Re: [PATCH v5] powerpc32: provide VIRT_CPU_ACCOUNTING
Le 14/02/2016 21:40, Denis Kirjanov a écrit :
On 2/11/16, Christophe Leroy wrote:
This patch provides VIRT_CPU_ACCOUTING to PPC32 architecture.
PPC32 doesn't have the PACA structure, so we use the task_info
structure to store the accounting data.
In order to reuse on PPC32 the PPC64 functions, all u64 data has
been replaced by 'unsigned long' so that it is u32 on PPC32 and
u64 on PPC64
Signed-off-by: Christophe Leroy
Doesn't build for me with the patch applied
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
GEN .version
CHK include/generated/compile.h
UPD include/generated/compile.h
CC init/version.o
LD init/built-in.o
drivers/built-in.o: In function `get_cpu_idle_time':
(.text+0x1261c4): undefined reference to `__umoddi3'
drivers/built-in.o: In function `get_cpu_idle_time':
(.text+0x1261e0): undefined reference to `__udivdi3'
Makefile:936: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1
Looks like you have CONFIG_CPU_FREQ, which I don't have.
The issue comes from the jiffies64_to_cputime64() defined in
arch/powerpc/include/asm/cputime.h :
static inline cputime64_t jiffies64_to_cputime64(const u64 jif)
{
u64 ct;
u64 sec;
/* have to be a little careful about overflow */
ct = jif % HZ;
sec = jif / HZ;
On 32 bits, 64 bits % and / require __udivdi3() and __umoddi3(), which
are not implemented in the kernel.
As HZ fits in 32 bits, the solution is to use do_div(). I should not
change anything on PPC64 and would solve your issue.
I will submit an update of the patch within an hour.
Christophe
Re: [PATCH 3/7] usb: gadget: pxa25x_udc: use readl/writel for mmio
On Monday 15 February 2016 08:33:37 Krzysztof Hałasa wrote: > Arnd Bergmann writes: > > >> Anyway, I think readl()/writel() do the right thing: in BE mode they > >> swap PCI accesses and don't swap normal registers, in LE mode nothing is > >> swapped. > > > > This seems to be true when CONFIG_IXP4XX_INDIRECT_PCI is set, but > > not otherwise. For the indirect variant, writel() is a __raw_writel() > > without barrier or byteswap on non-PCI memory, while with that > > option disabled, we use the standard implementation that has both > > a byteswap and a barrier. > > > > According to your description, that would mean the version without > > indirect PCI access is broken and it appears to have been that way > > since before the start of git history in 2.6.12. > > > > It's possible that nobody cared because all drivers for non-PCI > > devices on ixp4xx (the on chip ones) just use __raw_readl or > > direct pointer references. > > Well, it is possible. I recall I probably used __raw_* instead of > readl()/writel() in qmgr/npe/Ethernet drivers for this very reason. > > I think Direct pointer references are only used for locations in RAM > (DMA buffers), they have their own share of problems because the > peripherals are always big endian. > > I think I still have an early IXP425 board with UDC connector so I will > try to dig it up and test this code. > > I wonder if we should switch the driver to use __raw_*, too. The problem > is almost nobody uses UDC with this CPU. > I consider the use of __raw_* accessors a bug, I don't think we should ever do that because it hides how the hardware actually works, it doesn't work with spinlocks, and it can lead to the compiler splitting up accesses into byte sized ones (not on ARM with the current definition, but possible in general). Almost all hardware is fixed-endian, so you have to use swapping accessors when the CPU is the other way, except for device RAM and FIFO registers that are always used to transfer a byte stream (see the definition of readsl() and memcpy_fromio()). When you have hardware that adds byteswaps on the bus interface, you typically end up with MMIO registers requiring no swap (or double swap) and readsl()/memcpy_fromio()) suddenly requiring a swap that is counterintuitive. Arnd
Re: [PATCH 10/14] ARM: dts: sun8i-a83t: Add PRCM related clocks and resets
On Sat, Feb 13, 2016 at 12:43 AM, Chen-Yu Tsai wrote:
> On Sat, Feb 13, 2016 at 12:06 AM, Vishnu Patekar
> wrote:
>> Hello Wens,
>>
>>
>> On Tue, Feb 2, 2016 at 2:44 PM, Chen-Yu Tsai wrote:
>>> On Sun, Jan 31, 2016 at 9:21 AM, Vishnu Patekar
>>> wrote:
This adds A83T PRCM related clocks, clock resets.
As a83t apb0 gates clock support is added earlier, this enables it.
Apart from apb0 gates, other added clocks are compatible with
earlier sun8i socs.
Signed-off-by: Vishnu Patekar
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 44
+++
1 file changed, 44 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index ac96aa1..5ea20ff 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -268,6 +268,44 @@
"mmc2_output",
"mmc2_sample";
};
+
+ cpus_clk: clk@01f01400 {
+ compatible = "allwinner,sun9i-a80-cpus-clk";
+ reg = <0x01f01400 0x4>;
+ #clock-cells = <0>;
+ clocks = <&osc16Md512>, <&osc24M>, <&pll6>,
<&osc16M>;
+ clock-output-names = "cpus";
+ };
+
+ ahb0: ahb0_clk {
+ compatible = "fixed-factor-clock";
+ #clock-cells = <0>;
+ clock-div = <1>;
+ clock-mult = <1>;
+ clocks = <&cpus_clk>;
+ clock-output-names = "ahb0";
+ };
+
+ apb0: clk@01f0140c {
+ compatible = "allwinner,sun8i-a23-apb0-clk";
>>>
>>> This is actually wrong, as it is wrong in sun9i-a80.dtsi.
>>> I've sent a patch series for it.
>> A83T apb0 is different from A80, and it's same as A23, so this should
>> be correct.
>> Please correct me in case I'm missing something.
>
> My user manual (v1.5.1) says A83T apb0 dividers (page. 246) are
> /1, /2, /3, /4, while the A23 is /1, /2, /4, /8.
As Vishnu pointed out on IRC, the A23 driver is wrong. They are in fact,
both one-based dividers. I'll send a patch to fix this.
ChenYu
> ChenYu
>
>>> Also the drivers for "allwinner,sun9i-a80-cpus-clk" and
>>> "allwinner,sun9i-a80-apbs-clk"
>>> are only compiled for CONFIG_MACH_SUN9I. Please add a patch to address this.
>> Okie.
>>>
>>> Regards
>>> ChenYu
>>>
+ reg = <0x01f0140c 0x4>;
+ #clock-cells = <0>;
+ clocks = <&ahb0>;
+ clock-output-names = "apb0";
+ };
+
+ apb0_gates: clk@01f01428 {
+ compatible = "allwinner,sun8i-a83t-apb0-gates-clk";
+ reg = <0x01f01428 0x4>;
+ #clock-cells = <1>;
+ clocks = <&apb0>;
+ clock-indices = <0>, <1>,
+ <2>, <3>,
+ <4>, <6>, <7>;
+ clock-output-names = "apb0_pio", "apb0_ir",
+ "apb0_timer", "apb0_rsb",
+ "apb0_uart", "apb0_i2c0",
"apb0_twd";
+ };
};
soc {
@@ -434,5 +472,11 @@
#interrupt-cells = <3>;
interrupts = >>> IRQ_TYPE_LEVEL_HIGH)>;
};
+
+ apb0_reset: reset@01f014b0 {
+ reg = <0x01f014b0 0x4>;
+ compatible = "allwinner,sun6i-a31-clock-reset";
+ #reset-cells = <1>;
+ };
};
};
--
1.9.1
Re: [PATCH v2] auxdisplay: ht16k33: Driver for LED controller.
On Fri, 12 Feb 2016 09:12:43 -0600 Rob Herring wrote: > On Tue, Feb 09, 2016 at 12:31:08PM +0100, Robin van der Gracht wrote: > > This is a driver for the Holtek HT16K33 LED controller with keyscan. > > > > Signed-off-by: Robin van der Gracht > > --- > > Changes in v2: > > - Fixed build error reported by kbuild test robot by including > > mm.h > > > > .../devicetree/bindings/display/ht16k33.txt| 42 ++ > > drivers/auxdisplay/Kconfig | 9 + > > drivers/auxdisplay/Makefile| 1 + > > drivers/auxdisplay/ht16k33.c | 573 > > + 4 files changed, 625 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/ht16k33.txt create mode > > 100644 drivers/auxdisplay/ht16k33.c > > > > diff --git a/Documentation/devicetree/bindings/display/ht16k33.txt > > b/Documentation/devicetree/bindings/display/ht16k33.txt new file > > mode 100644 index 000..45fbabb > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/ht16k33.txt > > @@ -0,0 +1,42 @@ > > +Holtek ht16k33 RAM mapping 16*8 LED controller driver with keyscan > > +--- > > + > > +Required properties: > > +- compatible: "ht,ht16k33" > > +- reg: I2C slave address of > > the chip. +- interrupt-parent: A phandle pointing to the > > interrupt controller > > + serving the > > interrupt for this chip. +- interrupts: > > Interrupt specification for the key pressed interrupt. +- > > refresh-rate: Display update interval in HZ. > > Add units: "-hz" > > > +- debounce-delay-ms: Debouncing interval time in > > microseconds. +- linux,keymap: The keymap > > for keys as described in the binding > > + document > > (devicetree/bindings/input/matrix-keymap.txt). > > The alignment of the descriptions here seem to be random. Please line > them up. > > > + > > +Optional properties: > > +- linux,no-autorepeat: Disable keyrepeat. > > +- default-brightness: Initial brightness setting [0-15] (15 > > if not set). > > default-brightness-level seem a bit more common. > Thanks for reviewing Rob. I'll take your comments into account and resend an adjusted patch. Best regards, -- Robin van der Gracht Protonic Holland tel.: +31 (0) 229 212928 fax.: +31 (0) 229 210930 Factorij 36 / 1689 AL Zwaag
sound: memory leak in snd_seq_pool_init
Hello,
The following program causes memory leak of a 24K object allocated in
snd_seq_pool_init:
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include
#include
#include
#include
#include
long r[148];
void* thr(void* arg)
{
switch ((long)arg) {
case 0:
r[0] = syscall(SYS_mmap, 0x2000ul, 0xe000ul, 0x3ul, 0x32ul,
0xul, 0x0ul);
break;
case 1:
r[2] = syscall(SYS_open, "/dev/snd/seq", 0x1ul, 0, 0, 0);
break;
case 2:
*(uint32_t*)0x20008a90 = (uint32_t)0x6;
*(uint32_t*)0x20008a94 = (uint32_t)0x4;
*(uint32_t*)0x20008a98 = (uint32_t)0x200;
*(uint8_t*)0x20008a9c = (uint8_t)0xfa5;
*(uint8_t*)0x20008a9d = (uint8_t)0x1;
*(uint8_t*)0x20008a9e = (uint8_t)0x0;
*(uint8_t*)0x20008a9f = (uint8_t)0x3;
*(uint8_t*)0x20008aa0 = (uint8_t)0x1;
*(uint8_t*)0x20008aa1 = (uint8_t)0x1;
*(uint8_t*)0x20008aa2 = (uint8_t)0x0;
*(uint8_t*)0x20008aa3 = (uint8_t)0x40;
*(uint8_t*)0x20008aa4 = (uint8_t)0x9;
*(uint8_t*)0x20008aa5 = (uint8_t)0x9;
*(uint8_t*)0x20008aa6 = (uint8_t)0x6;
*(uint8_t*)0x20008aa7 = (uint8_t)0x80;
*(uint8_t*)0x20008aa8 = (uint8_t)0x0;
*(uint8_t*)0x20008aa9 = (uint8_t)0x5d34b2c3;
*(uint8_t*)0x20008aaa = (uint8_t)0x3a7;
*(uint8_t*)0x20008aab = (uint8_t)0x9;
*(uint8_t*)0x20008aac = (uint8_t)0x8d62;
*(uint8_t*)0x20008aad = (uint8_t)0x5;
*(uint8_t*)0x20008aae = (uint8_t)0x7;
*(uint8_t*)0x20008aaf = (uint8_t)0x20;
*(uint8_t*)0x20008ab0 = (uint8_t)0x8;
*(uint8_t*)0x20008ab1 = (uint8_t)0x7;
*(uint8_t*)0x20008ab2 = (uint8_t)0xfffc;
*(uint8_t*)0x20008ab3 = (uint8_t)0x7;
*(uint8_t*)0x20008ab4 = (uint8_t)0x7ff;
*(uint8_t*)0x20008ab5 = (uint8_t)0x1;
*(uint8_t*)0x20008ab6 = (uint8_t)0x0;
*(uint8_t*)0x20008ab7 = (uint8_t)0x9;
*(uint8_t*)0x20008ab8 = (uint8_t)0x6;
*(uint8_t*)0x20008ab9 = (uint8_t)0xfe00;
*(uint8_t*)0x20008aba = (uint8_t)0x1000;
*(uint8_t*)0x20008abb = (uint8_t)0xfffb;
*(uint8_t*)0x20008abc = (uint8_t)0xcfd3;
*(uint8_t*)0x20008abd = (uint8_t)0x101;
*(uint8_t*)0x20008abe = (uint8_t)0x9;
*(uint8_t*)0x20008abf = (uint8_t)0xfffc;
*(uint8_t*)0x20008ac0 = (uint8_t)0xf2;
*(uint8_t*)0x20008ac1 = (uint8_t)0x6;
*(uint8_t*)0x20008ac2 = (uint8_t)0x0;
*(uint8_t*)0x20008ac3 = (uint8_t)0x7fff;
*(uint8_t*)0x20008ac4 = (uint8_t)0x4;
*(uint8_t*)0x20008ac5 = (uint8_t)0x5;
*(uint8_t*)0x20008ac6 = (uint8_t)0x4;
*(uint8_t*)0x20008ac7 = (uint8_t)0x4;
*(uint8_t*)0x20008ac8 = (uint8_t)0x20;
*(uint8_t*)0x20008ac9 = (uint8_t)0x401;
*(uint8_t*)0x20008aca = (uint8_t)0x6;
*(uint8_t*)0x20008acb = (uint8_t)0x6;
*(uint8_t*)0x20008acc = (uint8_t)0x5;
*(uint8_t*)0x20008acd = (uint8_t)0x3;
*(uint8_t*)0x20008ace = (uint8_t)0xfffc;
*(uint8_t*)0x20008acf = (uint8_t)0xb0c;
*(uint8_t*)0x20008ad0 = (uint8_t)0x2;
*(uint8_t*)0x20008ad1 = (uint8_t)0xfff9;
*(uint8_t*)0x20008ad2 = (uint8_t)0x8000;
*(uint8_t*)0x20008ad3 = (uint8_t)0x5;
*(uint8_t*)0x20008ad4 = (uint8_t)0xb0c;
*(uint8_t*)0x20008ad5 = (uint8_t)0xfeff;
*(uint8_t*)0x20008ad6 = (uint8_t)0x5;
*(uint8_t*)0x20008ad7 = (uint8_t)0x101;
*(uint8_t*)0x20008ad8 = (uint8_t)0xbfd;
*(uint8_t*)0x20008ad9 = (uint8_t)0x7ff;
*(uint8_t*)0x20008ada = (uint8_t)0x7f;
*(uint8_t*)0x20008adb = (uint8_t)0x5;
*(uint32_t*)0x20008adc = (uint32_t)0x6;
*(uint8_t*)0x20008ae0 = (uint8_t)0x0;
*(uint8_t*)0x20008ae1 = (uint8_t)0x0;
*(uint8_t*)0x20008ae2 = (uint8_t)0x0;
*(uint8_t*)0x20008ae3 = (uint8_t)0x0;
*(uint8_t*)0x20008ae4 = (uint8_t)0x0;
*(uint8_t*)0x20008ae5 = (uint8_t)0x0;
*(uint8_t*)0x20008ae6 = (uint8_t)0x0;
*(uint8_t*)0x20008ae7 = (uint8_t)0x0;
*(uint8_t*)0x20008ae8 = (uint8_t)0x0;
*(uint8_t*)0x20008ae9 = (uint8_t)0x0;
*(uint8_t*)0x20008aea = (uint8_t)0x0;
*(uint8_t*)0x20008aeb = (uint8_t)0x0;
*(uint8_t*)0x20008aec = (uint8_t)0x0;
*(uint8_t*)0x20008aed = (uint8_t)0x0;
*(uint8_t*)0x20008aee = (uint8_t)0x0;
*(uint8_t*)0x20008aef = (uint8_t)0x0;
*(uint8_t*)0x20008af0 = (uint8_t)0x0;
*(uint8_t*)0x20008af1 = (uint8_t)0x0;
*(uint8_t*)0x20008af2 = (uint8_t)0x0;
*(uint8_t*)0x20008af3 = (uint8_t)0x0;
*(uint8_t*)0x20008af4 = (uint8_t)0x0;
*(uint8_t*)0x20008af5 = (uint8_t)0x0;
*(uint8_t*)0x20008af6 = (uint8_t)0x0;
*(uint8_t*)0x20008af7 = (uint8_t)0x0;
*(uint8_t*)0x20008af8 = (uint8_t)0x0;
*(uint8_t*)0x20008af9 = (uint8_t)0x0;
*(uint8_t*)0x20008afa = (uint8_t)0x0;
*(uint8_t*)0x20008afb = (uint8_t)0x0;
*(uint8_t*)0x20008afc = (uint8_t)0x0;
*(uint8_t*)0x20008afd = (uint8_t)0x0;
*(uint8_t*)0x20008afe = (uint8_t)0x0;
*(uint8_t*)0x20008aff = (uint8_t)0x0;
*(uint8_t*)0x20008b00 = (uint8_t)0x0;
*(uint8_t*)0x20008b01 = (uint8_t)0x0;
*(uint8_t*)0x20008b02 = (uint
Re: [LKP] [lkp] [gpio] 3c702e9987: kmsg.user_verbs:couldn't_register_device_number
On Mon, Feb 15, 2016 at 3:39 AM, Huang, Ying wrote:
> Michael Welling writes:
>> Could you run cat /proc/devices?
>
> Sorry, the test mechanism is not flexible enough to run some shell
> command in test system. Could you provide a specialized debug kernel to
> dump the necessary information in kernel log? We can collect dmesg
> easily.
Can you try this:
diff --git a/fs/char_dev.c b/fs/char_dev.c
index 24b142569ca9..74a2d433273e 100644
--- a/fs/char_dev.c
+++ b/fs/char_dev.c
@@ -96,6 +96,8 @@ __register_chrdev_region(unsigned int major,
unsigned int baseminor,
goto out;
}
major = i;
+pr_info("CHARDEV: allocate major %d for \"%s\"\n",
+i, name);
}
cd->major = major;
Then dmesg |grep CHARDEV should tell what we need to know.
Yours,
Linus Walleij
[PATCH v3] clk: sunxi: Fix sun8i-a23-apb0-clk divider flags
The APB0 clock on A23 is a zero-based divider, not a power-of-two based
divider.
Note that this patch does not apply cleanly to kernels before 4.5-rc1,
which added CLK_OF_DECLARE support to this driver.
Fixes: 57a1fbf28424 ("clk: sunxi: Add A23 APB0 divider clock support")
Signed-off-by: Chen-Yu Tsai
---
Vishnu pointed out that A23 is in fact a zero-based divider. This
version corrects the whole driver, now that we know this clock is
compatible between A23 and A80.
---
drivers/clk/sunxi/clk-sun8i-apb0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/sunxi/clk-sun8i-apb0.c
b/drivers/clk/sunxi/clk-sun8i-apb0.c
index 7ba61103a6f5..2ea61debffc1 100644
--- a/drivers/clk/sunxi/clk-sun8i-apb0.c
+++ b/drivers/clk/sunxi/clk-sun8i-apb0.c
@@ -36,7 +36,7 @@ static struct clk *sun8i_a23_apb0_register(struct device_node
*node,
/* The A23 APB0 clock is a standard 2 bit wide divider clock */
clk = clk_register_divider(NULL, clk_name, clk_parent, 0, reg,
- 0, 2, CLK_DIVIDER_POWER_OF_TWO, NULL);
+ 0, 2, 0, NULL);
if (IS_ERR(clk))
return clk;
--
2.7.0
[PATCH RFC 1/1] x86: fix bad memory access in fb_is_primary_device()
Currently the code in fb_is_primary_device() contains to_pci_dev() macro which is applied to dev from struct fb_info. In some cases this causes bad memory access when fb_is_primary_device() handles fb_info of efifb. The reason is that fb dev of efifb is embedded into struct platform_device but not into struct pci_dev. We can fix this by checking fb dev bus name in fb_is_primary_device(). It seems that this bug reveals some bigger problem with to_pci_dev(), to_platform_device() and others, which just do container_of() and don't check whether struct device is a part of the appropriate structure. Should we do something more about it? KASan report: == BUG: KASAN: slab-out-of-bounds in fb_is_primary_device+0x58/0x70 at addr 8803b68ca8a8 Read of size 8 by task swapper/0/1 = BUG kmalloc-1024 (Not tainted): kasan: bad access detected - Disabling lock debugging due to kernel taint INFO: Allocated in platform_device_alloc+0x2c/0xa0 age=183 cpu=0 pid=1 ___slab_alloc+0x486/0x4e0 __slab_alloc+0x20/0x40 __kmalloc+0x1d7/0x240 platform_device_alloc+0x2c/0xa0 platform_device_register_full+0x3b/0x200 sysfb_init+0xd4/0x11e do_one_initcall+0x122/0x290 kernel_init_freeable+0x2e9/0x3ad kernel_init+0x13/0x100 ret_from_fork+0x3f/0x70 INFO: Slab 0xea000eda3200 objects=24 used=24 fp=0x (null) flags=0x5fff804080 INFO: Object 0x8803b68ca450 @offset=9296 fp=0x8803b68ca760 Bytes b4 8803b68ca440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Object 8803b68ca450: 60 a7 8c b6 03 88 ff ff 00 00 00 00 00 00 00 00 `... Object 8803b68ca460: 20 6c 6f 82 ff ff ff ff 10 5d a8 b6 03 88 ff ff lo..].. Object 8803b68ca470: 00 60 b3 b8 00 88 ff ff 30 b1 c8 b9 03 88 ff ff .`..0... Object 8803b68ca480: d0 e7 6d b7 03 88 ff ff 30 6c 6f 82 ff ff ff ff ..m.0lo. Object 8803b68ca490: 30 b1 c8 b9 03 88 ff ff 40 31 6f 82 ff ff ff ff 0...@1o. Object 8803b68ca4a0: c0 a7 ad b6 03 88 ff ff 03 00 00 00 07 00 00 00 Object 8803b68ca4b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Object 8803b68ca4c0: 00 00 00 00 00 00 00 00 c8 a4 8c b6 03 88 ff ff Object 8803b68ca4d0: c8 a4 8c b6 03 88 ff ff 00 00 ca b7 03 88 ff ff Object 8803b68ca4e0: 00 00 00 00 00 00 00 00 60 6a 6f 82 ff ff ff ff `jo. Object 8803b68ca4f0: 48 0b 68 82 ff ff ff ff 90 f5 4f b2 03 88 ff ff H.h...O. Object 8803b68ca500: 00 80 ea b0 03 88 ff ff 00 00 00 00 80 00 00 00 Object 8803b68ca510: 00 00 00 00 00 00 00 00 b8 d3 8c b6 03 88 ff ff Object 8803b68ca520: f8 d8 8c b6 03 88 ff ff ff ff ff 7f 00 00 00 00 Object 8803b68ca530: 00 00 00 00 00 00 00 00 38 a5 8c b6 03 88 ff ff 8... Object 8803b68ca540: 38 a5 8c b6 03 88 ff ff 00 00 00 00 00 00 00 00 8... Object 8803b68ca550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Object 8803b68ca560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Object 8803b68ca570: e0 62 7c 81 ff ff ff ff 60 a4 8c b6 03 88 ff ff .b|.`... Object 8803b68ca580: 00 00 00 00 ff ff ff ff ff ff ff ff 00 00 00 00 Object 8803b68ca590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Object 8803b68ca5a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Object 8803b68ca5b0: e0 ff ff ff 0f 00 00 00 b8 a5 8c b6 03 88 ff ff Object 8803b68ca5c0: b8 a5 8c b6 03 88 ff ff 70 69 7c 81 ff ff ff ff pi|. Object 8803b68ca5d0: 00 00 00 00 00 00 00 00 d8 a5 8c b6 03 88 ff ff Object 8803b68ca5e0: d8 a5 8c b6 03 88 ff ff 00 00 00 00 00 00 00 00 Object 8803b68ca5f0: 00 00 00 00 00 00 00 00 81 00 00 00 00 00 00 00 Object 8803b68ca600: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Object 8803b68ca610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Object 8803b68ca620: 00 00 00 00 00 00 00 00 a0 7a fb ff 00 00 00 00 .z.. Object 8803b68ca630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Object 8803b68ca640: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Object 8803b68ca650: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Object 8803b68ca660: 60 a6 8c b6 03 88 ff ff 60 a6 8c b6 03 88 ff ff `...`... Object 8803b68ca670: ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 Object 8803b68ca680: 00 00 0
Re: [PATCH 1/4] block: bio: introduce helpers to get the 1st and last bvec
Hi,
On Mon, 15 Feb 2016 10:19:49 +0200
Sagi Grimberg wrote:
>
> > +/*
> > + * bio_get_last_bvec() is introduced to get the last bvec of one
> > + * bio for bio_will_gap().
> > + *
> > + * TODO: make it more efficient.
> > + */
> > +static inline void bio_get_last_bvec(struct bio *bio, struct bio_vec *bv)
> > +{
> > + struct bvec_iter iter;
> > +
> > + bio_for_each_segment(*bv, bio, iter)
> > + if (bv->bv_len == iter.bi_size)
> > + break;
> > +}
>
> This helper is used for each req/bio once or more. I'd say
No, the helper is only used for the non-splitted BIO, and all
splitted BIO is marked as non-merge.
> it's critical to make it efficient and not settle for
> a quick bail for drivers that don't have a virt_boundary
> like you did in patch #2.
Cc Kent and Keith.
Follows another version which should be more efficient.
Kent and Keith, I appreciate much if you may give a review on it.
diff --git a/include/linux/bio.h b/include/linux/bio.h
index 56d2db8..ef45fec 100644
--- a/include/linux/bio.h
+++ b/include/linux/bio.h
@@ -278,11 +278,21 @@ static inline void bio_get_first_bvec(struct bio *bio,
struct bio_vec *bv)
*/
static inline void bio_get_last_bvec(struct bio *bio, struct bio_vec *bv)
{
- struct bvec_iter iter;
+ struct bvec_iter iter = bio->bi_iter;
+ int idx;
+
+ bio_advance_iter(bio, &iter, iter.bi_size);
+
+ WARN_ON(!iter.bi_idx && !iter.bi_bvec_done);
+
+ if (!iter.bi_bvec_done)
+ idx = iter.bi_idx - 1;
+ else/* in the middle of bvec */
+ idx = iter.bi_idx;
- bio_for_each_segment(*bv, bio, iter)
- if (bv->bv_len == iter.bi_size)
- break;
+ *bv = bio->bi_io_vec[idx];
+ if (iter.bi_bvec_done)
+ bv->bv_len = iter.bi_bvec_done;
}
/*
>
> However, given that it's a regression bug fix I'm not sure it's the best
> idea to add logic here.
But the issue is obviously in bio_will_gap(), isn't it?
Simply reverting 52cc6eead9095(block: blk-merge: fast-clone bio when splitting
rw bios)
still might cause performance regression too.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-block" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/4] dt-bindings: power: reset: add document for reboot-mode driver
Hi Rob & John:
On 2016年02月05日 13:03, John Stultz wrote:
On Thu, Feb 4, 2016 at 8:35 PM, Rob Herring wrote:
On Thu, Feb 04, 2016 at 03:46:15PM -0800, John Stultz wrote:
On Thu, Feb 4, 2016 at 3:08 PM, Rob Herring wrote:
On Tue, Feb 02, 2016 at 05:59:11PM +0800, Andy Yan wrote:
+Example:
+ reboot-mode {
+ mode-normal = ;
+ mode-recovery = ;
+ mode-fastboot = ;
I tend to agree with John on calling this mode-bootloader.
OTOH, fastboot is more specific about what the mode is. The name in DT
and the userspace name don't necessarily have to be the same.
Wait. This is a bit confusing. The utility of adding a property name
and using that name be the reboot command parsed for made sense
(compared to earlier versions which had command strings) as it made
the dts more terse. But it sounds here like you're suggesting we
should have some logic in the driver that translates "reboot fastboot"
to mode-bootloader or vice versa.
I said early on the DT names and kernel-userspace names should not
necessarily be linked. They can be, but we shouldn't require that.
Sigh. Ok. It seemed it was due to earlier comments (maybe from others,
but I thought it was you), that we moved from specifying a command
string, to using the label. But if you think the label name and the
commands shouldn't be linked, it seems like we should re-introduce
that. No?
Unless your thinking we need some sort of static in-kernel mapping of
commands to label names? But that just seems painfully indirect for
little gain ("Its obvious! For that mode, you use this term here, and
that different term over there!").
My concern with mode-bootloader is what if you can boot into multiple
bootloader modes. Say USB mass storage is one option. "bootloader" is
not real specific.
True. But as I think we agreed below, "bootloader" and "recovery" are
basically defacto standards, and I think it would be a bad idea to try
to declare all the existing android tooling and docs wrong just
because the command is vague, technically.
+ mode-loader = ;
This one needs a better name. Maybe it should be 'rockchip,mode-loader'
as it is vendor specific. Either way, loader is vague. Perhaps
rockchip,mode-bl-download?
Hrm. So how what reboot command do you expect to trigger that?
Whatever your OS has defined to map to that.
We could just decide the kernel will strip and 'mode-' and
match commands against what remains.
That part sounds sane, although I do think having vendor prefixes are
reasonable for actual commands as well.
I think one of the difficult things here is that there's no real
standards for all bios/bootloader modes. So they are somewhat
firmware/bootloader/device specific, and thus we need something that
is flexible enough to allow lots of different modes to be easily
specified. That said, this does expose a userspace interface (though
one could argue kernel ABI doesn't cross reboots :) so we should try
to have some consistency so the same userspace can work on various
devices.
There is: UEFI. Boot mode efivars are standard. But then they are pretty
much PC oriented though. It is more which device to boot off of, but
there is network boot or boot to bios setup.
Well, there's a partial standard there. I'm told for android on x86,
there is no UEFI standard way to communicate rebooting to fastboot or
recovery. Every device does its own device specific driver.
I do think the "bootloader" and "recovery" arguments are somewhat
defacto standards, well established on most android devices.
Yes, otherwise I'd be completely against "mode-bootloader" as the
property.
Ok.
I think here the concern is rockchip probably has some userspace that
is already using "reboot maskrom" or "reboot loader" for their own
uses. And its a bit of a pain to ask that userspace to be reworked to
Perhaps those are only for development and change would not be so
painful.
Andy: Can you comment here? How critical are the specific commands
you've used here for your userspace?
Have some discussion with my colleague, we decided remove the"
maskrom" mode in next version.
Actually, this mode is not so used so often.
But "reboot loader" is frequently used in development by all the
rockchip platform related people, even
some widely used factory tools use this command.So we really hope it can
compatible with the existing tools
and user experience.
use "reboot rom-download" or "reboot rockchip,rom-download" depending
on how we try to deal with these. (Granted, non-upstream interfaces
aren't official, so that is their risk somewhat, but we avoid being
smug about that :)
Or vendor specific modes require vendor specific translation in the
kernel.
True.
To some extent we need to design what is right and worry about future
devices rather than cater to past devices. There's always some
compromise. What would you design ignoring the existing conditions.
Start there and then figure out how to make it work with cu
[PATCH v5 1/2] Documentation: bindings: add description of phy for sdhci-of-arasan
This patch adds phys and phy-names for sdhci-of-arasan as required
properties for arasan,sdhci-5.1, and details the example as well.
Signed-off-by: Shawn Lin
---
Changes in v2:
- Keep phy as a mandatory requirement for arasan,sdhci-5.1
.../devicetree/bindings/mmc/arasan,sdhci.txt | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
index da541c3..31b35c3 100644
--- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
+++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
@@ -1,11 +1,12 @@
Device Tree Bindings for the Arasan SDHCI Controller
- The bindings follow the mmc[1], clock[2] and interrupt[3] bindings. Only
- deviations are documented here.
+ The bindings follow the mmc[1], clock[2], interrupt[3] and phy[4] bindings.
+ Only deviations are documented here.
[1] Documentation/devicetree/bindings/mmc/mmc.txt
[2] Documentation/devicetree/bindings/clock/clock-bindings.txt
[3] Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+ [4] Documentation/devicetree/bindings/phy/phy-bindings.txt
Required Properties:
- compatible: Compatibility string. Must be 'arasan,sdhci-8.9a' or
@@ -17,6 +18,10 @@ Required Properties:
- interrupt-parent: Phandle for the interrupt controller that services
interrupts for this device.
+Required Properties for "arasan,sdhci-5.1":
+ - phys: From PHY bindings: Phandle for the Generic PHY for arasan.
+ - phy-names: MUST be "phy_arasan".
+
Example:
sdhci@e010 {
compatible = "arasan,sdhci-8.9a";
@@ -26,3 +31,14 @@ Example:
interrupt-parent = <&gic>;
interrupts = <0 24 4>;
} ;
+
+ sdhci@e280 {
+ compatible = "arasan,sdhci-5.1";
+ reg = <0xe280 0x1000>;
+ clock-names = "clk_xin", "clk_ahb";
+ clocks = <&cru 8>, <&cru 18>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 24 4>;
+ phys = <&emmc_phy>;
+ phy-names = "phy_arasan";
+ } ;
--
2.3.7
[PATCH v5 0/2] Add phy support for arasan,sdhci-5.1
Hello Ulf and Adrian, Sorry for delay the new version for this topic. Actually I have no platform available to test phy stuff since v4. Now, I can rework it.:) I remove rpm support from v5 because this patchset just need to focus on phy stuff, which will make the changes more precise. Another reason is that phy_power_on take too much time from rpm, however the power profit gained from phy_power_off is little due to the low power mechanism with the phy itself observed from experiments. v4 can be found here: https://patchwork.kernel.org/patch/7463251/ Note: Phy is mandatory requirement for arasan,sdhci-5.1, so we introduce generic phy support for sdhci-of-arasan. Shawn Lin (2): Documentation: bindings: add description of phy for sdhci-of-arasan mmc: sdhci-of-arasan: add phy support for sdhci-of-arasan .../devicetree/bindings/mmc/arasan,sdhci.txt | 20 ++- drivers/mmc/host/sdhci-of-arasan.c | 66 -- 2 files changed, 80 insertions(+), 6 deletions(-) -- 2.3.7
[PATCH v5 2/2] mmc: sdhci-of-arasan: add phy support for sdhci-of-arasan
This patch adds Generic PHY access for sdhci-of-arasan. Driver
can get PHY handler from dt-binding, and power-on/init the PHY.
Currently, it's just mandatory for arasan,sdhci-5.1.
Signed-off-by: Shawn Lin
Serise-changes: 5
- remove rpm support from this serise
- fix some err case for handling phy
Serise-changes: 4
- remove suspend/resume_phy
- add err handle label for system PM callback
- fix comments of struct sdhci_arasan_data and system PM
callback suggested by Michal
Serise-changes: 3
- remove phy_init/exit for suspend/resume
- adjust phy_int/power_on seq to make code more reasonable
- simplify suspend/resume_phy
Serise-changes: 2
- Keep phy as a mandatory requirement for arasan,sdhci-5.1
---
Changes in v2: None
drivers/mmc/host/sdhci-of-arasan.c | 66 +++---
1 file changed, 62 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-arasan.c
b/drivers/mmc/host/sdhci-of-arasan.c
index 5d9fdb3..cc40b1d 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -21,6 +21,7 @@
#include
#include
+#include
#include "sdhci-pltfm.h"
#define SDHCI_ARASAN_CLK_CTRL_OFFSET 0x2c
@@ -32,9 +33,11 @@
/**
* struct sdhci_arasan_data
* @clk_ahb: Pointer to the AHB clock
+ * @phy: Pointer to the generic phy
*/
struct sdhci_arasan_data {
struct clk *clk_ahb;
+ struct phy *phy;
};
static unsigned int sdhci_arasan_get_timeout_clock(struct sdhci_host *host)
@@ -72,7 +75,7 @@ static struct sdhci_pltfm_data sdhci_arasan_pdata = {
/**
* sdhci_arasan_suspend - Suspend method for the driver
* @dev: Address of the device structure
- * Returns 0 on success and error value on error
+ * Return: 0 on success and error value on error
*
* Put the device in a low power state.
*/
@@ -88,6 +91,14 @@ static int sdhci_arasan_suspend(struct device *dev)
if (ret)
return ret;
+ if (!IS_ERR(sdhci_arasan->phy)) {
+ ret = phy_power_off(sdhci_arasan->phy);
+ if (ret) {
+ dev_err(dev, "Cannot power off phy.\n");
+ return ret;
+ }
+ }
+
clk_disable(pltfm_host->clk);
clk_disable(sdhci_arasan->clk_ahb);
@@ -97,7 +108,7 @@ static int sdhci_arasan_suspend(struct device *dev)
/**
* sdhci_arasan_resume - Resume method for the driver
* @dev: Address of the device structure
- * Returns 0 on success and error value on error
+ * Return: 0 on success and error value on error
*
* Resume operation after suspend
*/
@@ -118,11 +129,24 @@ static int sdhci_arasan_resume(struct device *dev)
ret = clk_enable(pltfm_host->clk);
if (ret) {
dev_err(dev, "Cannot enable SD clock.\n");
- clk_disable(sdhci_arasan->clk_ahb);
- return ret;
+ goto err_clk_en;
+ }
+
+ if (!IS_ERR(sdhci_arasan->phy)) {
+ ret = phy_power_on(sdhci_arasan->phy);
+ if (ret) {
+ dev_err(dev, "Cannot power on phy.\n");
+ goto err_phy_power;
+ }
}
return sdhci_resume_host(host);
+
+err_phy_power:
+ clk_disable(pltfm_host->clk);
+err_clk_en:
+ clk_disable(sdhci_arasan->clk_ahb);
+ return ret;
}
#endif /* ! CONFIG_PM_SLEEP */
@@ -183,6 +207,30 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
goto clk_disable_all;
}
+ sdhci_arasan->phy = ERR_PTR(-ENODEV);
+ if (of_device_is_compatible(pdev->dev.of_node,
+ "arasan,sdhci-5.1")) {
+ sdhci_arasan->phy = devm_phy_get(&pdev->dev,
+"phy_arasan");
+ if (IS_ERR(sdhci_arasan->phy)) {
+ ret = PTR_ERR(sdhci_arasan->phy);
+ dev_err(&pdev->dev, "No phy for arasan,sdhci-5.1.\n");
+ goto clk_disable_all;
+ }
+
+ ret = phy_init(sdhci_arasan->phy);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "phy_init err.\n");
+ goto clk_disable_all;
+ }
+
+ ret = phy_power_on(sdhci_arasan->phy);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "phy_power_on err.\n");
+ goto err_phy_power;
+ }
+ }
+
ret = sdhci_add_host(host);
if (ret)
goto err_pltfm_free;
@@ -190,7 +238,12 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
return 0;
err_pltfm_free:
+ if (!IS_ERR(sdhci_arasan->phy))
+ phy_power_off(sdhci_arasan->phy);
sdhci_pltfm_free(pdev);
+err_phy_power:
+ if (!IS_ERR(sdhci_arasan->phy))
+ phy_exit(sdhci_arasan->phy);
clk_disable_all:
clk_disable_unprepare(clk_x
Re: [PATCH v6 7/7] clk: mediatek: Enable critical clocks for MT2701
Hi Mike,
On Thu, 2016-02-11 at 13:35 -0800, Michael Turquette wrote:
> Hi James,
>
> Quoting James Liao (2016-02-05 01:37:30)
> > Some system clocks should be turned on by default on MT2701.
> > This patch enable these clocks when related clocks have
> > been registered.
> >
> > Signed-off-by: James Liao
> > ---
> > drivers/clk/mediatek/clk-mt2701.c | 23 +--
> > 1 file changed, 21 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/clk/mediatek/clk-mt2701.c
> > b/drivers/clk/mediatek/clk-mt2701.c
> > index 01722e0..f7b4d52 100644
> > --- a/drivers/clk/mediatek/clk-mt2701.c
> > +++ b/drivers/clk/mediatek/clk-mt2701.c
> > @@ -573,6 +573,21 @@ static const struct mtk_gate top_clks[] __initconst = {
> > GATE_TOP_AUD(CLK_TOP_AUD_I2S6_MCLK, "aud_i2s6_mclk",
> > "aud_k6_src_div", 28),
> > };
> >
> > +static struct clk_onecell_data *top_clk_data __initdata;
> > +static struct clk_onecell_data *pll_clk_data __initdata;
> > +
> > +static void __init mtk_clk_enable_critical(void)
> > +{
> > + if (!top_clk_data || !pll_clk_data)
> > + return;
> > +
> > + clk_prepare_enable(pll_clk_data->clks[CLK_APMIXED_ARMPLL]);
> > + clk_prepare_enable(top_clk_data->clks[CLK_TOP_AXI_SEL]);
> > + clk_prepare_enable(top_clk_data->clks[CLK_TOP_MEM_SEL]);
> > + clk_prepare_enable(top_clk_data->clks[CLK_TOP_DDRPHYCFG_SEL]);
> > + clk_prepare_enable(top_clk_data->clks[CLK_TOP_RTC_SEL]);
> > +}
>
> I think we're close to having a better solution. Please see this patch
> series[0] and let me know if it provides a better way for you to enable
> these critical clocks instead of the open-coded solution.
>
> [0]
> http://lkml.kernel.org/r/<1455225554-13267-1-git-send-email-mturque...@baylibre.com>
>
I took a quick view of this patchset, CLK_ENABLE_HAND_OFF is not
suitable for these critical clocks. I'm not sure CLK_IS_CRITICAL
suitable or not. A clock with CLK_IS_CRITICAL will be prepare_enable
when it is registered. But if its parent is not registered into CCF, it
will not be enabled even the parent clock register into CCF later.
> > +
> > static void __init mtk_topckgen_init(struct device_node *node)
> > {
> > struct clk_onecell_data *clk_data;
> > @@ -585,7 +600,7 @@ static void __init mtk_topckgen_init(struct device_node
> > *node)
> > return;
> > }
> >
> > - clk_data = mtk_alloc_clk_data(CLK_TOP_NR);
> > + top_clk_data = clk_data = mtk_alloc_clk_data(CLK_TOP_NR);
> >
> > mtk_clk_register_fixed_clks(top_fixed_clks,
> > ARRAY_SIZE(top_fixed_clks),
> > clk_data);
> > @@ -606,6 +621,8 @@ static void __init mtk_topckgen_init(struct device_node
> > *node)
> > if (r)
> > pr_err("%s(): could not register clock provider: %d\n",
> > __func__, r);
> > +
> > + mtk_clk_enable_critical();
>
> So you call the function here, and ...
> > }
> > CLK_OF_DECLARE(mtk_topckgen, "mediatek,mt2701-topckgen",
> > mtk_topckgen_init);
> >
> > @@ -1201,7 +1218,7 @@ static void __init mtk_apmixedsys_init(struct
> > device_node *node)
> > struct clk_onecell_data *clk_data;
> > int r;
> >
> > - clk_data = mtk_alloc_clk_data(ARRAY_SIZE(apmixed_plls));
> > + pll_clk_data = clk_data =
> > mtk_alloc_clk_data(ARRAY_SIZE(apmixed_plls));
> > if (!clk_data)
> > return;
> >
> > @@ -1212,6 +1229,8 @@ static void __init mtk_apmixedsys_init(struct
> > device_node *node)
> > if (r)
> > pr_err("%s(): could not register clock provider: %d\n",
> > __func__, r);
> > +
> > + mtk_clk_enable_critical();
>
> ... here as well. So the prepare_count and enable_count will be 2? I'm
> not sure that this makes sense. If you have different clocks that need
> to be enabled at different times (due to the split registration scheme
> that you employ in this driver) then why not pass an array of those
> clocks into mtk_clk_enable_critical?
No. After topckgen and apmixedsys initialized, critical clocks'
reference count will be 1.
There is a guard at the beginning of mtk_clk_enable_critical():
if (!top_clk_data || !pll_clk_data)
return;
So this function will be only executed when topckgen and apmixedsys init
done.
We need to enable critical clocks:
1. As early as possible.
2. After critical clocks and their parents are registered into CCF.
We need to wait all necessary clock providers because parents of
critical clocks must be enabled at the same time. For example,
CLK_TOP_AXI_SEL may have different parent on different platforms. We
also need to keep new parent clock on if CLK_TOP_AXI_SEL change its
parent dynamically.
Because we can't ensure the init ordering of clock providers, we can
only check all necessary providers are registered or not in each init
function.
> Anyways, lik
[PATCH] f2fs crypto: avoid unneeded memory allocation when {en/de}crypting symlink
This patch adopts f2fs with codes of ext4, it removes unneeded memory
allocation in creating/accessing path of symlink.
Signed-off-by: Chao Yu
---
fs/f2fs/crypto_fname.c | 21 +--
fs/f2fs/f2fs.h | 1 +
fs/f2fs/namei.c| 72 --
3 files changed, 48 insertions(+), 46 deletions(-)
diff --git a/fs/f2fs/crypto_fname.c b/fs/f2fs/crypto_fname.c
index 73741fb..6dfdc97 100644
--- a/fs/f2fs/crypto_fname.c
+++ b/fs/f2fs/crypto_fname.c
@@ -257,6 +257,18 @@ u32 f2fs_fname_crypto_round_up(u32 size, u32 blksize)
return ((size + blksize - 1) / blksize) * blksize;
}
+unsigned f2fs_fname_encrypted_size(struct inode *inode, u32 ilen)
+{
+ struct f2fs_crypt_info *ci = F2FS_I(inode)->i_crypt_info;
+ int padding = 32;
+
+ if (ci)
+ padding = 4 << (ci->ci_flags & F2FS_POLICY_FLAGS_PAD_MASK);
+ if (ilen < F2FS_CRYPTO_BLOCK_SIZE)
+ ilen = F2FS_CRYPTO_BLOCK_SIZE;
+ return f2fs_fname_crypto_round_up(ilen, padding);
+}
+
/**
* f2fs_fname_crypto_alloc_obuff() -
*
@@ -266,15 +278,8 @@ u32 f2fs_fname_crypto_round_up(u32 size, u32 blksize)
int f2fs_fname_crypto_alloc_buffer(struct inode *inode,
u32 ilen, struct f2fs_str *crypto_str)
{
- unsigned int olen;
- int padding = 32;
- struct f2fs_crypt_info *ci = F2FS_I(inode)->i_crypt_info;
+ unsigned int olen = f2fs_fname_encrypted_size(inode, ilen);
- if (ci)
- padding = 4 << (ci->ci_flags & F2FS_POLICY_FLAGS_PAD_MASK);
- if (ilen < F2FS_CRYPTO_BLOCK_SIZE)
- ilen = F2FS_CRYPTO_BLOCK_SIZE;
- olen = f2fs_fname_crypto_round_up(ilen, padding);
crypto_str->len = olen;
if (olen < F2FS_FNAME_CRYPTO_DIGEST_SIZE * 2)
olen = F2FS_FNAME_CRYPTO_DIGEST_SIZE * 2;
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index c4c7bf1..fc302ea 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -2225,6 +2225,7 @@ int _f2fs_get_encryption_info(struct inode *inode);
/* crypto_fname.c */
bool f2fs_valid_filenames_enc_mode(uint32_t);
u32 f2fs_fname_crypto_round_up(u32, u32);
+unsigned f2fs_fname_encrypted_size(struct inode *, u32);
int f2fs_fname_crypto_alloc_buffer(struct inode *, u32, struct f2fs_str *);
int f2fs_fname_disk_to_usr(struct inode *, f2fs_hash_t *,
const struct f2fs_str *, struct f2fs_str *);
diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
index 6f944e5..fcc8c26 100644
--- a/fs/f2fs/namei.c
+++ b/fs/f2fs/namei.c
@@ -345,13 +345,23 @@ static int f2fs_symlink(struct inode *dir, struct dentry
*dentry,
struct f2fs_sb_info *sbi = F2FS_I_SB(dir);
struct inode *inode;
size_t len = strlen(symname);
- size_t p_len;
- char *p_str;
- struct f2fs_str disk_link = FSTR_INIT(NULL, 0);
+ struct f2fs_str disk_link = FSTR_INIT((char *)symname, len + 1);
struct f2fs_encrypted_symlink_data *sd = NULL;
int err;
- if (len > dir->i_sb->s_blocksize)
+ if (f2fs_encrypted_inode(dir)) {
+ err = f2fs_get_encryption_info(dir);
+ if (err)
+ return err;
+
+ if (!f2fs_encrypted_inode(dir))
+ return -EPERM;
+
+ disk_link.len = (f2fs_fname_encrypted_size(dir, len) +
+ sizeof(struct f2fs_encrypted_symlink_data));
+ }
+
+ if (disk_link.len > dir->i_sb->s_blocksize)
return -ENAMETOOLONG;
inode = f2fs_new_inode(dir, S_IFLNK | S_IRWXUGO);
@@ -374,42 +384,36 @@ static int f2fs_symlink(struct inode *dir, struct dentry
*dentry,
f2fs_unlock_op(sbi);
alloc_nid_done(sbi, inode->i_ino);
- if (f2fs_encrypted_inode(dir)) {
+ if (f2fs_encrypted_inode(inode)) {
struct qstr istr = QSTR_INIT(symname, len);
+ struct f2fs_str ostr;
- err = f2fs_get_encryption_info(inode);
- if (err)
+ sd = kzalloc(disk_link.len, GFP_NOFS);
+ if (!sd) {
+ err = -ENOMEM;
goto err_out;
+ }
- err = f2fs_fname_crypto_alloc_buffer(inode, len, &disk_link);
+ err = f2fs_get_encryption_info(inode);
if (err)
goto err_out;
- err = f2fs_fname_usr_to_disk(inode, &istr, &disk_link);
- if (err < 0)
- goto err_out;
-
- p_len = encrypted_symlink_data_len(disk_link.len) + 1;
-
- if (p_len > dir->i_sb->s_blocksize) {
- err = -ENAMETOOLONG;
+ if (!f2fs_encrypted_inode(inode)) {
+ err = -EPERM;
goto err_out;
}
- sd = kzalloc(p_len, GFP_NOFS);
- if (!sd) {
- err = -ENOMEM;
Re: [PATCH 10/14] ARM: dts: sun8i-a83t: Add PRCM related clocks and resets
On Mon, Feb 15, 2016 at 5:34 PM, Chen-Yu Tsai wrote:
> On Sat, Feb 13, 2016 at 12:43 AM, Chen-Yu Tsai wrote:
>> On Sat, Feb 13, 2016 at 12:06 AM, Vishnu Patekar
>> wrote:
>>> Hello Wens,
>>>
>>>
>>> On Tue, Feb 2, 2016 at 2:44 PM, Chen-Yu Tsai wrote:
On Sun, Jan 31, 2016 at 9:21 AM, Vishnu Patekar
wrote:
> This adds A83T PRCM related clocks, clock resets.
>
> As a83t apb0 gates clock support is added earlier, this enables it.
> Apart from apb0 gates, other added clocks are compatible with
> earlier sun8i socs.
>
> Signed-off-by: Vishnu Patekar
> ---
> arch/arm/boot/dts/sun8i-a83t.dtsi | 44
> +++
> 1 file changed, 44 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
> b/arch/arm/boot/dts/sun8i-a83t.dtsi
> index ac96aa1..5ea20ff 100644
> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
> @@ -268,6 +268,44 @@
> "mmc2_output",
> "mmc2_sample";
> };
> +
> + cpus_clk: clk@01f01400 {
> + compatible = "allwinner,sun9i-a80-cpus-clk";
> + reg = <0x01f01400 0x4>;
> + #clock-cells = <0>;
> + clocks = <&osc16Md512>, <&osc24M>, <&pll6>,
> <&osc16M>;
> + clock-output-names = "cpus";
> + };
> +
> + ahb0: ahb0_clk {
> + compatible = "fixed-factor-clock";
> + #clock-cells = <0>;
> + clock-div = <1>;
> + clock-mult = <1>;
> + clocks = <&cpus_clk>;
> + clock-output-names = "ahb0";
> + };
> +
> + apb0: clk@01f0140c {
> + compatible = "allwinner,sun8i-a23-apb0-clk";
This is actually wrong, as it is wrong in sun9i-a80.dtsi.
I've sent a patch series for it.
>>> A83T apb0 is different from A80, and it's same as A23, so this should
>>> be correct.
>>> Please correct me in case I'm missing something.
>>
>> My user manual (v1.5.1) says A83T apb0 dividers (page. 246) are
>> /1, /2, /3, /4, while the A23 is /1, /2, /4, /8.
>
> As Vishnu pointed out on IRC, the A23 driver is wrong. They are in fact,
> both one-based dividers. I'll send a patch to fix this.
^^^
zero-based
And for this patch,
Acked-by: Chen-Yu Tsai
>
> ChenYu
>
>> ChenYu
>>
Also the drivers for "allwinner,sun9i-a80-cpus-clk" and
"allwinner,sun9i-a80-apbs-clk"
are only compiled for CONFIG_MACH_SUN9I. Please add a patch to address
this.
>>> Okie.
Regards
ChenYu
> + reg = <0x01f0140c 0x4>;
> + #clock-cells = <0>;
> + clocks = <&ahb0>;
> + clock-output-names = "apb0";
> + };
> +
> + apb0_gates: clk@01f01428 {
> + compatible =
> "allwinner,sun8i-a83t-apb0-gates-clk";
> + reg = <0x01f01428 0x4>;
> + #clock-cells = <1>;
> + clocks = <&apb0>;
> + clock-indices = <0>, <1>,
> + <2>, <3>,
> + <4>, <6>, <7>;
> + clock-output-names = "apb0_pio", "apb0_ir",
> + "apb0_timer", "apb0_rsb",
> + "apb0_uart", "apb0_i2c0",
> "apb0_twd";
> + };
> };
>
> soc {
> @@ -434,5 +472,11 @@
> #interrupt-cells = <3>;
> interrupts = IRQ_TYPE_LEVEL_HIGH)>;
> };
> +
> + apb0_reset: reset@01f014b0 {
> + reg = <0x01f014b0 0x4>;
> + compatible = "allwinner,sun6i-a31-clock-reset";
> + #reset-cells = <1>;
> + };
> };
> };
> --
> 1.9.1
>
Re: [PATCH v2] mfd: ab8500: Provide a small example using new MFD cell MACROs
On Wed, Feb 10, 2016 at 4:39 PM, Lee Jones wrote: > mfd: ab8500: Provide a small example using new MFD cell MACROs > > Signed-off-by: Lee Jones Oh, that's pretty. Acked-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH] iio: adc/imx25-gcq: move incorrect do_div
Hi,
On Friday, February 12, 2016 12:15:29 PM Arnd Bergmann wrote:
> The newly added driver uses do_div() to device a 32-bit number, which now
> provokes a warning:
>
> drivers/iio/adc/fsl-imx25-gcq.c: In function 'mx25_gcq_setup_cfgs':
> include/asm-generic/div64.h:207:28: warning: comparison of distinct pointer
> types lacks a cast
> (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
>
> This replaces the do_div() call with a straight division operator.
>
> Signed-off-by: Arnd Bergmann
> Fixes: 6df2e98c3ea5 ("iio: adc: Add imx25-gcq ADC driver")
Thanks for fixing this.
Reviewed-by: Markus Pargmann
Best Regards,
Markus
> ---
> drivers/iio/adc/fsl-imx25-gcq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iio/adc/fsl-imx25-gcq.c b/drivers/iio/adc/fsl-imx25-gcq.c
> index 2fd192735d5b..72b32c1ab257 100644
> --- a/drivers/iio/adc/fsl-imx25-gcq.c
> +++ b/drivers/iio/adc/fsl-imx25-gcq.c
> @@ -233,7 +233,7 @@ static int mx25_gcq_setup_cfgs(struct platform_device
> *pdev,
> priv->channel_vref_mv[reg] =
> regulator_get_voltage(priv->vref[refp]);
> /* Conversion from uV to mV */
> - do_div(priv->channel_vref_mv[reg], 1000);
> + priv->channel_vref_mv[reg] /= 1000;
> break;
> case MX25_ADC_REFP_INT:
> priv->channel_vref_mv[reg] = 2500;
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH RESEND] arm64: add alignment fault hanling
On Mon, Feb 15, 2016 at 08:58:32AM +, EunTaik Lee wrote:
> Userspace memory is mapped as below:
> F2A7F000--F2A7 Normal Memory
> F2A8--F2A80FFF Device nGnRnE
How do you end up with Device nGnRnE in user space? I thought we should
have got some guard page.
> And that userspace application makes a system call
> as below:
>
> -009 |do_strncpy_from_user(inline)
> -009 |strncpy_from_user()
> -010 |getname_flags()
> -011 |user_path_at_empty()
> -012 |user_path_at()
> -013 |SYSC_faccessat(inline)
> -013 |sys_faccessat()
> -014 |__sys_trace(asm)
> --> |exception
>
> The string spans from 0xF2A7FFC1 to 0xF2A7FFFB.
>
> When do_strncpy_from_user() reads the last (unsigned long)
> value, the alignement fault is triggered. The 8 byte
> from 0xF2A7FFC1 spans to the next page that is mapped as
> Device nGnRnE, which does not allow an unaligned access,
> causes the abort.
do_strncpy_from_user() relies on unsafe_get_user() not being able to
read 8 bytes. The problem now is that it doesn't get a page fault but an
alignment one is isn't handled.
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index 19211c4..8257d4f 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -371,6 +371,16 @@ static int __kprobes do_translation_fault(unsigned long
> addr,
> return 0;
> }
>
> +static int __kprobes do_alignment_fault(unsigned long addr,
> + unsigned int esr,
> + struct pt_regs *regs)
> +{
> + if (addr >= TASK_SIZE && fixup_exception(regs))
> + return 0;
> +
> + return 1;
> +}
Why addr >= TASK_SIZE? addr here should be the fault address, not pc.
> +
> /*
> * This abort handler always returns "fault".
> */
> @@ -418,7 +428,7 @@ static struct fault_info {
> { do_bad, SIGBUS, 0, "synchronous parity error (translation table walk" },
> { do_bad, SIGBUS, 0, "synchronous parity error (translation table walk" },
> { do_bad, SIGBUS, 0, "unknown 32" },
> - { do_bad, SIGBUS, BUS_ADRALN, "alignment fault" },
> + { do_alignment_fault, SIGBUS, BUS_ADRALN, "alignment fault" },
The simplest would be to use do_bad_area() here without any additional
function.
--
Catalin
Re: [PATCH v1 3/6] rockchip: power-domain: add support for sub-power domains
在 2016/2/15 16:38, Elaine Zhang 写道:
This patch adds support for making one power domain a sub-domain of
other domain. This is useful for modeling power dependences,
which needs to have more than one power domain enabled to be operational.
Signed-off-by: Elaine Zhang
---
drivers/soc/rockchip/pm_domains.c | 51 +++
1 file changed, 51 insertions(+)
diff --git a/drivers/soc/rockchip/pm_domains.c
b/drivers/soc/rockchip/pm_domains.c
index 350527b..c4c2aea 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -372,6 +372,51 @@ static void rockchip_configure_pd_cnt(struct rockchip_pmu
*pmu,
regmap_write(pmu->regmap, domain_reg_offset + 4, count);
}
+static int rockchip_pm_add_subdomain(struct rockchip_pmu *pmu,
+struct device_node *parent)
+{
+ struct device_node *np;
+ int error;
+
+ for_each_child_of_node(parent, np) {
+ struct generic_pm_domain *child_domain, *parent_domain;
+ u32 idx = ~0;
+
+ if (of_property_read_u32(parent, "reg", &idx)) {
+ dev_err(pmu->dev,
+ "%s: failed to retrieve domain id (reg)\n",
+ parent->name);
+ return -EINVAL;
miss of_node_put.
+ }
+ parent_domain = pmu->genpd_data.domains[idx];
+
+ error = rockchip_pm_add_one_domain(pmu, np);
+ if (error) {
+ dev_err(pmu->dev, "failed to handle node %s: %d\n",
+ np->name, error);
+ return -ENODEV;
Ditto
+ }
+
+ if (of_property_read_u32(np, "reg", &idx)) {
+ dev_err(pmu->dev,
+ "%s: failed to retrieve domain id (reg)\n",
+ np->name);
+ return -EINVAL;
Ditto
+ }
+ child_domain = pmu->genpd_data.domains[idx];
+
+ if (pm_genpd_add_subdomain(parent_domain, child_domain))
+ pr_warn("%s failed to add subdomain: %s\n",
+ parent_domain->name, child_domain->name);
+ else
+ pr_warn("%s add subdomain: %s\n",
+ parent_domain->name, child_domain->name);
+
+ rockchip_pm_add_subdomain(pmu, np);
+ }
+ return 0;
+}
+
static int rockchip_pm_domain_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -437,6 +482,12 @@ static int rockchip_pm_domain_probe(struct platform_device
*pdev)
node->name, error);
goto err_out;
}
+ error = rockchip_pm_add_subdomain(pmu, node);
+ if (error < 0) {
+ dev_err(dev, "failed to handle subdomain node %s: %d\n",
+ node->name, error);
+ goto err_out;
+ }
}
if (error) {
Re: arm qemu test failures due to 'driver-core: platform: probe of-devices only using list of compatibles'
On Mon, Feb 15, 2016 at 10:14:06AM +0100, Uwe Kleine-König wrote: > Hello Russell, > > On Mon, Feb 15, 2016 at 08:58:18AM +, Russell King - ARM Linux wrote: > > On Mon, Feb 15, 2016 at 09:17:50AM +0100, Uwe Kleine-König wrote: > > > On Sun, Feb 14, 2016 at 08:07:55PM +, Russell King - ARM Linux wrote: > > > > On Sun, Feb 14, 2016 at 08:55:01PM +0100, Uwe Kleine-König wrote: > > > > > So the unexpected abnormality here is that even though this device is > > > > > instantiated by dt, the driver doesn't provide any compatibles. > > > > > Either my expectation is wrong, then 67d02a1bbb33455 should be > > > > > reverted > > > > > > > > Your expectation is wrong. AMBA primecell devices have hardware IDs > > > > and are matched to their drivers by those IDs. Just like PCI. > > > > > > pci devices don't appear in dt, do they? I don't see the connection > > > between amba devices and platform devices, see my other mail in this > > > thread for some more details. > > > > They both have hardware IDs, and they are both matched via those hardware > > IDs. > > I changed platform_match which is about matching by dt compatible, acpi > and/or device name. I don't see how this can affect an amba device given > they match to a driver by a hardware id. > > > Your change has introduced a regression and is therefore wrong. > > I'd like to understand though why and how my commit is wrong to be able > to fix it instead of getting it reverted. I don't have the commit, and I haven't seen the patch so I can't comment further, sorry. -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
Re: [PATCH v2 3/3] mm/compaction: speed up pageblock_pfn_to_page() when zone is contiguous
On 2016/2/15 10:42, Joonsoo Kim wrote: >> >> I have a question about the zone continuity. because hole exists at >> arbitrary position in a page block. Therefore, only pageblock_pf_to_page() >> is insufficiency, whether pageblock aligned pfn or not , the >> pfn_valid_within() >> is necessary. >> >> eh: 120M-122M is a range of page block, but the 120.5M-121.5M is holes, only >> by >> pageblock_pfn_to_page() to conclude in the result is inaccurate > > contiguous may be misleading word. It doesn't represent there are no > hole. It only represents that all pageblocks within zone span belong to > corresponding zone and validity of all pageblock aligned pfn is > checked. So, if it is set, we can safely call pfn_to_page() for pageblock > aligned pfn in that zone without checking pfn_valid(). > > Thanks. > Hi Joonsoo, So "contiguous" here only means that struct page is exist, and don't care whether the memory is exist, right? Thanks, Xishi Qiu > > . >
Re: [PATCH v4 2/8] [media] VPU: mediatek: support Mediatek VPU
Hi Tiffany,
A small review comment below:
On 02/04/2016 12:34 PM, Tiffany Lin wrote:
> The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs.
> It is able to handle video decoding/encoding of in a range of formats.
> The driver provides with VPU firmware download, memory management and
> the communication interface between CPU and VPU.
> For VPU initialization, it will create virtual memory for CPU access and
> IOMMU address for vcodec hw device access. When a decode/encode instance
> opens a device node, vpu driver will download vpu firmware to the device.
> A decode/encode instant will decode/encode a frame using VPU
> interface to interrupt vpu to handle decoding/encoding jobs.
>
> Signed-off-by: Andrew-CT Chen
> Signed-off-by: Tiffany Lin
> ---
> drivers/media/platform/Kconfig |9 +
> drivers/media/platform/Makefile |2 +
> drivers/media/platform/mtk-vpu/Makefile |1 +
> drivers/media/platform/mtk-vpu/mtk_vpu.c | 994
> ++
> drivers/media/platform/mtk-vpu/mtk_vpu.h | 167 +
> 5 files changed, 1173 insertions(+)
> create mode 100644 drivers/media/platform/mtk-vpu/Makefile
> create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.c
> create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.h
>
> diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.c
> b/drivers/media/platform/mtk-vpu/mtk_vpu.c
> new file mode 100644
> index 000..f54fd89
> --- /dev/null
> +++ b/drivers/media/platform/mtk-vpu/mtk_vpu.c
> @@ -0,0 +1,994 @@
> +static ssize_t vpu_debug_read(struct file *file, char __user *user_buf,
> + size_t count, loff_t *ppos)
> +{
> + char buf[256];
> + unsigned int len;
> + unsigned int running, pc, vpu_to_host, host_to_vpu, wdt;
> + int ret;
> + struct device *dev = file->private_data;
> + struct mtk_vpu *vpu = dev_get_drvdata(dev);
> +
> + ret = vpu_clock_enable(vpu);
> + if (ret) {
> + dev_err(vpu->dev, "[VPU] enable clock failed %d\n", ret);
> + return 0;
> + }
> +
> + /* vpu register status */
> + running = vpu_running(vpu);
> + pc = vpu_cfg_readl(vpu, VPU_PC_REG);
> + wdt = vpu_cfg_readl(vpu, VPU_WDT_REG);
> + host_to_vpu = vpu_cfg_readl(vpu, HOST_TO_VPU);
> + vpu_to_host = vpu_cfg_readl(vpu, VPU_TO_HOST);
> + vpu_clock_disable(vpu);
> +
> + if (running) {
> + len = sprintf(buf, "VPU is running\n\n"
Please use snprintf.
> + "FW Version: %s\n"
> + "PC: 0x%x\n"
> + "WDT: 0x%x\n"
> + "Host to VPU: 0x%x\n"
> + "VPU to Host: 0x%x\n",
> + vpu->run.fw_ver, pc, wdt,
> + host_to_vpu, vpu_to_host);
> + } else {
> + len = sprintf(buf, "VPU not running\n");
Ditto.
sprintf always makes me feel uncomfortable :-)
> + }
> +
> + return simple_read_from_buffer(user_buf, count, ppos, buf, len);
> +}
Regards,
Hans
Re: arm qemu test failures due to 'driver-core: platform: probe of-devices only using list of compatibles'
Hello Russell, On Mon, Feb 15, 2016 at 10:04:15AM +, Russell King - ARM Linux wrote: > On Mon, Feb 15, 2016 at 10:14:06AM +0100, Uwe Kleine-König wrote: > > On Mon, Feb 15, 2016 at 08:58:18AM +, Russell King - ARM Linux wrote: > > > On Mon, Feb 15, 2016 at 09:17:50AM +0100, Uwe Kleine-König wrote: > > > > On Sun, Feb 14, 2016 at 08:07:55PM +, Russell King - ARM Linux > > > > wrote: > > > > > On Sun, Feb 14, 2016 at 08:55:01PM +0100, Uwe Kleine-König wrote: > > > > > > So the unexpected abnormality here is that even though this device > > > > > > is > > > > > > instantiated by dt, the driver doesn't provide any compatibles. > > > > > > Either my expectation is wrong, then 67d02a1bbb33455 should be > > > > > > reverted > > > > > > > > > > Your expectation is wrong. AMBA primecell devices have hardware IDs > > > > > and are matched to their drivers by those IDs. Just like PCI. > > > > > > > > pci devices don't appear in dt, do they? I don't see the connection > > > > between amba devices and platform devices, see my other mail in this > > > > thread for some more details. > > > > > > They both have hardware IDs, and they are both matched via those hardware > > > IDs. > > > > I changed platform_match which is about matching by dt compatible, acpi > > and/or device name. I don't see how this can affect an amba device given > > they match to a driver by a hardware id. > > > > > Your change has introduced a regression and is therefore wrong. > > > > I'd like to understand though why and how my commit is wrong to be able > > to fix it instead of getting it reverted. > > I don't have the commit, and I haven't seen the patch so I can't > comment further, sorry. It's in -next. For a quick look: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=67d02a1bbb33455 Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: Nokia N900: Proper C-states
On Thursday 11 February 2016 09:47:50 Tony Lindgren wrote: > * Pali Rohár [160211 07:03]: > > > On 02/09/2016 04:56 PM, Tony Lindgren wrote: > > > >I'm almost certain those values are not n900 specific but should be > > > >used for omap3430 in general. > > > > cpuidle parameters for Nokia N900 were added by this commit: > > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5a1b1d3a9efad6bd53d01ff02e86626d1a51d697 > > > > which says: > > > > Numbers based on measurements made in October 2009 for PM optimized > > kernel with CPU freq enabled. > > > > Tony, do you have any other omap3430 device? > > Yes I can make sure it works for omap3-ldp for a minimal case. > That's a 3430 ES 3.0 that's a GP SoC. > > Regards, > > Tony Ok. If it works and you think those values are not Nokia N900 specific, but omap3430, we can add them into kernel. Do you want me to prepare patch? Or will you do it? -- Pali Rohár pali.ro...@gmail.com
Re: [PATCH v4 2/8] [media] VPU: mediatek: support Mediatek VPU
On 02/04/2016 12:34 PM, Tiffany Lin wrote: > The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs. > It is able to handle video decoding/encoding of in a range of formats. > The driver provides with VPU firmware download, memory management and > the communication interface between CPU and VPU. > For VPU initialization, it will create virtual memory for CPU access and > IOMMU address for vcodec hw device access. When a decode/encode instance > opens a device node, vpu driver will download vpu firmware to the device. > A decode/encode instant will decode/encode a frame using VPU > interface to interrupt vpu to handle decoding/encoding jobs. > > Signed-off-by: Andrew-CT Chen > Signed-off-by: Tiffany Lin > --- > drivers/media/platform/Kconfig |9 + > drivers/media/platform/Makefile |2 + > drivers/media/platform/mtk-vpu/Makefile |1 + > drivers/media/platform/mtk-vpu/mtk_vpu.c | 994 > ++ > drivers/media/platform/mtk-vpu/mtk_vpu.h | 167 + > 5 files changed, 1173 insertions(+) > create mode 100644 drivers/media/platform/mtk-vpu/Makefile > create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.c > create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.h > > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig > index ccbc974..ba812d6 100644 > --- a/drivers/media/platform/Kconfig > +++ b/drivers/media/platform/Kconfig > @@ -148,6 +148,15 @@ config VIDEO_CODA > Coda is a range of video codec IPs that supports > H.264, MPEG-4, and other video formats. > > +config VIDEO_MEDIATEK_VPU > + tristate "Mediatek Video Processor Unit" > + depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MEDIATEK > + ---help--- > + This driver provides downloading VPU firmware and > + communicating with VPU. This driver for hw video > + codec embedded in new Mediatek's SOCs. It is able > + to handle video decoding/encoding in a range of formats. Can you be more specific in this text and mention for which Mediatek SoCs this driver is for? Just like you did in the commit log. Also add something like this: To compile this driver as a module, choose M here: the module will be called mtk-vpu. I always find it useful if the Kconfig text mentions the module name. Regards, Hans > + > config VIDEO_MEM2MEM_DEINTERLACE > tristate "Deinterlace support" > depends on VIDEO_DEV && VIDEO_V4L2 && DMA_ENGINE
Re: arm qemu test failures due to 'driver-core: platform: probe of-devices only using list of compatibles'
On Mon, Feb 15, 2016 at 11:10:14AM +0100, Uwe Kleine-König wrote: > Hello Russell, > > On Mon, Feb 15, 2016 at 10:04:15AM +, Russell King - ARM Linux wrote: > > On Mon, Feb 15, 2016 at 10:14:06AM +0100, Uwe Kleine-König wrote: > > > On Mon, Feb 15, 2016 at 08:58:18AM +, Russell King - ARM Linux wrote: > > > > On Mon, Feb 15, 2016 at 09:17:50AM +0100, Uwe Kleine-König wrote: > > > > > On Sun, Feb 14, 2016 at 08:07:55PM +, Russell King - ARM Linux > > > > > wrote: > > > > > > On Sun, Feb 14, 2016 at 08:55:01PM +0100, Uwe Kleine-König wrote: > > > > > > > So the unexpected abnormality here is that even though this > > > > > > > device is > > > > > > > instantiated by dt, the driver doesn't provide any compatibles. > > > > > > > Either my expectation is wrong, then 67d02a1bbb33455 should be > > > > > > > reverted > > > > > > > > > > > > Your expectation is wrong. AMBA primecell devices have hardware IDs > > > > > > and are matched to their drivers by those IDs. Just like PCI. > > > > > > > > > > pci devices don't appear in dt, do they? I don't see the connection > > > > > between amba devices and platform devices, see my other mail in this > > > > > thread for some more details. > > > > > > > > They both have hardware IDs, and they are both matched via those > > > > hardware > > > > IDs. > > > > > > I changed platform_match which is about matching by dt compatible, acpi > > > and/or device name. I don't see how this can affect an amba device given > > > they match to a driver by a hardware id. > > > > > > > Your change has introduced a regression and is therefore wrong. > > > > > > I'd like to understand though why and how my commit is wrong to be able > > > to fix it instead of getting it reverted. > > > > I don't have the commit, and I haven't seen the patch so I can't > > comment further, sorry. > > It's in -next. For a quick look: > > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=67d02a1bbb33455 Well, if that's only touching the platform device matching, it can't have any effect on AMBA bus matching, which uses completely different code. The AMBA bus code is entirely separate from platform devices. -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
Re: linux-next: build failure after merge of the akpm-current tree
On Thu, 11 Feb 2016, Stephen Rothwell wrote: > Or the trivial tree should be based on v4.5-rc1 not v4.3 (in which case > this patch belongs as part of ee49ac85bc24b946 (and presumably would > have been found in testing of the trivial tree alone). This was indeed applied to wrong base, my error, sorry for that. I will drop this now from my tree and we'll merge it properly later; best thing would probably be to send it directly to Linus at the very end of merge window. Thanks for noticing, -- Jiri Kosina SUSE Labs
Re: Nokia N900: Proper C-states
On Thursday 11 February 2016 16:02:21 Pali Rohár wrote: > On Tuesday 09 February 2016 18:06:26 Daniel Lezcano wrote: > > On 02/09/2016 04:56 PM, Tony Lindgren wrote: > > >* Daniel Lezcano [160102 14:01]: > > >>On 01/02/2016 03:26 PM, Pali Rohár wrote: > > >>>Hello, > > >>> > > >>>due to this Daniel Lezcano commit (ARM: OMAP3: cpuidle - remove rx51 > > >>>cpuidle parameters table) > > >>> > > >>>https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=231900afba52d6faddfb480cde4132d4edc089bc > > >>> > > >>>we need patch cpuidle34xx.c code to fix commit for Nokia N900. See: > > >>> > > >>>https://github.com/pali/linux-n900/commit/e147fd4b678f1f3d7a5235287910960bd41e04dc > > >>> > > >>>As Nokia N900 code is converting from legacy board code to DST, I would > > >>>like to know how to patch correctly omap3_idle_driver in DTS with > > >>>correct values measured for Nokia N900. Thanks! > > > > > >I'm almost certain those values are not n900 specific but should be > > >used for omap3430 in general. > > > > > cpuidle parameters for Nokia N900 were added by this commit: > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5a1b1d3a9efad6bd53d01ff02e86626d1a51d697 > > which says: > > Numbers based on measurements made in October 2009 for PM optimized > kernel with CPU freq enabled. Adding Kalle Jokiniemi, author of that commit which added cpuidle parameters for Nokia N900. Kalle, do you know if cpuidle values measured are Nokia N900 specific or general omap3430? -- Pali Rohár pali.ro...@gmail.com
Re: [PATCH] sched/deadline: Always calculate end of period on sched_yield()
Hi, On 12/02/16 18:10, Steven Rostedt wrote: > I'm writing a test case for SCHED_DEADLINE, and notice a strange > anomaly. Every so often, a deadline is missed and when I looked into > it, it happened because the sched_yield() had no effect (it didn't end > the previous period and let the start of the next runtime happen on the > end of the old period). > > deadline-22287...1 116.778420: sys_enter_sched_yield: > deadline-22287d..3 116.778421: hrtimer_cancel: > hrtimer=0x88011ebd79a0 > deadline-22287d..2 116.778422: rcu_utilization: Start context > switch > deadline-22287d..2 116.778423: rcu_utilization: End context switch > deadline-22287d..4 116.778423: hrtimer_start: > hrtimer=0x88011ebd79a0 function=hrtick/0x0 expires=116124420428 > softexpires=116124420428 > deadline-22287...1 116.778425: sys_exit_sched_yield: 0x0 > > > Schedule was never called. A added some trace_printks() and discovered > that this happens when sched_yield() is called right after a tick that > updates its current bandwidth. > > When the schedule tick happens that updates the current bandwidth, > update_curr_dl() is called, where it updates curr->se.exec_start to > rq_clock_task(rq). > > The rq_clock_task(rq) gets updated by update_rq_clock_task() that gets > update by various points in the scheduler. > > Now, if the user task calls sched_yield() just after a bandwidth update > synced curr->se.exec_start to rq_clock_task(rq), when sched_yield() > calls into update_curr_dl() we have: > > delta_exec = rq_clock_task(rq) - curr->se.exec_start; > if (unlikely((s64)delta_exec <= 0)) > return; > > Coming in here from a sched_yield() will have delta_exec == 0 if the > sched_yield() was called after a DL tick and before another > update_rq_clock_task() is called. > > This means that the task will not release its remaining runtime, and > the will start off in the current period when it expected to be in the > next period. > > The fix that appears to work for me is to add a test in > update_curr_dl() to not exit if delta_exec is zero and > dl_se->dl_yielded is true. > > Signed-off-by: Steven Rostedt > --- > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c > index cd64c979d0e1..1dd180cda574 100644 > --- a/kernel/sched/deadline.c > +++ b/kernel/sched/deadline.c > @@ -735,7 +735,7 @@ static void update_curr_dl(struct rq *rq) >* approach need further study. >*/ > delta_exec = rq_clock_task(rq) - curr->se.exec_start; > - if (unlikely((s64)delta_exec <= 0)) > + if (unlikely((s64)delta_exec <= 0 && !dl_se->dl_yielded)) > return; > This looks good to me. Do you think we could also skip some of the following updates/accounting in this case? Not sure we win anything by doing that, though. Thanks, - Juri
Re: patch to fix small grammar error
On Thu, 11 Feb 2016, Justin Keller wrote: > Hello, > I have a small patch to the memory-hotplug documentation. One line > adds a comma, and the other line adds an and. > > Justin Keller Justin, your patch is missing a Signed-off-by: line (please read Documentation/SubmittingPatches) and also your mail client damaged the diff so that it can't be applied (please see some hints in Documentation/email-clients.txt). -- Jiri Kosina SUSE Labs
Re: sound: memory leak in snd_seq_pool_init
On Mon, 15 Feb 2016 10:35:22 +0100,
Dmitry Vyukov wrote:
>
> Hello,
>
> The following program causes memory leak of a 24K object allocated in
> snd_seq_pool_init:
>
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include
> #include
> #include
> #include
> #include
>
> long r[148];
>
> void* thr(void* arg)
> {
> switch ((long)arg) {
> case 0:
> r[0] = syscall(SYS_mmap, 0x2000ul, 0xe000ul, 0x3ul, 0x32ul,
>0xul, 0x0ul);
> break;
> case 1:
> r[2] = syscall(SYS_open, "/dev/snd/seq", 0x1ul, 0, 0, 0);
> break;
> case 2:
> *(uint32_t*)0x20008a90 = (uint32_t)0x6;
> *(uint32_t*)0x20008a94 = (uint32_t)0x4;
> *(uint32_t*)0x20008a98 = (uint32_t)0x200;
> *(uint8_t*)0x20008a9c = (uint8_t)0xfa5;
> *(uint8_t*)0x20008a9d = (uint8_t)0x1;
> *(uint8_t*)0x20008a9e = (uint8_t)0x0;
> *(uint8_t*)0x20008a9f = (uint8_t)0x3;
> *(uint8_t*)0x20008aa0 = (uint8_t)0x1;
> *(uint8_t*)0x20008aa1 = (uint8_t)0x1;
> *(uint8_t*)0x20008aa2 = (uint8_t)0x0;
> *(uint8_t*)0x20008aa3 = (uint8_t)0x40;
> *(uint8_t*)0x20008aa4 = (uint8_t)0x9;
> *(uint8_t*)0x20008aa5 = (uint8_t)0x9;
> *(uint8_t*)0x20008aa6 = (uint8_t)0x6;
> *(uint8_t*)0x20008aa7 = (uint8_t)0x80;
> *(uint8_t*)0x20008aa8 = (uint8_t)0x0;
> *(uint8_t*)0x20008aa9 = (uint8_t)0x5d34b2c3;
> *(uint8_t*)0x20008aaa = (uint8_t)0x3a7;
> *(uint8_t*)0x20008aab = (uint8_t)0x9;
> *(uint8_t*)0x20008aac = (uint8_t)0x8d62;
> *(uint8_t*)0x20008aad = (uint8_t)0x5;
> *(uint8_t*)0x20008aae = (uint8_t)0x7;
> *(uint8_t*)0x20008aaf = (uint8_t)0x20;
> *(uint8_t*)0x20008ab0 = (uint8_t)0x8;
> *(uint8_t*)0x20008ab1 = (uint8_t)0x7;
> *(uint8_t*)0x20008ab2 = (uint8_t)0xfffc;
> *(uint8_t*)0x20008ab3 = (uint8_t)0x7;
> *(uint8_t*)0x20008ab4 = (uint8_t)0x7ff;
> *(uint8_t*)0x20008ab5 = (uint8_t)0x1;
> *(uint8_t*)0x20008ab6 = (uint8_t)0x0;
> *(uint8_t*)0x20008ab7 = (uint8_t)0x9;
> *(uint8_t*)0x20008ab8 = (uint8_t)0x6;
> *(uint8_t*)0x20008ab9 = (uint8_t)0xfe00;
> *(uint8_t*)0x20008aba = (uint8_t)0x1000;
> *(uint8_t*)0x20008abb = (uint8_t)0xfffb;
> *(uint8_t*)0x20008abc = (uint8_t)0xcfd3;
> *(uint8_t*)0x20008abd = (uint8_t)0x101;
> *(uint8_t*)0x20008abe = (uint8_t)0x9;
> *(uint8_t*)0x20008abf = (uint8_t)0xfffc;
> *(uint8_t*)0x20008ac0 = (uint8_t)0xf2;
> *(uint8_t*)0x20008ac1 = (uint8_t)0x6;
> *(uint8_t*)0x20008ac2 = (uint8_t)0x0;
> *(uint8_t*)0x20008ac3 = (uint8_t)0x7fff;
> *(uint8_t*)0x20008ac4 = (uint8_t)0x4;
> *(uint8_t*)0x20008ac5 = (uint8_t)0x5;
> *(uint8_t*)0x20008ac6 = (uint8_t)0x4;
> *(uint8_t*)0x20008ac7 = (uint8_t)0x4;
> *(uint8_t*)0x20008ac8 = (uint8_t)0x20;
> *(uint8_t*)0x20008ac9 = (uint8_t)0x401;
> *(uint8_t*)0x20008aca = (uint8_t)0x6;
> *(uint8_t*)0x20008acb = (uint8_t)0x6;
> *(uint8_t*)0x20008acc = (uint8_t)0x5;
> *(uint8_t*)0x20008acd = (uint8_t)0x3;
> *(uint8_t*)0x20008ace = (uint8_t)0xfffc;
> *(uint8_t*)0x20008acf = (uint8_t)0xb0c;
> *(uint8_t*)0x20008ad0 = (uint8_t)0x2;
> *(uint8_t*)0x20008ad1 = (uint8_t)0xfff9;
> *(uint8_t*)0x20008ad2 = (uint8_t)0x8000;
> *(uint8_t*)0x20008ad3 = (uint8_t)0x5;
> *(uint8_t*)0x20008ad4 = (uint8_t)0xb0c;
> *(uint8_t*)0x20008ad5 = (uint8_t)0xfeff;
> *(uint8_t*)0x20008ad6 = (uint8_t)0x5;
> *(uint8_t*)0x20008ad7 = (uint8_t)0x101;
> *(uint8_t*)0x20008ad8 = (uint8_t)0xbfd;
> *(uint8_t*)0x20008ad9 = (uint8_t)0x7ff;
> *(uint8_t*)0x20008ada = (uint8_t)0x7f;
> *(uint8_t*)0x20008adb = (uint8_t)0x5;
> *(uint32_t*)0x20008adc = (uint32_t)0x6;
> *(uint8_t*)0x20008ae0 = (uint8_t)0x0;
> *(uint8_t*)0x20008ae1 = (uint8_t)0x0;
> *(uint8_t*)0x20008ae2 = (uint8_t)0x0;
> *(uint8_t*)0x20008ae3 = (uint8_t)0x0;
> *(uint8_t*)0x20008ae4 = (uint8_t)0x0;
> *(uint8_t*)0x20008ae5 = (uint8_t)0x0;
> *(uint8_t*)0x20008ae6 = (uint8_t)0x0;
> *(uint8_t*)0x20008ae7 = (uint8_t)0x0;
> *(uint8_t*)0x20008ae8 = (uint8_t)0x0;
> *(uint8_t*)0x20008ae9 = (uint8_t)0x0;
> *(uint8_t*)0x20008aea = (uint8_t)0x0;
> *(uint8_t*)0x20008aeb = (uint8_t)0x0;
> *(uint8_t*)0x20008aec = (uint8_t)0x0;
> *(uint8_t*)0x20008aed = (uint8_t)0x0;
> *(uint8_t*)0x20008aee = (uint8_t)0x0;
> *(uint8_t*)0x20008aef = (uint8_t)0x0;
> *(uint8_t*)0x20008af0 = (uint8_t)0x0;
> *(uint8_t*)0x20008af1 = (uint8_t)0x0;
> *(uint8_t*)0x20008af2 = (uint8_t)0x0;
> *(uint8_t*)0x20008af3 = (uint8_t)0x0;
> *(uint8_t*)0x20008af4 = (uint8_t)0x0;
> *(uint8_t*)0x20008af5 = (uint8_t)0x0;
> *(uint8_t*)0x20008af6 = (uint8_t)0x0;
> *(uint8_t*)0x20008af7 = (uint8_t)0x0;
> *(uint8_t*)0x20008af8 = (uint8_t)0x0;
> *(uint8_t*)0x20008af9 = (uint8_t)0x0;
> *(uint8_t*)0x20008afa = (uint8_t)0x0;
> *(uint8_t*)0x20008afb
Re: [PATCH v4 21/23] arm64: hw_breakpoint: Allow EL2 breakpoints if running in HYP
On Thu, Feb 11, 2016 at 06:40:02PM +, Marc Zyngier wrote:
> With VHE, we place kernel {watch,break}-points at EL2 to get things
> like kgdb and "perf -e mem:..." working.
>
> This requires a bit of repainting in the low-level encore/decode,
> but is otherwise pretty simple.
>
> Signed-off-by: Marc Zyngier
To the best of my knowledge, this patch is fine ;)
Reviewed-by: Catalin Marinas
Re: [PATCH v4 00/23] arm64: Virtualization Host Extension support
On Thu, Feb 11, 2016 at 07:10:50PM +, Marc Zyngier wrote: > On 11/02/16 19:07, Christoffer Dall wrote: > > On Thu, Feb 11, 2016 at 06:39:41PM +, Marc Zyngier wrote: > >> ARMv8.1 comes with the "Virtualization Host Extension" (VHE for > >> short), which enables simpler support of Type-2 hypervisors. > >> > >> This extension allows the kernel to directly run at EL2, and > >> significantly reduces the number of system registers shared between > >> host and guest, reducing the overhead of virtualization. > >> > >> In order to have the same kernel binary running on all versions of the > >> architecture, this series makes heavy use of runtime code patching. > >> > >> The first 22 patches massage the KVM code to deal with VHE and enable > >> Linux to run at EL2. The last patch catches an ugly case when VHE > >> capable CPUs are paired with some of their less capable siblings. This > >> should never happen, but hey... > >> > >> I have deliberately left out some of the more "advanced" > >> optimizations, as they are likely to distract the reviewer from the > >> core infrastructure, which is what I care about at the moment. > >> > >> Note: GDB is currently busted on VHE systems, as it checks for version > >> 6 on the debug architecture, while VHE is version 7. The > >> binutils people are on the case. > >> > >> This has been tested on the FVP_Base_SLV-V8-A model, and based on > >> v4.5-rc3 + kvmarm/master. I've put a branch out on: > >> > >> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git > >> kvm-arm64/vhe > > > > I'm happy with this series as it stands, we just need someone to take a > > look at that debug patch and be happy with it. > > I think Will is planning to have a go at it shortly. Once he and Catalin > are happy with the thing, I'll throw it into -next for a good shake. Fine by me but it would be good for Will to have a look, especially on the debug and perf stuff. -- Catalin
[PATCH v2 0/2] Disable rfkill hardblock if BIOS date > 2016
V1: https://lkml.org/lkml/2015/12/15/940 V2 changes: * Only affect on ideapad whose BIOS date > 2016 to avoid regression on existing ideapads. * Show has_hw_rfkill_switch in debugfs Ike Panhc (2): ideapad: No hardware switch after 2016 ideapad: show has_hw_rfkill_switch in debugfs drivers/platform/x86/ideapad-laptop.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) -- 1.9.1
[PATCH 1/2] ideapad: No hardware switch after 2016
There are complains on few ideapads that wireless is always hard blocked but there is no physical radio switch. For now, we need each user to report its dmi information and ignore hard blocks on their ideapad. With more and more ideapads available in market to maintain the dmi table becomes never-ended job. I've checked lenovo website and for recent design none of the ideapads has radio switch. I do not believe there will be in the future. Therefore to disable hard block according to BIOS date is reasonable approach. This patch will disable rfkill hardblock if BIOS year > 2015. Signed-off-by: Ike Panhc --- drivers/platform/x86/ideapad-laptop.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/platform/x86/ideapad-laptop.c b/drivers/platform/x86/ideapad-laptop.c index d78ee15..1b39074d 100644 --- a/drivers/platform/x86/ideapad-laptop.c +++ b/drivers/platform/x86/ideapad-laptop.c @@ -938,7 +938,10 @@ static int ideapad_acpi_add(struct platform_device *pdev) priv->cfg = cfg; priv->adev = adev; priv->platform_device = pdev; - priv->has_hw_rfkill_switch = !dmi_check_system(no_hw_rfkill_list); + if (!dmi_get_date(DMI_BIOS_DATE, &i, NULL, NULL)) + i = 2015; + priv->has_hw_rfkill_switch = (i < 2016) && + !dmi_check_system(no_hw_rfkill_list); ret = ideapad_sysfs_init(priv); if (ret) -- 1.9.1
[PATCH 2/2] ideapad: show has_hw_rfkill_switch in debugfs
It will be easier for user to report driver status about hardware radio switch. Signed-off-by: Ike Panhc --- drivers/platform/x86/ideapad-laptop.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/platform/x86/ideapad-laptop.c b/drivers/platform/x86/ideapad-laptop.c index 1b39074d..6e47f0f 100644 --- a/drivers/platform/x86/ideapad-laptop.c +++ b/drivers/platform/x86/ideapad-laptop.c @@ -226,6 +226,8 @@ static int debugfs_status_show(struct seq_file *s, void *data) seq_printf(s, "BL power value:\t%s\n", value ? "On" : "Off"); seq_printf(s, "=\n"); + seq_printf(s, "Has RF switch:\t%s\n", + priv->has_hw_rfkill_switch ? "Yes" : "No"); if (!read_ec_data(priv->adev->handle, VPCCMD_R_RF, &value)) seq_printf(s, "Radio status:\t%s(%lu)\n", value ? "On" : "Off", value); -- 1.9.1
[PATCH v6] powerpc32: provide VIRT_CPU_ACCOUNTING
This patch provides VIRT_CPU_ACCOUTING to PPC32 architecture.
PPC32 doesn't have the PACA structure, so we use the task_info
structure to store the accounting data.
In order to reuse on PPC32 the PPC64 functions, all u64 data has
been replaced by 'unsigned long' so that it is u32 on PPC32 and
u64 on PPC64
Signed-off-by: Christophe Leroy
---
Changes in v3: unlike previous version of the patch that was inspired
from IA64 architecture, this new version tries to reuse as much as
possible the PPC64 implementation.
PPC32 doesn't have PACA and past discusion on v2 version has shown
that it is not worth implementing a PACA in PPC32 architecture
(see below benh opinion)
benh: PACA is actually a data structure and you really really don't want it
on ppc32 :-) Having a register point to current works, having a register
point to per-cpu data instead works too (ie, change what we do today),
but don't introduce a PACA *please* :-)
Changes in v4: ACCOUNT_CPU_USER_ENTRY/EXIT() needed updates in other
places than entry_32.S and entry_64.S (reported by kbuild-robot)
Related defines in asm-offset.c need to be conditional to
CONFIG_VIRT_CPU_ACCOUNTING_NATIVE (reported by kbuild-robot)
Changes in v5: Using PPC_LL et PPC_STL instead of defining new macros
AC_LD and AC_STD
Changes in v6: jiffies64_to_cputime64() modified to avoid 64 bits
div and mod on PPC32
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/cputime.h | 9 +---
arch/powerpc/include/asm/exception-64s.h | 2 +-
arch/powerpc/include/asm/ppc_asm.h | 24 ++--
arch/powerpc/include/asm/reg.h | 1 +
arch/powerpc/include/asm/thread_info.h | 11 +
arch/powerpc/kernel/asm-offsets.c| 7 ++
arch/powerpc/kernel/entry_32.S | 17 ++
arch/powerpc/kernel/entry_64.S | 6 ++---
arch/powerpc/kernel/exceptions-64e.S | 4 ++--
arch/powerpc/kernel/time.c | 38 ++--
arch/powerpc/platforms/Kconfig.cputype | 1 -
12 files changed, 92 insertions(+), 29 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 3a557be..57ce4ff 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -159,6 +159,7 @@ config PPC
select ARCH_HAS_DEVMEM_IS_ALLOWED
select HAVE_ARCH_SECCOMP_FILTER
select ARCH_HAS_UBSAN_SANITIZE_ALL
+ select HAVE_VIRT_CPU_ACCOUNTING
config GENERIC_CSUM
def_bool CPU_LITTLE_ENDIAN
diff --git a/arch/powerpc/include/asm/cputime.h
b/arch/powerpc/include/asm/cputime.h
index e245255..c4c4b4d 100644
--- a/arch/powerpc/include/asm/cputime.h
+++ b/arch/powerpc/include/asm/cputime.h
@@ -90,11 +90,10 @@ static inline void setup_cputime_one_jiffy(void)
static inline cputime64_t jiffies64_to_cputime64(const u64 jif)
{
u64 ct;
- u64 sec;
+ u64 sec = jif;
/* have to be a little careful about overflow */
- ct = jif % HZ;
- sec = jif / HZ;
+ ct = do_div(sec, HZ);
if (ct) {
ct *= tb_ticks_per_sec;
do_div(ct, HZ);
@@ -230,7 +229,11 @@ static inline cputime_t clock_t_to_cputime(const unsigned
long clk)
#define cputime64_to_clock_t(ct) cputime_to_clock_t((cputime_t)(ct))
+#ifdef CONFIG_PPC64
static inline void arch_vtime_task_switch(struct task_struct *tsk) { }
+#else
+void arch_vtime_task_switch(struct task_struct *tsk);
+#endif
#endif /* __KERNEL__ */
#endif /* CONFIG_VIRT_CPU_ACCOUNTING_NATIVE */
diff --git a/arch/powerpc/include/asm/exception-64s.h
b/arch/powerpc/include/asm/exception-64s.h
index 93ae809..8bc38d1 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -287,7 +287,7 @@ do_kvm_##n:
\
std r0,GPR0(r1);/* save r0 in stackframe*/ \
std r10,GPR1(r1); /* save r1 in stackframe*/ \
beq 4f; /* if from kernel mode */ \
- ACCOUNT_CPU_USER_ENTRY(r9, r10); \
+ ACCOUNT_CPU_USER_ENTRY(r13, r9, r10); \
SAVE_PPR(area, r9, r10); \
4: EXCEPTION_PROLOG_COMMON_2(area)\
EXCEPTION_PROLOG_COMMON_3(n) \
diff --git a/arch/powerpc/include/asm/ppc_asm.h
b/arch/powerpc/include/asm/ppc_asm.h
index 499d9f8..07d1bfc 100644
--- a/arch/powerpc/include/asm/ppc_asm.h
+++ b/arch/powerpc/include/asm/ppc_asm.h
@@ -24,27 +24,27 @@
*/
#ifndef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
-#define ACCOUNT_CPU_USER_ENTRY(ra, rb)
-#define ACCOUNT_CPU_USER_EXIT(ra, rb)
+#define ACCOUNT_CPU_USER_ENTRY(ptr, ra, rb)
+#define ACCOUNT_CPU_USER_EXIT(ptr, ra, rb)
#define ACCOUNT_STOLEN_TIME
#else
-#define ACCOUNT_CPU_USER_ENTRY(ra, rb) \
+#def
Re: richacl(7) man page review comments
Hi Andreas, On 02/15/2016 12:12 AM, Andreas Gruenbacher wrote: > On Sun, Feb 14, 2016 at 10:27 PM, Michael Kerrisk (man-pages) > wrote: >> On 02/12/2016 11:25 PM, Andreas Gruenbacher wrote: >>> We could sure move acl(5) and richacl(7) there. >> >> We already have acl(5) (now "acl(7)" in man pages) ;-). > > Hmm, I can't find that page either in > git://git.kernel.org/pub/scm/docs/man-pages/man-pages or on > http://man7.org/. Are you sure you don't mean xattr.7 == attr.5 which > documents the xattr syscall interface? You're right. I was confusing with xattr(7). So, I think it might make some sense to eventually move both of these into man-pages (for richacl(7), at least, it's probably worth delaying this for a bit), since they're describing kernel-user-space interfaces. I can see counter-arguments too, such as these pages are closely related to the corresponding user-space libraries you maintain. What do you think? Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
Re: remap_file_pages regression
On Mon, Feb 15, 2016 at 03:32:55AM +0200, Grazvydas Ignotas wrote:
> Hi,
>
> since remap_file_pages() rework the following simple program fails.
> I haven't actually bisected this, only know it worked on 3.19 at least
> (I bought a new system now and need 4.2+ for hardware support).
The patch below should fix the issue. Please test.
> If you are curious, the program is an emulator and is using
> remap_file_pages() to implement memory mirroring efficiently (and to
> remap things during run time).
Could you elaborate on this?
Why creating file on tmpfs/shmem (using memfd_create() for example) plus
plain mmap()s wouldn't work for you?
>From 6b8690c3a983a72212db8cd35eb4cab106a195d4 Mon Sep 17 00:00:00 2001
From: "Kirill A. Shutemov"
Date: Mon, 15 Feb 2016 13:06:16 +0300
Subject: [PATCH] mm: fix regression in remap_file_pages() emulation
Grazvydas Ignotas has reported a regression in remap_file_pages()
emulation.
Testcase:
#define _GNU_SOURCE
#include
#include
#include
#include
#define SIZE(4096 * 3)
int main(int argc, char **argv)
{
unsigned long *p;
long i;
p = mmap(NULL, SIZE, PROT_READ | PROT_WRITE,
MAP_SHARED | MAP_ANONYMOUS, -1, 0);
if (p == MAP_FAILED) {
perror("mmap");
return -1;
}
for (i = 0; i < SIZE / 4096; i++)
p[i * 4096 / sizeof(*p)] = i;
if (remap_file_pages(p, 4096, 0, 1, 0)) {
perror("remap_file_pages");
return -1;
}
if (remap_file_pages(p, 4096 * 2, 0, 1, 0)) {
perror("remap_file_pages");
return -1;
}
assert(p[0] == 1);
munmap(p, SIZE);
return 0;
}
The second remap_file_pages() fails with -EINVAL.
The reason is that remap_file_pages() emulation assumes that the target
vma covers whole area we want to over map. That assumption is broken by
first remap_file_pages() call: it split the area into two vma.
The solution is to check next adjacent vmas, if they map the same file
with the same flags.
Signed-off-by: Kirill A. Shutemov
Reported-by: Grazvydas Ignotas
---
mm/mmap.c | 34 +-
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index 2f2415a7a688..76d1ec29149b 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2664,12 +2664,29 @@ SYSCALL_DEFINE5(remap_file_pages, unsigned long, start,
unsigned long, size,
if (!vma || !(vma->vm_flags & VM_SHARED))
goto out;
- if (start < vma->vm_start || start + size > vma->vm_end)
+ if (start < vma->vm_start)
goto out;
- if (pgoff == linear_page_index(vma, start)) {
- ret = 0;
- goto out;
+ if (start + size > vma->vm_end) {
+ struct vm_area_struct *next;
+
+ for (next = vma->vm_next; next; next = next->vm_next) {
+ /* hole between vmas ? */
+ if (next->vm_start != next->vm_prev->vm_end)
+ goto out;
+
+ if (next->vm_file != vma->vm_file)
+ goto out;
+
+ if (next->vm_flags != vma->vm_flags)
+ goto out;
+
+ if (start + size <= next->vm_end)
+ break;
+ }
+
+ if (!next)
+ goto out;
}
prot |= vma->vm_flags & VM_READ ? PROT_READ : 0;
@@ -2679,9 +2696,16 @@ SYSCALL_DEFINE5(remap_file_pages, unsigned long, start,
unsigned long, size,
flags &= MAP_NONBLOCK;
flags |= MAP_SHARED | MAP_FIXED | MAP_POPULATE;
if (vma->vm_flags & VM_LOCKED) {
+ struct vm_area_struct *tmp;
flags |= MAP_LOCKED;
+
/* drop PG_Mlocked flag for over-mapped range */
- munlock_vma_pages_range(vma, start, start + size);
+ for (tmp = vma; tmp->vm_start >= start + size;
+ tmp = tmp->vm_next) {
+ munlock_vma_pages_range(tmp,
+ max(tmp->vm_start, start),
+ min(tmp->vm_end, start + size));
+ }
}
file = get_file(vma->vm_file);
--
Kirill A. Shutemov
Re: [PATCH 2/4] block: check virt boundary in bio_will_gap()
On Mon, Feb 15, 2016 at 4:22 PM, Sagi Grimberg wrote:
>
>> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
>> index 4571ef1..b8ff6a3 100644
>> --- a/include/linux/blkdev.h
>> +++ b/include/linux/blkdev.h
>> @@ -1388,7 +1388,7 @@ static inline bool bvec_gap_to_prev(struct
>> request_queue *q,
>> static inline bool bio_will_gap(struct request_queue *q, struct bio
>> *prev,
>> struct bio *next)
>> {
>> - if (!bio_has_data(prev))
>> + if (!bio_has_data(prev) || !queue_virt_boundary(q))
>> return false;
>
>
> Can we not do that?
Given there are only 3 drivers which set virt boundary, I think
it is reasonable to do that.
>
> bvec_gap_to_prev is already checking the virt_boundary and I'd sorta
> like to keep the motivation to optimize bio_get_last_bvec() to be O(1).
Currently the approaches I thought of still need to iterate bvec by bvec,
not sure if O(1) can be reached easily, but I am happy to discuss the
optimized implementation.
Thanks,
Ming
Re: [PATCH v8 4/8] ppc64 ftrace_with_regs configuration variables
Hi guys,
Sorry I haven't been keeping up to date with this thread I've been away.
On Thu, 2016-02-11 at 09:42 +0100, Torsten Duwe wrote:
> On Thu, Feb 11, 2016 at 06:48:17PM +1100, Balbir Singh wrote:
> > On Wed, 2016-02-10 at 17:25 +0100, Torsten Duwe wrote:
> > > +
> > > +echo "int func() { return 0; }" | \
> > > +$* -S -x c -O2 -p -mprofile-kernel - -o - 2> /dev/null | \
> > > +sed -n -e '/func:/,/bl _mcount/p' | grep -q TOC
> > > +
> > > +leaf_toc_result=$?
> >
> > leaf_toc_result failed for me with gcc 5. I'll try and grab gcc-6
> > and give the patches a spin
>
> Don't bother. _All_ gccs are broken in that respect currently.
I'm not sure where we got our wires crossed on this one, but this is not a gcc
bug. In fact it's a feature :)
There is explicit code in gcc to check whether the TOC setup is needed and only
emit it when it's required. One case where it's *not* required is when the
function does not TOC accesses. (See rs6000_global_entry_point_needed_p()).
So I think this is just one of the "fun" details we have to deal with to
implement kernel tracing.
The first implication of this is that there is not a single offset value for
the _mcount call, it needs to be calculated per-function. In practice there
will only be two values, so we could try both, or we could just have the code
work it out dynamically by looking for the expected code sequence?
Secondly it means the ftrace trampoline needs to cope with being called with r2
containing something other than the kernel TOC (ie. a module's TOC pointer).
But I think that's solvable also?
cheers
[PATCH v2 00/10] mfd: axp20x: Add support for AXP809 PMIC
Hi everyone,
This is v2 of the AXP809 PMIC support series. This adds support for
X-Powers' AXP809 PMIC. This is the primary PMIC accompanying Allwinner's
A80 SoC. For now, only the power button (PEK) and regulators are
supported. These are supported using existing axp20x drivers. This is
based on the AXP223 series v8, as well as 2 patches from v1 that are
already in regulator/topic/axp20x.
Changes since v1:
- Added patch 4, changing default regulator names to lowercase.
- Dropped regulator nodes from axp809.dtsi.
Patch 1 adds a MAINTAINERS entry for the X-Powers AXP PMICs. I list
myself as the maintainer.
Patch 2 adds AXP809 to the axp20x bindings.
Patch 3 adds AXP809 support to the axp20x mfd driver.
Patch 4 changes the in-kernel default regulator names from uppercase to
lowercase, making it easier on the eye.
Patch 5 adds AXP809 support to the axp20x regulator driver. This patch
depends on patch 3, and patches already in regulator/topic/axp20x.
Patch 6 adds a dtsi file for AXP809.
Patch 7 enables AXP809 support on the A80 Optimus board.
Patch 8 enables AXP809 support on the Cubieboard 4.
Patch 9 disables the dummy regulators from sunxi-common-regulators.dtsi
on the A80 Optimus board. These aren't used in the board DTS anymore.
Patch 10 disables the dummy regulators from sunxi-common-regulators.dtsi,
on the Cubieboard4. These aren't used in the board DTS anymore.
Regards
ChenYu
Chen-Yu Tsai (10):
MAINTAINERS: Add entry for X-Powers AXP family PMIC drivers
mfd: axp20x: Add bindings for AXP809 PMIC
mfd: axp20x: Add support for AXP809 PMIC
regulator: axp20x: Use of_match name as default regulator name
regulator: axp20x: support AXP809 variant
ARM: dts: sunxi: Add dtsi file for AXP809 PMIC
ARM: dts: sun9i: a80-optimus: Add AXP809 PMIC device node and
regulators
ARM: dts: sun9i: cubieboard4: Add AXP809 PMIC device node and
regulators
ARM: dts: sun9i: a80-optimus: Disable dummy regulators vcc3v0, vcc3v3,
vcc5v0
ARM: dts: sun9i: cubieboard4: Disable dummy regulators vcc3v0, vcc3v3,
vcc5v0
Documentation/devicetree/bindings/mfd/axp20x.txt | 31 -
MAINTAINERS| 6 +
.../dts/{sun9i-a80-cubieboard4.dts => axp809.dtsi} | 98 ++
arch/arm/boot/dts/sun9i-a80-cubieboard4.dts| 143 -
arch/arm/boot/dts/sun9i-a80-optimus.dts| 143 -
drivers/mfd/axp20x-rsb.c | 1 +
drivers/mfd/axp20x.c | 79
drivers/regulator/axp20x-regulator.c | 129 ++-
include/linux/mfd/axp20x.h | 59 +
9 files changed, 559 insertions(+), 130 deletions(-)
copy arch/arm/boot/dts/{sun9i-a80-cubieboard4.dts => axp809.dtsi} (52%)
--
2.7.0
[PATCH v2 10/10] ARM: dts: sun9i: cubieboard4: Disable dummy regulators vcc3v0, vcc3v3, vcc5v0
These 3 regulators are provided in sunxi-common-regulators.dtsi.
3.0V/3.3V and 5.0V are commonly used voltages in Allwinner devices.
These dummy regulators provide a stand-in when bindings that require
one, but the real regulator is not supported yet.
Since these are no longer needed, we can disable them.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun9i-a80-cubieboard4.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
index 8d8af1189d87..84a12fef5768 100644
--- a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
+++ b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
@@ -255,6 +255,18 @@
#include "axp809.dtsi"
+®_vcc3v0 {
+ status = "disabled";
+};
+
+®_vcc3v3 {
+ status = "disabled";
+};
+
+®_vcc5v0 {
+ status = "disabled";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
--
2.7.0
[PATCH v2 01/10] MAINTAINERS: Add entry for X-Powers AXP family PMIC drivers
Add an entry for X-Powers AXP family PMIC drivers and list myself as maintainer. Cc: Carlo Caione Cc: Maxime Ripard Cc: Ramakrishna Pallala Cc: Todd Brandt Cc: Jacob Pan Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index f678c37107f5..7ea4e54f566a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11941,6 +11941,12 @@ F: include/linux/workqueue.h F: kernel/workqueue.c F: Documentation/workqueue.txt +X-POWERS MULTIFUNCTION PMIC DEVICE DRIVERS +M: Chen-Yu Tsai +L: linux-kernel@vger.kernel.org +S: Maintained +N: axp[128] + X.25 NETWORK LAYER M: Andrew Hendry L: linux-...@vger.kernel.org -- 2.7.0
[PATCH v2 09/10] ARM: dts: sun9i: a80-optimus: Disable dummy regulators vcc3v0, vcc3v3, vcc5v0
These 3 regulators are provided in sunxi-common-regulators.dtsi.
3.0V/3.3V and 5.0V are commonly used voltages in Allwinner devices.
These dummy regulators provide a stand-in when bindings that require
one, but the real regulator is not supported yet.
Since these are no longer needed, we can disable them.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun9i-a80-optimus.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/sun9i-a80-optimus.dts
b/arch/arm/boot/dts/sun9i-a80-optimus.dts
index 6cfc02194035..991337d1d6f1 100644
--- a/arch/arm/boot/dts/sun9i-a80-optimus.dts
+++ b/arch/arm/boot/dts/sun9i-a80-optimus.dts
@@ -322,6 +322,18 @@
#include "axp809.dtsi"
+®_vcc3v0 {
+ status = "disabled";
+};
+
+®_vcc3v3 {
+ status = "disabled";
+};
+
+®_vcc5v0 {
+ status = "disabled";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
--
2.7.0
[PATCH v2 08/10] ARM: dts: sun9i: cubieboard4: Add AXP809 PMIC device node and regulators
The AXP809 PMIC is the primary PMIC. It provides various supply voltages
for the SoC and other peripherals. The PMIC's interrupt line is connected
to NMI pin of the SoC.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun9i-a80-cubieboard4.dts | 131 +++-
1 file changed, 129 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
index eb2ccd0a3bd5..8d8af1189d87 100644
--- a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
+++ b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
@@ -98,7 +98,7 @@
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins>, <&mmc0_cd_pin_cubieboard4>;
- vmmc-supply = <®_vcc3v0>;
+ vmmc-supply = <®_dcdc1>;
bus-width = <4>;
cd-gpios = <&pio 7 18 GPIO_ACTIVE_HIGH>; /* PH18 */
cd-inverted;
@@ -108,7 +108,7 @@
&mmc2 {
pinctrl-names = "default";
pinctrl-0 = <&mmc2_8bit_pins>;
- vmmc-supply = <®_vcc3v0>;
+ vmmc-supply = <®_dcdc1>;
bus-width = <8>;
non-removable;
cap-mmc-hw-reset;
@@ -126,8 +126,135 @@
&r_rsb {
status = "okay";
+
+ axp809: pmic@3a3 {
+ reg = <0x3a3>;
+ interrupt-parent = <&nmi_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+
+ regulators {
+ reg_aldo1: aldo1 {
+ /*
+* TODO: This should be handled by the
+* USB PHY driver.
+*/
+ regulator-always-on;
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "vcc33-usbh";
+ };
+
+ reg_aldo2: aldo2 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-name = "vcc-pb-io-cam";
+ };
+
+ aldo3 {
+ /* unused */
+ };
+
+ reg_dc5ldo: dc5ldo {
+ regulator-always-on;
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <110>;
+ regulator-name = "vdd-cpus-09-usbh";
+ };
+
+ reg_dcdc1: dcdc1 {
+ regulator-always-on;
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "vcc-3v";
+ };
+
+ reg_dcdc2: dcdc2 {
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <110>;
+ regulator-name = "vdd-gpu";
+ };
+
+ reg_dcdc3: dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <110>;
+ regulator-name = "vdd-cpua";
+ };
+
+ reg_dcdc4: dcdc4 {
+ regulator-always-on;
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <110>;
+ regulator-name = "vdd-sys-usb0-hdmi";
+ };
+
+ reg_dcdc5: dcdc5 {
+ regulator-always-on;
+ regulator-min-microvolt = <1425000>;
+ regulator-max-microvolt = <1575000>;
+ regulator-name = "vcc-dram";
+ };
+
+ reg_dldo1: dldo1 {
+ /*
+* The WiFi chip supports a wide range
+* (3.0 ~ 4.8V) of voltages, and so does
+* this regulator (3.0 ~ 4.2V), but
+* Allwinner SDK always sets it to 3.3V.
+*/
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "vcc-wifi";
+ };
+
+ reg_dldo2: dldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <300>;
+
[PATCH v2 02/10] mfd: axp20x: Add bindings for AXP809 PMIC
This patch adds the basic and regulator bindings for the X-Powers AXP809
PMIC.
Also update the DC-DC converter operating frequency for AXP22X/AXP80X.
Signed-off-by: Chen-Yu Tsai
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/mfd/axp20x.txt | 31 ++--
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index fd39fa54571b..d20b1034e967 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -6,10 +6,11 @@ axp202 (X-Powers)
axp209 (X-Powers)
axp221 (X-Powers)
axp223 (X-Powers)
+axp809 (X-Powers)
Required properties:
- compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
- "x-powers,axp221", "x-powers,axp223"
+ "x-powers,axp221", "x-powers,axp223", "x-powers,axp809"
- reg: The I2C slave address or RSB hardware address for the AXP chip
- interrupt-parent: The parent interrupt controller
- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
@@ -18,7 +19,9 @@ Required properties:
Optional properties:
- x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz
- (range: 750-1875). Default: 1.5MHz
+ AXP152/20X: range: 750-1875, Default: 1.5 MHz
+ AXP22X/80X: range: 1800-4050, Default: 3 MHz
+
- -supply: a phandle to the regulator supply node. May be omitted if
inputs are unregulated, such as using the IPSOUT output
from the PMIC.
@@ -77,6 +80,30 @@ LDO_IO0 : LDO : ips-supply
: GPIO 0
LDO_IO1: LDO : ips-supply: GPIO 1
RTC_LDO: LDO : ips-supply: always on
+AXP809 regulators, type, and corresponding input supply names:
+
+RegulatorTypeSupply Name Notes
+---- -
+DCDC1 : DC-DC buck: vin1-supply
+DCDC2 : DC-DC buck: vin2-supply
+DCDC3 : DC-DC buck: vin3-supply
+DCDC4 : DC-DC buck: vin4-supply
+DCDC5 : DC-DC buck: vin5-supply
+DC1SW : On/Off Switch : : DCDC1 secondary output
+DC5LDO : LDO : : input from DCDC5
+ALDO1 : LDO : aldoin-supply : shared supply
+ALDO2 : LDO : aldoin-supply : shared supply
+ALDO3 : LDO : aldoin-supply : shared supply
+DLDO1 : LDO : dldoin-supply : shared supply
+DLDO2 : LDO : dldoin-supply : shared supply
+ELDO1 : LDO : eldoin-supply : shared supply
+ELDO2 : LDO : eldoin-supply : shared supply
+ELDO3 : LDO : eldoin-supply : shared supply
+LDO_IO0: LDO : ips-supply: GPIO 0
+LDO_IO1: LDO : ips-supply: GPIO 1
+RTC_LDO: LDO : ips-supply: always on
+SW : On/Off Switch : swin-supply
+
Example:
axp209: pmic@34 {
--
2.7.0
[PATCH v2 06/10] ARM: dts: sunxi: Add dtsi file for AXP809 PMIC
The AXP809 PMIC is used with the Allwinner A80 SoC, along with
an AXP806 PMIC as a slave.
This patch adds a dtsi file for all the common bindings and default
values unrelated to board design. Currently this is just listing all
the regulator nodes. The regulators are initialized based on their
device node names.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/axp809.dtsi | 53 +++
1 file changed, 53 insertions(+)
create mode 100644 arch/arm/boot/dts/axp809.dtsi
diff --git a/arch/arm/boot/dts/axp809.dtsi b/arch/arm/boot/dts/axp809.dtsi
new file mode 100644
index ..ab8e5f2d9246
--- /dev/null
+++ b/arch/arm/boot/dts/axp809.dtsi
@@ -0,0 +1,53 @@
+/*
+ * Copyright 2015 Chen-Yu Tsai
+ *
+ * Chen-Yu Tsai
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * AXP809 Integrated Power Management Chip
+ */
+
+&axp809 {
+ compatible = "x-powers,axp809";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+};
--
2.7.0
[PATCH v2 05/10] regulator: axp20x: support AXP809 variant
The X-Powers AXP809 PMIC has a similar set of regulators as the AXP221,
though a few LDOs were removed, and a new switch output added. Like the
AXP221, AXP809 also has DC1SW and DC5LDO, which are internally chained
to DCDC1 and DCDC5, respectively.
Add support for this new variant. Also remove the "axp22x_" prefix from
DC1SW/DC5LDO supply handling code, as the AXP809 uses it as well.
Signed-off-by: Chen-Yu Tsai
---
drivers/regulator/axp20x-regulator.c | 119 ++-
1 file changed, 90 insertions(+), 29 deletions(-)
diff --git a/drivers/regulator/axp20x-regulator.c
b/drivers/regulator/axp20x-regulator.c
index 40cd894e4df5..6a601f377019 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -224,6 +224,61 @@ static const struct regulator_desc axp22x_regulators[] = {
AXP_DESC_FIXED(AXP22X, RTC_LDO, "rtc_ldo", "ips", 3000),
};
+static const struct regulator_linear_range axp809_dcdc4_ranges[] = {
+ REGULATOR_LINEAR_RANGE(60, 0x0, 0x2f, 2),
+ REGULATOR_LINEAR_RANGE(180, 0x30, 0x38, 10),
+};
+
+static const struct regulator_linear_range axp809_dldo1_ranges[] = {
+ REGULATOR_LINEAR_RANGE(70, 0x0, 0x1a, 10),
+ REGULATOR_LINEAR_RANGE(340, 0x1b, 0x1f, 20),
+};
+
+static const struct regulator_desc axp809_regulators[] = {
+ AXP_DESC(AXP809, DCDC1, "dcdc1", "vin1", 1600, 3400, 100,
+AXP22X_DCDC1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(1)),
+ AXP_DESC(AXP809, DCDC2, "dcdc2", "vin2", 600, 1540, 20,
+AXP22X_DCDC2_V_OUT, 0x3f, AXP22X_PWR_OUT_CTRL1, BIT(2)),
+ AXP_DESC(AXP809, DCDC3, "dcdc3", "vin3", 600, 1860, 20,
+AXP22X_DCDC3_V_OUT, 0x3f, AXP22X_PWR_OUT_CTRL1, BIT(3)),
+ AXP_DESC_RANGES(AXP809, DCDC4, "dcdc4", "vin4", axp809_dcdc4_ranges,
+ 57, AXP22X_DCDC4_V_OUT, 0x3f, AXP22X_PWR_OUT_CTRL1,
+ BIT(4)),
+ AXP_DESC(AXP809, DCDC5, "dcdc5", "vin5", 1000, 2550, 50,
+AXP22X_DCDC5_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(5)),
+ /* secondary switchable output of DCDC1 */
+ AXP_DESC_SW(AXP809, DC1SW, "dc1sw", NULL, AXP22X_PWR_OUT_CTRL2,
+ BIT(7)),
+ /* LDO regulator internally chained to DCDC5 */
+ AXP_DESC(AXP809, DC5LDO, "dc5ldo", NULL, 700, 1400, 100,
+AXP22X_DC5LDO_V_OUT, 0x7, AXP22X_PWR_OUT_CTRL1, BIT(0)),
+ AXP_DESC(AXP809, ALDO1, "aldo1", "aldoin", 700, 3300, 100,
+AXP22X_ALDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(6)),
+ AXP_DESC(AXP809, ALDO2, "aldo2", "aldoin", 700, 3300, 100,
+AXP22X_ALDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(7)),
+ AXP_DESC(AXP809, ALDO3, "aldo3", "aldoin", 700, 3300, 100,
+AXP22X_ALDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(5)),
+ AXP_DESC_RANGES(AXP809, DLDO1, "dldo1", "dldoin", axp809_dldo1_ranges,
+ 32, AXP22X_DLDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2,
+ BIT(3)),
+ AXP_DESC(AXP809, DLDO2, "dldo2", "dldoin", 700, 3300, 100,
+AXP22X_DLDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(4)),
+ AXP_DESC(AXP809, ELDO1, "eldo1", "eldoin", 700, 3300, 100,
+AXP22X_ELDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(0)),
+ AXP_DESC(AXP809, ELDO2, "eldo2", "eldoin", 700, 3300, 100,
+AXP22X_ELDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(1)),
+ AXP_DESC(AXP809, ELDO3, "eldo3", "eldoin", 700, 3300, 100,
+AXP22X_ELDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(2)),
+ AXP_DESC_IO(AXP809, LDO_IO0, "ldo_io0", "ips", 700, 3300, 100,
+ AXP22X_LDO_IO0_V_OUT, 0x1f, AXP20X_GPIO0_CTRL, 0x07,
+ AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
+ AXP_DESC_IO(AXP809, LDO_IO1, "ldo_io1", "ips", 700, 3300, 100,
+ AXP22X_LDO_IO1_V_OUT, 0x1f, AXP20X_GPIO1_CTRL, 0x07,
+ AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
+ AXP_DESC_FIXED(AXP809, RTC_LDO, "rtc_ldo", "ips", 1800),
+ AXP_DESC_SW(AXP809, SW, "sw", "swin", AXP22X_PWR_OUT_CTRL2, BIT(6)),
+};
+
static int axp20x_set_dcdc_freq(struct platform_device *pdev, u32 dcdcfreq)
{
struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
@@ -239,6 +294,7 @@ static int axp20x_set_dcdc_freq(struct platform_device
*pdev, u32 dcdcfreq)
break;
case AXP221_ID:
case AXP223_ID:
+ case AXP809_ID:
min = 1800;
max = 4050;
def = 3000;
@@ -318,6 +374,7 @@ static int axp20x_set_dcdc_workmode(struct regulator_dev
*rdev, int id, u32 work
case AXP221_ID:
case AXP223_ID:
+ case AXP809_ID:
if (id < AXP22X_DCDC1 || id > AXP22X_DCDC5)
return -EINVAL;
@@ -346,8 +403,8 @@ static int axp20x_regulator_probe(struct platform_device
*pdev)
};
[PATCH v2 07/10] ARM: dts: sun9i: a80-optimus: Add AXP809 PMIC device node and regulators
The AXP809 PMIC is the primary PMIC. It provides various supply voltages
for the SoC and other peripherals. The PMIC's interrupt line is
connected to NMI pin of the SoC.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun9i-a80-optimus.dts | 131 +++-
1 file changed, 129 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/sun9i-a80-optimus.dts
b/arch/arm/boot/dts/sun9i-a80-optimus.dts
index d7a20d92b114..6cfc02194035 100644
--- a/arch/arm/boot/dts/sun9i-a80-optimus.dts
+++ b/arch/arm/boot/dts/sun9i-a80-optimus.dts
@@ -150,7 +150,7 @@
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins>, <&mmc0_cd_pin_optimus>;
- vmmc-supply = <®_vcc3v0>;
+ vmmc-supply = <®_dcdc1>;
bus-width = <4>;
cd-gpios = <&pio 7 18 GPIO_ACTIVE_HIGH>; /* PH8 */
cd-inverted;
@@ -160,7 +160,7 @@
&mmc2 {
pinctrl-names = "default";
pinctrl-0 = <&mmc2_8bit_pins>;
- vmmc-supply = <®_vcc3v0>;
+ vmmc-supply = <®_dcdc1>;
bus-width = <8>;
non-removable;
cap-mmc-hw-reset;
@@ -193,8 +193,135 @@
&r_rsb {
status = "okay";
+
+ axp809: pmic@3a3 {
+ reg = <0x3a3>;
+ interrupt-parent = <&nmi_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+
+ regulators {
+ reg_aldo1: aldo1 {
+ /*
+* TODO: This should be handled by the
+* USB PHY driver.
+*/
+ regulator-always-on;
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "vcc33-usbh";
+ };
+
+ reg_aldo2: aldo2 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-name = "vcc-pb-io-cam";
+ };
+
+ aldo3 {
+ /* unused */
+ };
+
+ reg_dc5ldo: dc5ldo {
+ regulator-always-on;
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <110>;
+ regulator-name = "vdd-cpus-09-usbh";
+ };
+
+ reg_dcdc1: dcdc1 {
+ regulator-always-on;
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "vcc-3v";
+ };
+
+ reg_dcdc2: dcdc2 {
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <110>;
+ regulator-name = "vdd-gpu";
+ };
+
+ reg_dcdc3: dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <110>;
+ regulator-name = "vdd-cpua";
+ };
+
+ reg_dcdc4: dcdc4 {
+ regulator-always-on;
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <110>;
+ regulator-name = "vdd-sys-usb0-hdmi";
+ };
+
+ reg_dcdc5: dcdc5 {
+ regulator-always-on;
+ regulator-min-microvolt = <1425000>;
+ regulator-max-microvolt = <1575000>;
+ regulator-name = "vcc-dram";
+ };
+
+ reg_dldo1: dldo1 {
+ /*
+* The WiFi chip supports a wide range
+* (3.0 ~ 4.8V) of voltages, and so does
+* this regulator (3.0 ~ 4.2V), but
+* Allwinner SDK always sets it to 3.3V.
+*/
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "vcc-wifi";
+ };
+
+ reg_dldo2: dldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <300>;
+ regulator-max-micr
Re: [PATCH] drivers: stm: correct the index in master array release
Chunyan Zhang writes: > On Tue, Feb 9, 2016 at 6:12 PM, Alexander Shishkin > wrote: >> Chunyan Zhang writes: >> >>> It would be broken if stm_data->sw_start isn't zero, because that >>> stp_master_free() get the 'master' with __stm_master()/stm_master(), >>> in which the masterID is the second input parameter minus >>> stm_data->sw_start. So freeing STM masters has to start from >>> stm_data->sw_start. >> >> No, it won't. stm_master_free() handles nonexistent masters correctly. >> It does make sense to shrink the loop in stm_unregister_device() to >> avoid going through the [0..sw_start) range, since stm_master() returns >> NULL for those, but not for the reasons given in this patch description. > > Let's assume sw_start = 64, sw_end = 79, sw_nmasters should be 16, if > the loop goes through [0..16), the existed masters will not be freed. Ah yes, you're right, of course. I'll add this fix to the queue with a proper description. Thanks, -- Alex
[PATCH v2 03/10] mfd: axp20x: Add support for AXP809 PMIC
The X-Powers AXP809 is a new PMIC that is paired with Allwinner's A80
SoC, along with a slave AXP806 PMIC.
This PMIC is quite similar to the earlier AXP223, though the interrupts
and regulator have changed a bit.
This patch adds support for the interrupts and power button of the PMIC.
Signed-off-by: Chen-Yu Tsai
---
drivers/mfd/axp20x-rsb.c | 1 +
drivers/mfd/axp20x.c | 79 ++
include/linux/mfd/axp20x.h | 59 ++
3 files changed, 139 insertions(+)
diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
index 28c20247c112..a407527bcd09 100644
--- a/drivers/mfd/axp20x-rsb.c
+++ b/drivers/mfd/axp20x-rsb.c
@@ -61,6 +61,7 @@ static int axp20x_rsb_remove(struct sunxi_rsb_device *rdev)
static const struct of_device_id axp20x_rsb_of_match[] = {
{ .compatible = "x-powers,axp223", .data = (void *)AXP223_ID },
+ { .compatible = "x-powers,axp809", .data = (void *)AXP809_ID },
{ },
};
MODULE_DEVICE_TABLE(of, axp20x_rsb_of_match);
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index a57d6e940610..1ce923277cc8 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -37,6 +37,7 @@ static const char * const axp20x_model_names[] = {
"AXP221",
"AXP223",
"AXP288",
+ "AXP809",
};
static const struct regmap_range axp152_writeable_ranges[] = {
@@ -85,6 +86,7 @@ static const struct regmap_access_table axp20x_volatile_table
= {
.n_yes_ranges = ARRAY_SIZE(axp20x_volatile_ranges),
};
+/* AXP22x ranges are shared with the AXP809, as they cover the same range */
static const struct regmap_range axp22x_writeable_ranges[] = {
regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
regmap_reg_range(AXP20X_DCDC_MODE, AXP22X_BATLOW_THRES1),
@@ -211,6 +213,20 @@ static struct resource axp288_fuel_gauge_resources[] = {
},
};
+static struct resource axp809_pek_resources[] = {
+ {
+ .name = "PEK_DBR",
+ .start = AXP809_IRQ_PEK_RIS_EDGE,
+ .end= AXP809_IRQ_PEK_RIS_EDGE,
+ .flags = IORESOURCE_IRQ,
+ }, {
+ .name = "PEK_DBF",
+ .start = AXP809_IRQ_PEK_FAL_EDGE,
+ .end= AXP809_IRQ_PEK_FAL_EDGE,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
static const struct regmap_config axp152_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
@@ -378,6 +394,41 @@ static const struct regmap_irq axp288_regmap_irqs[] = {
INIT_REGMAP_IRQ(AXP288, BC_USB_CHNG,5, 1),
};
+static const struct regmap_irq axp809_regmap_irqs[] = {
+ INIT_REGMAP_IRQ(AXP809, ACIN_OVER_V,0, 7),
+ INIT_REGMAP_IRQ(AXP809, ACIN_PLUGIN,0, 6),
+ INIT_REGMAP_IRQ(AXP809, ACIN_REMOVAL, 0, 5),
+ INIT_REGMAP_IRQ(AXP809, VBUS_OVER_V,0, 4),
+ INIT_REGMAP_IRQ(AXP809, VBUS_PLUGIN,0, 3),
+ INIT_REGMAP_IRQ(AXP809, VBUS_REMOVAL, 0, 2),
+ INIT_REGMAP_IRQ(AXP809, VBUS_V_LOW, 0, 1),
+ INIT_REGMAP_IRQ(AXP809, BATT_PLUGIN,1, 7),
+ INIT_REGMAP_IRQ(AXP809, BATT_REMOVAL, 1, 6),
+ INIT_REGMAP_IRQ(AXP809, BATT_ENT_ACT_MODE, 1, 5),
+ INIT_REGMAP_IRQ(AXP809, BATT_EXIT_ACT_MODE, 1, 4),
+ INIT_REGMAP_IRQ(AXP809, CHARG, 1, 3),
+ INIT_REGMAP_IRQ(AXP809, CHARG_DONE, 1, 2),
+ INIT_REGMAP_IRQ(AXP809, BATT_CHG_TEMP_HIGH, 2, 7),
+ INIT_REGMAP_IRQ(AXP809, BATT_CHG_TEMP_HIGH_END, 2, 6),
+ INIT_REGMAP_IRQ(AXP809, BATT_CHG_TEMP_LOW, 2, 5),
+ INIT_REGMAP_IRQ(AXP809, BATT_CHG_TEMP_LOW_END, 2, 4),
+ INIT_REGMAP_IRQ(AXP809, BATT_ACT_TEMP_HIGH, 2, 3),
+ INIT_REGMAP_IRQ(AXP809, BATT_ACT_TEMP_HIGH_END, 2, 2),
+ INIT_REGMAP_IRQ(AXP809, BATT_ACT_TEMP_LOW, 2, 1),
+ INIT_REGMAP_IRQ(AXP809, BATT_ACT_TEMP_LOW_END, 2, 0),
+ INIT_REGMAP_IRQ(AXP809, DIE_TEMP_HIGH, 3, 7),
+ INIT_REGMAP_IRQ(AXP809, LOW_PWR_LVL1, 3, 1),
+ INIT_REGMAP_IRQ(AXP809, LOW_PWR_LVL2, 3, 0),
+ INIT_REGMAP_IRQ(AXP809, TIMER, 4, 7),
+ INIT_REGMAP_IRQ(AXP809, PEK_RIS_EDGE, 4, 6),
+ INIT_REGMAP_IRQ(AXP809, PEK_FAL_EDGE, 4, 5),
+ INIT_REGMAP_IRQ(AXP809, PEK_SHORT, 4, 4),
+ INIT_REGMAP_IRQ(AXP809, PEK_LONG, 4, 3),
+ INIT_REGMAP_IRQ(AXP809, PEK_OVER_OFF, 4, 2),
+ INIT_REGMAP_IRQ(AXP809, GPIO1_INPUT,4, 1),
+ INIT_REGMAP_IRQ(AXP809, GPIO0_INPUT,4, 0),
+};
+
static const struct regmap_irq_chip axp152_regmap_irq_chip = {
.name = "axp152_irq_chip",
.status_base= AXP152_IRQ1_STATE,
@@ -428,6 +479,18 @@ static const struct regmap_irq_chip axp288_regmap_irq_chip
= {
};
Re: [PATCH v4 00/23] arm64: Virtualization Host Extension support
On 15/02/16 10:23, Catalin Marinas wrote: > On Thu, Feb 11, 2016 at 07:10:50PM +, Marc Zyngier wrote: >> On 11/02/16 19:07, Christoffer Dall wrote: >>> On Thu, Feb 11, 2016 at 06:39:41PM +, Marc Zyngier wrote: ARMv8.1 comes with the "Virtualization Host Extension" (VHE for short), which enables simpler support of Type-2 hypervisors. This extension allows the kernel to directly run at EL2, and significantly reduces the number of system registers shared between host and guest, reducing the overhead of virtualization. In order to have the same kernel binary running on all versions of the architecture, this series makes heavy use of runtime code patching. The first 22 patches massage the KVM code to deal with VHE and enable Linux to run at EL2. The last patch catches an ugly case when VHE capable CPUs are paired with some of their less capable siblings. This should never happen, but hey... I have deliberately left out some of the more "advanced" optimizations, as they are likely to distract the reviewer from the core infrastructure, which is what I care about at the moment. Note: GDB is currently busted on VHE systems, as it checks for version 6 on the debug architecture, while VHE is version 7. The binutils people are on the case. This has been tested on the FVP_Base_SLV-V8-A model, and based on v4.5-rc3 + kvmarm/master. I've put a branch out on: git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/vhe >>> >>> I'm happy with this series as it stands, we just need someone to take a >>> look at that debug patch and be happy with it. >> >> I think Will is planning to have a go at it shortly. Once he and Catalin >> are happy with the thing, I'll throw it into -next for a good shake. > > Fine by me but it would be good for Will to have a look, especially on > the debug and perf stuff. Definitely. To make it clear, I do not intend to put anything in -next until all the relevant people has reviewed it, and at least given their Ack. Thanks, M. -- Jazz is not dead. It just smells funny...
[PATCH v2 04/10] regulator: axp20x: Use of_match name as default regulator name
Originally the helper macros used uppercase regulator names, which
are primarily used to expand to the regulator ID enum, as the default
names. This is aestheticly unpleasent.
Since the of_match bits are the same, just lowercase, use that as the
default names instead.
Signed-off-by: Chen-Yu Tsai
---
drivers/regulator/axp20x-regulator.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/regulator/axp20x-regulator.c
b/drivers/regulator/axp20x-regulator.c
index 81f25383f2d5..40cd894e4df5 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -39,7 +39,7 @@
#define AXP_DESC_IO(_family, _id, _match, _supply, _min, _max, _step, _vreg,
\
_vmask, _ereg, _emask, _enable_val, _disable_val)
\
[_family##_##_id] = {
\
- .name = #_id,
\
+ .name = (_match),
\
.supply_name= (_supply),
\
.of_match = of_match_ptr(_match),
\
.regulators_node = of_match_ptr("regulators"),
\
@@ -61,7 +61,7 @@
#define AXP_DESC(_family, _id, _match, _supply, _min, _max, _step, _vreg,
\
_vmask, _ereg, _emask)
\
[_family##_##_id] = {
\
- .name = #_id,
\
+ .name = (_match),
\
.supply_name= (_supply),
\
.of_match = of_match_ptr(_match),
\
.regulators_node = of_match_ptr("regulators"),
\
@@ -80,7 +80,7 @@
#define AXP_DESC_SW(_family, _id, _match, _supply, _ereg, _emask)
\
[_family##_##_id] = {
\
- .name = #_id,
\
+ .name = (_match),
\
.supply_name= (_supply),
\
.of_match = of_match_ptr(_match),
\
.regulators_node = of_match_ptr("regulators"),
\
@@ -94,7 +94,7 @@
#define AXP_DESC_FIXED(_family, _id, _match, _supply, _volt)
\
[_family##_##_id] = {
\
- .name = #_id,
\
+ .name = (_match),
\
.supply_name= (_supply),
\
.of_match = of_match_ptr(_match),
\
.regulators_node = of_match_ptr("regulators"),
\
@@ -109,7 +109,7 @@
#define AXP_DESC_RANGES(_family, _id, _match, _supply, _ranges, _n_voltages,
\
_vreg, _vmask, _ereg, _emask)
\
[_family##_##_id] = {
\
- .name = #_id,
\
+ .name = (_match),
\
.supply_name= (_supply),
\
.of_match = of_match_ptr(_match),
\
.regulators_node = of_match_ptr("regulators"),
\
--
2.7.0
tty: memory leak in tty_register_driver
Hello,
When I am running the following program in a parallel loop, kmemleak
starts reporting memory leaks of objects allocated in
tty_register_driver during boot. These leaks start popping up
chaotically and as you can see they originate in different drivers
(synclinkmp_init, isdn_init, chr_dev_init, sysfs_init).
On commit 388f7b1d6e8ca06762e2454d28d6c3c55ad0fe95 (4.5-rc3).
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include
#include
#include
#include
int main()
{
int fd, val;
fd = open("/dev/ptmx", O_RDWR);
val = 21;
ioctl(fd, TIOCSETD, &val);
return 0;
}
unreferenced object 0x88006708dc20 (size 8):
comm "swapper/0", pid 1, jiffies 4294672590 (age 930.839s)
hex dump (first 8 bytes):
74 74 79 53 4c 4d 38 00 ttySLM8.
backtrace:
[] __kmalloc_track_caller+0x1b0/0x320 mm/slub.c:4068
[] kstrdup+0x39/0x70 mm/util.c:53
[] kstrdup_const+0x46/0x60 mm/util.c:74
[] __kernfs_new_node+0x2b/0x2b0 fs/kernfs/dir.c:536
[] kernfs_new_node+0x80/0xe0 fs/kernfs/dir.c:572
[] kernfs_create_link+0x33/0x150 fs/kernfs/symlink.c:32
[] sysfs_do_create_link_sd.isra.2+0x8b/0x120
fs/sysfs/symlink.c:44
[< inline >] sysfs_do_create_link fs/sysfs/symlink.c:80
[] sysfs_create_link+0x65/0xc0 fs/sysfs/symlink.c:92
[< inline >] device_add_class_symlinks drivers/base/core.c:891
[] device_add+0x73c/0x1480 drivers/base/core.c:1086
[] device_register+0x1d/0x20 drivers/base/core.c:1189
[] tty_register_device_attr+0x320/0x760
drivers/tty/tty_io.c:3312
[< inline >] tty_register_device drivers/tty/tty_io.c:3239
[] tty_register_driver+0x36b/0x670
drivers/tty/tty_io.c:3504
[] synclinkmp_init+0x35a/0x40e
drivers/tty/synclinkmp.c:3992
[] do_one_initcall+0x159/0x380 init/main.c:794
[< inline >] do_initcall_level init/main.c:859
[< inline >] do_initcalls init/main.c:867
[< inline >] do_basic_setup init/main.c:885
[] kernel_init_freeable+0x474/0x52d init/main.c:1010
unreferenced object 0x88006709b330 (size 152):
comm "swapper/0", pid 1, jiffies 4294672590 (age 930.839s)
hex dump (first 32 bytes):
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
backtrace:
[] kmem_cache_alloc+0x153/0x2e0 mm/slub.c:2609
[< inline >] kmem_cache_zalloc include/linux/slab.h:597
[] __kernfs_new_node+0x6c/0x2b0 fs/kernfs/dir.c:540
[] kernfs_new_node+0x80/0xe0 fs/kernfs/dir.c:572
[] kernfs_create_link+0x33/0x150 fs/kernfs/symlink.c:32
[] sysfs_do_create_link_sd.isra.2+0x8b/0x120
fs/sysfs/symlink.c:44
[< inline >] sysfs_do_create_link fs/sysfs/symlink.c:80
[] sysfs_create_link+0x65/0xc0 fs/sysfs/symlink.c:92
[< inline >] device_add_class_symlinks drivers/base/core.c:891
[] device_add+0x73c/0x1480 drivers/base/core.c:1086
[] device_register+0x1d/0x20 drivers/base/core.c:1189
[] tty_register_device_attr+0x320/0x760
drivers/tty/tty_io.c:3312
[< inline >] tty_register_device drivers/tty/tty_io.c:3239
[] tty_register_driver+0x36b/0x670
drivers/tty/tty_io.c:3504
[] synclinkmp_init+0x35a/0x40e
drivers/tty/synclinkmp.c:3992
[] do_one_initcall+0x159/0x380 init/main.c:794
[< inline >] do_initcall_level init/main.c:859
[< inline >] do_initcalls init/main.c:867
[< inline >] do_basic_setup init/main.c:885
[] kernel_init_freeable+0x474/0x52d init/main.c:1010
[] kernel_init+0x13/0x150 init/main.c:936
[] ret_from_fork+0x3f/0x70 arch/x86/entry/entry_64.S:468
unreferenced object 0x88006708d860 (size 8):
comm "swapper/0", pid 1, jiffies 4294672591 (age 930.838s)
hex dump (first 8 bytes):
74 74 79 53 4c 4d 39 00 ttySLM9.
backtrace:
[] __kmalloc_track_caller+0x1b0/0x320 mm/slub.c:4068
[] kstrdup+0x39/0x70 mm/util.c:53
[] kstrdup_const+0x46/0x60 mm/util.c:74
[] __kernfs_new_node+0x2b/0x2b0 fs/kernfs/dir.c:536
[] kernfs_new_node+0x80/0xe0 fs/kernfs/dir.c:572
[] kernfs_create_link+0x33/0x150 fs/kernfs/symlink.c:32
[] sysfs_do_create_link_sd.isra.2+0x8b/0x120
fs/sysfs/symlink.c:44
[< inline >] sysfs_do_create_link fs/sysfs/symlink.c:80
[] sysfs_create_link+0x65/0xc0 fs/sysfs/symlink.c:92
[< inline >] device_add_class_symlinks drivers/base/core.c:891
[] device_add+0x73c/0x1480 drivers/base/core.c:1086
[] device_register+0x1d/0x20 drivers/base/core.c:1189
[] tty_register_device_attr+0x320/0x760
drivers/tty/tty_io.c:3312
[< inline >] tty_register_device drivers/tty/tty_io.c:3239
[] tty_register_driver+0x36b/0x670
drivers/tty/tty_io.c:3504
[] synclinkmp_init+0x35a/0x40e
drivers/tty/synclinkmp.c:3992
[] do_one_initcall+0x159/0x380 init/main.c:794
[< inline >] do_initcall_level init/main.c:859
[< inline >] do_i
Re: [PATCH v4 4/8] dt-bindings: Add a binding for Mediatek Video Encoder
On Tue, Feb 9, 2016 at 7:29 PM, Daniel Kurtz wrote:
> Hi Tiffany,
>
> On Thu, Feb 4, 2016 at 7:34 PM, Tiffany Lin wrote:
>> Add a DT binding documentation of Video Encoder for the
>> MT8173 SoC from Mediatek.
>>
>> Signed-off-by: Tiffany Lin
>> ---
>> .../devicetree/bindings/media/mediatek-vcodec.txt | 59
>>
>> 1 file changed, 59 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/media/mediatek-vcodec.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
>> b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
>> new file mode 100644
>> index 000..572bfdd
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
>> @@ -0,0 +1,59 @@
>> +Mediatek Video Codec
>> +
>> +Mediatek Video Codec is the video codec hw present in Mediatek SoCs which
>> +supports high resolution encoding functionalities.
>> +
>> +Required properties:
>> +- compatible : "mediatek,mt8173-vcodec-enc" for encoder
>> +- reg : Physical base address of the video codec registers and length of
>> + memory mapped region.
>> +- interrupts : interrupt number to the cpu.
>> +- mediatek,larb : must contain the local arbiters in the current Socs.
>> +- clocks : list of clock specifiers, corresponding to entries in
>> + the clock-names property.
>> +- clock-names: encoder must contain "vencpll_d2", "venc_sel", "univpll1_d2",
>> + "venc_lt_sel".
>> +- iommus : should point to the respective IOMMU block with master port as
>> + argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
>> + for details.
>> +- mediatek,vpu : the node of video processor unit
>> +
>> +Example:
>> +vcodec_enc: vcodec@0x18002000 {
>> +compatible = "mediatek,mt8173-vcodec-enc";
>> +reg = <0 0x18002000 0 0x1000>,/*VENC_SYS*/
>> + <0 0x19002000 0 0x1000>;/*VENC_LT_SYS*/
>
> This really looks like two encoder devices combined into a single
> device tree node.
> There are two register sets, two irqs, two sets of iommus, and two
> sets of clocks.
>
> If possible, please split this node into two, one for each encoder.
I chatted offline with Mediatek. They explained that there really is
just one encoder hardware, that happens to support multiple formats.
The encoder cannot encode with both formats at the same time. The
Mediatek HW designers added a new format to an existing encoder by
adding a second interface (register set, irq, iommus, clocks) without
modifying the original interface. However in the hardware itself
there is really just one encoder device.
So, although this node looks like it is for two encoder devices (one
for each format), really there is just one device that supports each
format through its large interface.
So, I'm fine with this being a single device node.
>> +interrupts = ,
>> + ;
>> +mediatek,larb = <&larb3>,
>> + <&larb5>;
>> +iommus = <&iommu M4U_PORT_VENC_RCPU>,
>> + <&iommu M4U_PORT_VENC_REC>,
>> + <&iommu M4U_PORT_VENC_BSDMA>,
>> + <&iommu M4U_PORT_VENC_SV_COMV>,
>> + <&iommu M4U_PORT_VENC_RD_COMV>,
>> + <&iommu M4U_PORT_VENC_CUR_LUMA>,
>> + <&iommu M4U_PORT_VENC_CUR_CHROMA>,
>> + <&iommu M4U_PORT_VENC_REF_LUMA>,
>> + <&iommu M4U_PORT_VENC_REF_CHROMA>,
>> + <&iommu M4U_PORT_VENC_NBM_RDMA>,
>> + <&iommu M4U_PORT_VENC_NBM_WDMA>,
>> + <&iommu M4U_PORT_VENC_RCPU_SET2>,
>> + <&iommu M4U_PORT_VENC_REC_FRM_SET2>,
>> + <&iommu M4U_PORT_VENC_BSDMA_SET2>,
>> + <&iommu M4U_PORT_VENC_SV_COMA_SET2>,
>> + <&iommu M4U_PORT_VENC_RD_COMA_SET2>,
>> + <&iommu M4U_PORT_VENC_CUR_LUMA_SET2>,
>> + <&iommu M4U_PORT_VENC_CUR_CHROMA_SET2>,
>> + <&iommu M4U_PORT_VENC_REF_LUMA_SET2>,
>> + <&iommu M4U_PORT_VENC_REC_CHROMA_SET2>;
>> +mediatek,vpu = <&vpu>;
>> +clocks = <&topckgen CLK_TOP_VENCPLL_D2>,
>> + <&topckgen CLK_TOP_VENC_SEL>,
>> + <&topckgen CLK_TOP_UNIVPLL1_D2>,
>> + <&topckgen CLK_TOP_VENC_LT_SEL>;
>> +clock-names = "vencpll_d2",
>> + "venc_sel",
>> + "univpll1_d2",
>> + "venc_lt_sel";
>
> The names of these clocks should be from the perspective of the
> encoder, not the clock provider.
I still think these clock names should be updated, however.
-Dan
Re: [PATCH 5/5] efi: Make efivarfs entries immutable by default
On Fri, 12 Feb, at 11:27:12AM, Matt Fleming wrote: > From: Peter Jones > > "rm -rf" is bricking some peoples' laptops because of variables being > used to store non-reinitializable firmware driver data that's required > to POST the hardware. > > These are 100% bugs, and they need to be fixed, but in the mean time it > shouldn't be easy to *accidentally* brick machines. > > We have to have delete working, and picking which variables do and don't > work for deletion is quite intractable, so instead make everything > immutable by default (except for a whitelist), and make tools that > aren't quite so broad-spectrum unset the immutable flag. > > Signed-off-by: Peter Jones > Tested-by: "Lee, Chun-Yi" > Acked-by: Matthew Garrett > Signed-off-by: Matt Fleming > --- > Documentation/filesystems/efivarfs.txt | 7 +++ > drivers/firmware/efi/vars.c| 87 > +++--- > fs/efivarfs/file.c | 70 + > fs/efivarfs/inode.c| 30 + > fs/efivarfs/internal.h | 3 +- > fs/efivarfs/super.c| 9 ++- > include/linux/efi.h| 2 + > tools/testing/selftests/efivarfs/efivarfs.sh | 19 +- > tools/testing/selftests/efivarfs/open-unlink.c | 72 - > 9 files changed, 258 insertions(+), 41 deletions(-) Folks, please hold off on merging this patch as Laszlo has raised a good point about including the efi-pstore variables in the whitelist.
Re: [PATCH RFC] Introduce atomic and per-cpu add-max and sub-min operations
Adding Peter and Paul,
On Sun, Feb 14, 2016 at 12:09:00PM +0300, Konstantin Khlebnikov wrote:
> bool atomic_add_max(atomic_t *var, int add, int max);
> bool atomic_sub_min(atomic_t *var, int sub, int min);
What are the memory-ordering requirements for these? Do you also want
relaxed/acquire/release versions for the use-cases you outline?
One observation is that you provide no ordering guarantees if the
comparison fails, which is fine if that's what you want, but we should
probably write that down like we do for cmpxchg.
> bool this_cpu_add_max(var, add, max);
> bool this_cpu_sub_min(var, sub, min);
>
> They add/subtract only if result will be not bigger than max/lower that min.
> Returns true if operation was done and false otherwise.
>
> Inside they check that (add <= max - var) and (sub <= var - min). Signed
> operations work if all possible values fits into range which length fits
> into non-negative range of that type: 0..INT_MAX, INT_MIN+1..0, -1000..1000.
> Unsigned operations work if value always in valid range: min <= var <= max.
> Char and short automatically casts to int, they never overflows.
>
> Patch adds the same for atomic_long_t, atomic64_t, local_t, local64_t.
> And unsigned variants: atomic_u32_add_max atomic_u32_sub_min for atomic_t,
> atomic_u64_add_max atomic_u64_sub_min for atomic64_t.
>
> Patch comes with test which hopefully covers all possible cornercases,
> see CONFIG_ATOMIC64_SELFTEST and CONFIG_PERCPU_TEST.
>
> All this allows to build any kind of counter in several lines:
Do you have another patch converting people over to these new atomics?
> - Simple atomic resource counter
>
> atomic_t usage;
> int limit;
>
> result = atomic_add_max(&usage, charge, limit);
>
> atomic_sub(uncharge, &usage);
>
> - Event counter with per-cpu batch
>
> atomic_t events;
> DEFINE_PER_CPU(int, cpu_events);
> int batch;
>
> if (!this_cpu_add_max(cpu_events, count, batch))
> atomic_add(this_cpu_xchg(cpu_events, 0) + count, &events);
>
> - Object counter with per-cpu part
>
> atomic_t objects;
> DEFINE_PER_CPU(int, cpu_objects);
> int batch;
>
> if (!this_cpu_add_max(cpu_objects, 1, batch))
> atomic_add(this_cpu_xchg(cpu_events, 0) + 1, &objects);
>
> if (!this_cpu_sub_min(cpu_objects, 1, -batch))
> atomic_add(this_cpu_xchg(cpu_events, 0) - 1, &objects);
>
> - Positive object counter with negative per-cpu parts
>
> atomic_t objects;
> DEFINE_PER_CPU(int, cpu_objects);
> int batch;
>
> if (!this_cpu_add_max(cpu_objects, 1, 0))
> atomic_add(this_cpu_xchg(cpu_events, -batch / 2) + 1, &objects);
>
> if (!this_cpu_sub_min(cpu_objects, 1, -batch))
> atomic_add(this_cpu_xchg(cpu_events, -batch / 2) - 1, &objects);
>
> - Resource counter with per-cpu precharge
>
> atomic_t usage;
> int limit;
> DEFINE_PER_CPU(int, precharge);
> int batch;
>
> result = this_cpu_sub_min(precharge, charge, 0);
> if (!result) {
> preempt_disable();
> charge += batch / 2 - __this_cpu_read(precharge);
> result = atomic_add_max(&usage, charge, limit);
> if (result)
> __this_cpu_write(precharge, batch / 2);
> preempt_enable();
> }
>
> if (!this_cpu_add_max(precharge, uncharge, batch)) {
> preempt_disable();
> if (__this_cpu_read(precharge) > batch / 2) {
> uncharge += __this_cpu_read(precharge) - batch / 2;
> __this_cpu_write(precharge, batch / 2);
> }
> atomic_sub(uncharge, &usage);
> preempt_enable();
> }
>
> - Each operation easily split into static-inline per-cpu fast-path and
> atomic slow-path which could be hidden in separate function which
> performs resource reclaim, logging, etc.
> - Types of global atomic part and per-cpu part might differs: for example
> like in vmstat counters atomit_long_t global and s8 local part.
> - Resource could be counted upwards to the limit or downwards to the zero.
> - Bounds min=INT_MIN/max=INT_MAX could be used for catching und/overflows.
>
> Signed-off-by: Konstantin Khlebnikov
> ---
> arch/x86/include/asm/local.h |2 +
> include/asm-generic/local.h |2 +
> include/asm-generic/local64.h |4 ++
> include/linux/atomic.h| 52 +
> include/linux/percpu-defs.h | 56 +++
> lib/atomic64_test.c | 49
> lib/percpu_test.c | 84
> +
> 7 files changed, 249 insertions(+)
You may want something in Documentation/ too.
> diff --git a/include/linux/atomic.h b/include/linux/atomic.h
> index 301de78d65f7..06b12a60645b 100644
> --- a/include/linux/atomic.h
> +++ b/include/linux/atomic.h
> @@ -561,4 +561,56 @@ static inline void atomic64_andnot(long long i,
> atomic64_t *v)
>
> #include
>
> +/*
> + * atomic_add_max - add unless result will be bugger that max
Freudian slip? ;)
> + * @var: pointer of type atomic_t
> + * @add: value to add
> + * @max: maximum resu
Re: [PATCH 3/2] oom: clear TIF_MEMDIE after oom_reaper managed to unmap the address space
Andrew Morton wrote:
>
> The patch titled
> Subject: mm/oom_kill.c: don't ignore oom score on exiting tasks
> has been removed from the -mm tree. Its filename was
> mm-oom_killc-dont-skip-pf_exiting-tasks-when-searching-for-a-victim.patch
>
> This patch was dropped because an updated version will be merged
>
> --
> From: Johannes Weiner
> Subject: mm/oom_kill.c: don't ignore oom score on exiting tasks
>
> When the OOM killer scans tasks and encounters a PF_EXITING one, it
> force-selects that one regardless of the score. Is there a possibility
> that the task might hang after it has set PF_EXITING? In that case the
> OOM killer should be able to move on to the next task.
>
> Frankly, I don't even know why we check for exiting tasks in the OOM
> killer. We've tried direct reclaim at least 15 times by the time we
> decide the system is OOM, there was plenty of time to exit and free
> memory; and a task might exit voluntarily right after we issue a kill.
> This is testing pure noise.
>
I can't find updated version of this patch in linux-next. Why don't you submit?
I think the patch description should be updated because this patch solves yet
another silent OOM livelock bug.
Say, there is a process with two threads named Thread1 and Thread2.
Since the OOM killer sets TIF_MEMDIE only on the first non-NULL mm task,
it is possible that Thread2 invokes the OOM killer and Thread1 gets
TIF_MEMDIE (without sending SIGKILL to processes using Thread1's mm).
--
Thread1 Thread2
Calls mmap()
Calls _exit(0)
Arrives at vm_mmap_pgoff()
Arrives at do_exit()
Gets PF_EXITING via exit_signals()
Calls down_write(&mm->mmap_sem)
Calls do_mmap_pgoff()
Calls down_read(&mm->mmap_sem) from exit_mm()
Does a GFP_KERNEL allocation
Calls out_of_memory()
oom_scan_process_thread(Thread1) returns
OOM_SCAN_ABORT
down_read(&mm->mmap_sem) is waiting for Thread2 to call up_write(&mm->mmap_sem)
but Thread2 is waiting for Thread1 to set
Thread1->mm = NULL ... silent OOM livelock!
--
The OOM reaper tries to avoid this livelock by using down_read_trylock()
instead of down_read(), but core_state check in exit_mm() cannot avoid this
livelock unless we use non-blocking allocation (i.e. GFP_ATOMIC or GFP_NOWAIT)
for allocations between down_write(&mm->mmap_sem) and up_write(&mm->mmap_sem).
I think that the same problem exists for any task_will_free_mem()-based
optimizations such as
if (current->mm &&
(fatal_signal_pending(current) || task_will_free_mem(current))) {
mark_oom_victim(current);
return true;
}
in out_of_memory() and
task_lock(p);
if (p->mm && task_will_free_mem(p)) {
mark_oom_victim(p);
task_unlock(p);
put_task_struct(p);
return;
}
task_unlock(p);
in oom_kill_process() and
if (fatal_signal_pending(current) || task_will_free_mem(current)) {
mark_oom_victim(current);
goto unlock;
}
in mem_cgroup_out_of_memory().
Well, what are possible callers of task_will_free_mem(current) between getting
PF_EXITING and doing current->mm = NULL ? tty_audit_exit() seems to be an
example
which does a GFP_KERNEL allocation from tty_audit_log() and can be later blocked
at down_read() in exit_mm() after TIF_MEMDIE is set at tty_audit_log() called
from
tty_audit_exit() ?
Is task_will_free_mem(current) possible for mem_cgroup_out_of_memory() case?
Re: arm qemu test failures due to 'driver-core: platform: probe of-devices only using list of compatibles'
Hello Guenter, On Sun, Feb 14, 2016 at 08:50:10AM -0800, Guenter Roeck wrote: > Uwe, > > Your patch 'driver-core: platform: probe of-devices only using list of > compatibles' causes the following qemu tests to crash in -next. > > arm:vexpress-a9:vexpress_defconfig:vexpress-v2p-ca9 > arm:vexpress-a15:vexpress_defconfig:vexpress-v2p-ca15-tc1 > arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9 > arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1 > > Crash log: > > VFS: Cannot open root device "mmcblk0" or unknown-block(0,0): error -6 > Please append a correct "root=" boot option; here are the available > partitions: > 1f00 131072 mtdblock0 (driver?) > 1f01 32768 mtdblock1 (driver?) > Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) Can you provide a complete boot log? This might already reveal which device is failing. It might not be the mmci device but something it depends on (clock, bus parent, irq). Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
[PATCH 0/2] Add Rockchip display port phy driver support
Hi Kison, This series is splited from Analogix DP DRM thread [0], and Heiko suggest this should be an independent thread which may be easy for you to apply. Best regards, Yakir [0]: https://patchwork.kernel.org/patch/8086571/ Changes in v12: - Re-order the include headers file alphabetically in phy-rockchip-dp.c (Jingoo) Changes in v11: - Correct the title of this rockchip dp phy document(Rob) - Add the ack from Rob Herring Changes in v10: - Fix the wrong macro value of GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK BIT(4) -> BIT(20) Changes in v9: - Removed the unused the variable "res" in probe function. (Heiko) - Removed the unused head file. Changes in v8: - Fix the mixed spacers on macro definitions. (Heiko) - Remove the unnecessary empty line after clk_prepare_enable. (Heiko) - Remove the specific address in the example node name. (Heiko) Changes in v7: - Simply the commit message. (Kishon) - Symmetrical enable/disbale the phy clock and power. (Kishon) - Simplify the commit message. (Kishon) Changes in v5: - Remove "reg" DT property, cause driver could poweron/poweroff phy via the exist "grf" syscon already. And rename the example DT node from "edp_phy: phy@ff770274" to "edp_phy: edp-phy" directly. (Heiko) - Add deivce_node at the front of driver, update phy_ops type from "static struct" to "static const struct". And correct the input paramters of devm_phy_create() interfaces. (Heiko) - Split binding doc's from driver changes. (Rob) - Update the rockchip,grf explain in document, and correct the clock required elemets in document. (Rob & Heiko) Changes in v4: - Add commit message, and remove the redundant rockchip_dp_phy_init() function, move those code to probe() method. And remove driver .owner number. (Kishon) Changes in v3: - Suggest, add rockchip dp phy driver, collect the phy clocks and power control. (Heiko) Yakir Yang (2): phy: Add driver for rockchip Display Port PHY dt-bindings: add document for rockchip dp phy .../devicetree/bindings/phy/rockchip-dp-phy.txt| 22 +++ drivers/phy/Kconfig| 7 + drivers/phy/Makefile | 1 + drivers/phy/phy-rockchip-dp.c | 151 + 4 files changed, 181 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt create mode 100644 drivers/phy/phy-rockchip-dp.c -- 1.9.1
[PATCH 2/2] dt-bindings: add document for rockchip dp phy
Add dt binding documentation for rockchip display port PHY.
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
Reviewed-by: Heiko Stuebner
---
Changes in v12: None
Changes in v11:
- Correct the title of this rockchip dp phy document(Rob)
- Add the ack from Rob Herring
Changes in v10: None
Changes in v9: None
Changes in v8:
- Remove the specific address in the example node name. (Heiko)
Changes in v7:
- Simplify the commit message. (Kishon)
Changes in v5:
- Split binding doc's from driver changes. (Rob)
- Update the rockchip,grf explain in document, and correct the clock required
elemets in document. (Rob & Heiko)
Changes in v4: None
Changes in v3: None
.../devicetree/bindings/phy/rockchip-dp-phy.txt| 22 ++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
new file mode 100644
index 000..50c4f9b
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
@@ -0,0 +1,22 @@
+Rockchip specific extensions to the Analogix Display Port PHY
+
+
+Required properties:
+- compatible : should be one of the following supported values:
+- "rockchip.rk3288-dp-phy"
+- clocks: from common clock binding: handle to dp clock.
+ of memory mapped region.
+- clock-names: from common clock binding:
+ Required elements: "24m"
+- rockchip,grf: phandle to the syscon managing the "general register files"
+- #phy-cells : from the generic PHY bindings, must be 0;
+
+Example:
+
+edp_phy: edp-phy {
+ compatible = "rockchip,rk3288-dp-phy";
+ rockchip,grf = <&grf>;
+ clocks = <&cru SCLK_EDP_24M>;
+ clock-names = "24m";
+ #phy-cells = <0>;
+};
--
1.9.1
[PATCH 1/2] phy: Add driver for rockchip Display Port PHY
Add phy driver for the Rockchip DisplayPort PHY module. This
is required to get DisplayPort working in Rockchip SoCs.
Signed-off-by: Yakir Yang
Reviewed-by: Heiko Stuebner
---
Changes in v12:
- Re-order the include headers file alphabetically in phy-rockchip-dp.c (Jingoo)
Changes in v11: None
Changes in v10:
- Fix the wrong macro value of GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK
BIT(4) -> BIT(20)
Changes in v9:
- Removed the unused the variable "res" in probe function. (Heiko)
- Removed the unused head file.
Changes in v8:
- Fix the mixed spacers on macro definitions. (Heiko)
- Remove the unnecessary empty line after clk_prepare_enable. (Heiko)
Changes in v7:
- Simply the commit message. (Kishon)
- Symmetrical enable/disbale the phy clock and power. (Kishon)
Changes in v5:
- Remove "reg" DT property, cause driver could poweron/poweroff phy via
the exist "grf" syscon already. And rename the example DT node from
"edp_phy: phy@ff770274" to "edp_phy: edp-phy" directly. (Heiko)
- Add deivce_node at the front of driver, update phy_ops type from "static
struct" to "static const struct". And correct the input paramters of
devm_phy_create() interfaces. (Heiko)
Changes in v4:
- Add commit message, and remove the redundant rockchip_dp_phy_init()
function, move those code to probe() method. And remove driver .owner
number. (Kishon)
Changes in v3:
- Suggest, add rockchip dp phy driver, collect the phy clocks and
power control. (Heiko)
drivers/phy/Kconfig | 7 ++
drivers/phy/Makefile | 1 +
drivers/phy/phy-rockchip-dp.c | 151 ++
3 files changed, 159 insertions(+)
create mode 100644 drivers/phy/phy-rockchip-dp.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index e7e117d..925e82c4 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -336,6 +336,13 @@ config PHY_ROCKCHIP_USB
help
Enable this to support the Rockchip USB 2.0 PHY.
+config PHY_ROCKCHIP_DP
+ tristate "Rockchip Display Port PHY Driver"
+ depends on ARCH_ROCKCHIP && OF
+ select GENERIC_PHY
+ help
+ Enable this to support the Rockchip Display Port PHY.
+
config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index c80f09d..081479a 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -37,6 +37,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+=
phy-s5pv210-usb2.o
obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
+obj-$(CONFIG_PHY_ROCKCHIP_DP) += phy-rockchip-dp.o
obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
new file mode 100644
index 000..88f09ec
--- /dev/null
+++ b/drivers/phy/phy-rockchip-dp.c
@@ -0,0 +1,151 @@
+/*
+ * Rockchip DP PHY driver
+ *
+ * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
+ * Author: Yakir Yang
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define GRF_SOC_CON12 0x0274
+
+#define GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK BIT(20)
+#define GRF_EDP_REF_CLK_SEL_INTER BIT(4)
+
+#define GRF_EDP_PHY_SIDDQ_HIWORD_MASK BIT(21)
+#define GRF_EDP_PHY_SIDDQ_ON0
+#define GRF_EDP_PHY_SIDDQ_OFF BIT(5)
+
+struct rockchip_dp_phy {
+ struct device *dev;
+ struct regmap *grf;
+ struct clk *phy_24m;
+};
+
+static int rockchip_set_phy_state(struct phy *phy, bool enable)
+{
+ struct rockchip_dp_phy *dp = phy_get_drvdata(phy);
+ int ret;
+
+ if (enable) {
+ ret = regmap_write(dp->grf, GRF_SOC_CON12,
+ GRF_EDP_PHY_SIDDQ_HIWORD_MASK |
+ GRF_EDP_PHY_SIDDQ_ON);
+ if (ret < 0) {
+ dev_err(dp->dev, "Can't enable PHY power %d\n", ret);
+ return ret;
+ }
+
+ ret = clk_prepare_enable(dp->phy_24m);
+ } else {
+ clk_disable_unprepare(dp->phy_24m);
+
+ ret = regmap_write(dp->grf, GRF_SOC_CON12,
+ GRF_EDP_PHY_SIDDQ_HIWORD_MASK |
+ GRF_EDP_PHY_SIDDQ_OFF);
+ }
+
+ return ret;
+}
+
+static int rockchip_dp_phy_power_on(struct phy *phy)
+{
+ return rockchip_set_phy_state(phy, true
Re: [PATCH V3] powerpc/mm: Fix Multi hit ERAT cause by recent THP update
Balbir Singh writes: >> Now we can't depend for mm_cpumask, a parallel find_linux_pte_hugepte >> can happen outside that. Now i had a variant for kick_all_cpus_sync that >> ignored idle cpus. But then that needs more verification. >> >> http://article.gmane.org/gmane.linux.ports.ppc.embedded/81105 > Can be racy as a CPU moves from non-idle to idle > > In > >> + pmd_hugepage_update(vma->vm_mm, address, pmdp, ~0UL, 0); >> + /* >> + * This ensures that generic code that rely on IRQ disabling >> + * to prevent a parallel THP split work as expected. >> + */ >> + kick_all_cpus_sync(); > > pmdp_invalidate()->pmd_hugepage_update() can still run in parallel with > find_linux_pte_or_hugepte() and race.. Am I missing something? > Yes. But then we make sure that the pte_t returned by find_linux_pte_or_hugepte doesn't change to a regular pmd entry by using that kick. Now callers of find_lnux_pte_or_hugepte will check for _PAGE_PRESENT. So if it called before pmd_hugepage_update(_PAGE_PRESENT), we wait for the caller to finish the usage (via kick()). Or they bail out after finding _PAGE_PRESENT cleared. -aneesh
Re: [PATCH 4.3 041/200] spi: omap2-mcspi: disable other channels CHCONF_FORCE in prepare_message
On Sun, Feb 14, 2016 at 04:50:47PM -0600, Michael Welling wrote: > spi: omap2-mcspi: Add calls for pinctrl state select That doesn't sound like stable material, it's adding a new feature which might break existing systems if they have buggy configuration defined in DT which we suddenly start using. signature.asc Description: PGP signature
[PATCH v14 0/17] Add Analogix Core Display Port Driver
Hi all,
The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
share the same IP, so a lot of parts can be re-used. I split the common
code into bridge directory, then rk3288 and exynos only need to keep
some platform code. Cause I can't find the exact IP name of exynos dp
controller, so I decide to name dp core driver with "analogix" which I
find in rk3288 eDP TRM
But there are still three light registers setting different between
exynos and rk3288.
1. RK3288 have five special pll registers which not indicate in exynos
dp controller.
2. The address of DP_PHY_PD(dp phy power manager register) are different
between rk3288 and exynos.
3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
register).
Due to Mark Yao have introduced the ATOMIC support to Rockchip drm, so it's
okay to use the ATOMIC helpers functions in connector_funcs. No need to splict
the connector init to platform driver anymore, and this is the biggest change
since version 11.
This v14 didn't have lots of new changes which seems not the correct time to
upgrade the version number, but I have changed ordering of patches (adding 2
more, and removing 2 out). Especially to prevent confusing people, so I updated
the whole series.
Thanks,
- Yakir
Changes in v14:
- Rebase the new changes in imx-dp driver
- Split up this patch into 3 parts, make this easy to review (Heiko)
- Remove the Rockchip DP PHY to an separate thread (Heiko)
https://patchwork.kernel.org/patch/8312701/
Changes in v13:
- Use .enable instead of preprare/commit in encoder_helper_funcs (Heiko)
- Fix the missing parameters with drm_encoder_init() helper function. (Heiko)
Changes in v12:
- Move the connector init to analogix_dp driver, and using ATOMIC helper (Heiko)
- Add the ack from Jingoo
- Remove the enum link_rate_type struct, using the marcos in drm_dp_helper.h
(Jingoo)
Changes in v11:
- Uses tabs to fix the indentation issues in analogix_dp_core.h (Heiko)
- Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
- Add the ack from Rob Herring
- Revert parts of Gustavo Padovan's changes in commit:
drm/exynos: do not start enabling DP at bind() phase
Add dp phy poweron function in bind time.
- Move the panel prepare from get_modes time to bind time, and move
the panel unprepare from bridge->disable to unbind time. (Heiko)
Changes in v10:
- Add the ack from Rob Herring
- Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here (Heiko)
- Add the ack from Rob Herring
- Remove the surplus "plat_data" check. (Heiko)
- switch (dp->plat_data && dp->plat_data->dev_type) {
+ switch (dp->plat_data->dev_type) {
Changes in v9:
- Document more details for 'ports' property.
Changes in v8:
- Correct the right document path of display-timing.txt (Heiko)
- Correct the misspell of 'from' to 'frm'. (Heiko)
- Modify the commit subject name. (Heiko)
Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
to avoid -EOVERFLOW error (Krzysztof)
Changes in v6:
- Fix the Kconfig recursive dependency (Javier)
- Fix Peach Pit hpd property name error:
- hpd-gpio = <&gpx2 6 0>;
+ hpd-gpios = <&gpx2 6 0>;
Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
attch function. Cause once platform failed at attach, core driver should
still failed, so no need to init connector before platform attached
(Krzysztof)
- Keep code style no changes with the previous exynos_dp_code.c in this
patch, and update commit message about the new export symbol (Krzysztof)
- Gather the device type patch (v4 11/16) into this one. (Krzysztof)
- leave out the connector registration to analogix platform driver. (Thierry)
- Resequence this patch after analogix_dp driver have been split
from exynos_dp code, and rephrase reasonable commit message, and
remove some controversial style (Krzysztof)
- analogix_dp_write_byte_to_dpcd(
- dp, DP_TEST_RESPONSE,
+ analogix_dp_write_byte_to_dpcd(dp,
+ DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);
- Switch video timing type to "u32", so driver could use "of_property_read_u32"
to get the backword timing values. Krzysztof suggest me that driver could use
the "of_property_read_bool" to get backword timing values, but that interfacs
would modify the original drm_display_mode timing directly (whether those
properties exists or not).
- Correct the misspell in commit message. (Krzysztof)
- Remove the empty line at the end of document, and correct the endpoint
numbers in the example DT node, and remove the regulator iomux setting
in driver code while using the pinctl in devicetree instead. (Heiko)
- Add
[PATCH v14 01/17] drm: bridge: analogix/dp: split exynos dp driver to bridge directory
Split the dp core driver from exynos directory to bridge directory,
and rename the core driver to analogix_dp_*, rename the platform
code to exynos_dp.
Beside the new analogix_dp driver would export six hooks.
"analogix_dp_bind()" and "analogix_dp_unbind()"
"analogix_dp_suspned()" and "analogix_dp_resume()"
"analogix_dp_detect()" and "analogix_dp_get_modes()"
The bind/unbind symbols is used for analogix platform driver to connect
with analogix_dp core driver. And the detect/get_modes is used for analogix
platform driver to init the connector.
They reason why connector need register in helper driver is rockchip drm
haven't implement the atomic API, but Exynos drm have implement it, so
there would need two different connector helper functions, that's why we
leave the connector register in helper driver.
Signed-off-by: Yakir Yang
---
Changes in v14:
- Rebase the new changes in imx-dp driver
- Split up this patch into 3 parts, make this easy to review (Heiko)
Changes in v13: None
Changes in v12:
- Move the connector init to analogix_dp driver, and using ATOMIC helper (Heiko)
Changes in v11:
- Uses tabs to fix the indentation issues in analogix_dp_core.h (Heiko)
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6:
- Fix the Kconfig recursive dependency (Javier)
Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
attch function. Cause once platform failed at attach, core driver should
still failed, so no need to init connector before platform attached
(Krzysztof)
- Keep code style no changes with the previous exynos_dp_code.c in this
patch, and update commit message about the new export symbol (Krzysztof)
- Gather the device type patch (v4 11/16) into this one. (Krzysztof)
- leave out the connector registration to analogix platform driver. (Thierry)
Changes in v4:
- Update "analogix,hpd-gpios" to "hpd-gpios" DT propery. (Rob)
- Rename "analogix_dp-exynos.c" file name to "exynos_dp.c" (Jingoo)
- Create a separate folder for analogix code in bridge/ (Archit)
Changes in v3:
- Move exynos's video_timing code to analogix_dp-exynos platform driver,
add get_modes method to struct analogix_dp_plat_data. (Thierry)
- Rename some "samsung*" dts propery to "analogix*". (Heiko)
Changes in v2:
- Remove new copyright (Jingoo)
- Fix compiled failed due to analogix_dp_device misspell
drivers/gpu/drm/bridge/Kconfig |2 +
drivers/gpu/drm/bridge/Makefile|1 +
drivers/gpu/drm/bridge/analogix/Kconfig|3 +
drivers/gpu/drm/bridge/analogix/Makefile |1 +
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1351 +++
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 277
.../analogix/analogix_dp_reg.c}| 160 +--
.../analogix/analogix_dp_reg.h}|8 +-
drivers/gpu/drm/exynos/Kconfig |3 +-
drivers/gpu/drm/exynos/Makefile|2 +-
drivers/gpu/drm/exynos/exynos_dp_core.c| 1352 ++--
drivers/gpu/drm/exynos/exynos_dp_core.h| 282
include/drm/bridge/analogix_dp.h | 40 +
13 files changed, 1845 insertions(+), 1637 deletions(-)
create mode 100644 drivers/gpu/drm/bridge/analogix/Kconfig
create mode 100644 drivers/gpu/drm/bridge/analogix/Makefile
create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
rename drivers/gpu/drm/{exynos/exynos_dp_reg.c =>
bridge/analogix/analogix_dp_reg.c} (84%)
rename drivers/gpu/drm/{exynos/exynos_dp_reg.h =>
bridge/analogix/analogix_dp_reg.h} (98%)
delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.h
create mode 100644 include/drm/bridge/analogix_dp.h
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 27e2022..efd94e0 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -40,4 +40,6 @@ config DRM_PARADE_PS8622
---help---
Parade eDP-LVDS bridge chip driver.
+source "drivers/gpu/drm/bridge/analogix/Kconfig"
+
endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index f13c33d..ff821f4 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
b/drivers/gpu/drm/bridge/analogix/Kconfig
new file mode 100644
index 000..80f286f
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -0,0 +1,3 @@
+config DRM_ANALO
[PATCH v14 08/17] ARM: dts: exynos/dp: remove some properties that deprecated by analogix_dp driver
After exynos_dp have been split the common IP code into analogix_dp driver,
the analogix_dp driver have deprecated some Samsung platform properties which
could be dynamically parsed from EDID/MODE/DPCD message, so this is an update
for Exynos DTS file for dp-controller.
Beside the backward compatibility is fully preserved, so there are no
bisectability break that make this change in a separate patch.
Signed-off-by: Yakir Yang
Reviewed-by: Krzysztof Kozlowski
Tested-by: Javier Martinez Canillas
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6:
- Fix Peach Pit hpd property name error:
- hpd-gpio = <&gpx2 6 0>;
+ hpd-gpios = <&gpx2 6 0>;
Changes in v5:
- Correct the misspell in commit message. (Krzysztof)
Changes in v4:
- Separate all DTS changes to a separate patch. (Krzysztof)
Changes in v3: None
Changes in v2: None
arch/arm/boot/dts/exynos5250-arndale.dts | 2 --
arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 --
arch/arm/boot/dts/exynos5250-snow-common.dtsi | 4 +---
arch/arm/boot/dts/exynos5250-spring.dts | 4 +---
arch/arm/boot/dts/exynos5420-peach-pit.dts| 4 +---
arch/arm/boot/dts/exynos5420-smdk5420.dts | 2 --
arch/arm/boot/dts/exynos5800-peach-pi.dts | 2 --
7 files changed, 3 insertions(+), 17 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index c000532..b1790cf 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -124,8 +124,6 @@
&dp {
status = "okay";
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 0f5dcd4..f30c2db 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -80,8 +80,6 @@
&dp {
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
index 5cb33ba..b96624b 100644
--- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -236,12 +236,10 @@
pinctrl-names = "default";
pinctrl-0 = <&dp_hpd>;
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <2>;
- samsung,hpd-gpio = <&gpx0 7 GPIO_ACTIVE_HIGH>;
+ hpd-gpios = <&gpx0 7 GPIO_ACTIVE_HIGH>;
ports {
port@0 {
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
index c1edd6d..91881d7 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -74,12 +74,10 @@
pinctrl-names = "default";
pinctrl-0 = <&dp_hpd_gpio>;
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <1>;
- samsung,hpd-gpio = <&gpc3 0 GPIO_ACTIVE_HIGH>;
+ hpd-gpios = <&gpc3 0 GPIO_ACTIVE_HIGH>;
};
&ehci {
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 35cfb07..2f37c87 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -148,12 +148,10 @@
pinctrl-names = "default";
pinctrl-0 = <&dp_hpd_gpio>;
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x06>;
samsung,lane-count = <2>;
- samsung,hpd-gpio = <&gpx2 6 GPIO_ACTIVE_HIGH>;
+ hpd-gpios = <&gpx2 6 GPIO_ACTIVE_HIGH>;
ports {
port@0 {
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index ac35aef..f67344f 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -93,8 +93,6 @@
pinctrl-names = "default";
pinctrl-0 = <&dp_hpd>;
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
[PATCH v14 06/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range
Both hsync/vsync polarity and interlace mode can be parsed from
drm display mode, and dynamic_range and ycbcr_coeff can be judge
by the video code.
But presumably Exynos still relies on the DT properties, so take
good use of mode_fixup() in to achieve the compatibility hacks.
Signed-off-by: Yakir Yang
Reviewed-by: Krzysztof Kozlowski
Tested-by: Javier Martinez Canillas
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
to avoid -EOVERFLOW error (Krzysztof)
Changes in v6: None
Changes in v5:
- Switch video timing type to "u32", so driver could use "of_property_read_u32"
to get the backword timing values. Krzysztof suggest me that driver could use
the "of_property_read_bool" to get backword timing values, but that interfacs
would modify the original drm_display_mode timing directly (whether those
properties exists or not).
Changes in v4:
- Provide backword compatibility with samsung. (Krzysztof)
Changes in v3:
- Dynamic parse video timing info from struct drm_display_mode and
struct drm_display_info. (Thierry)
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 148 +
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 +-
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 14 +-
3 files changed, 103 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index b948636..26359f4 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -893,8 +893,8 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
return;
}
- ret = analogix_dp_set_link_train(dp, dp->video_info->lane_count,
-dp->video_info->link_rate);
+ ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
+dp->video_info.link_rate);
if (ret) {
dev_err(dp->dev, "unable to do link train\n");
return;
@@ -1077,6 +1077,85 @@ static void analogix_dp_bridge_disable(struct drm_bridge
*bridge)
dp->dpms_mode = DRM_MODE_DPMS_OFF;
}
+static void analogix_dp_bridge_mode_set(struct drm_bridge *bridge,
+ struct drm_display_mode *orig_mode,
+ struct drm_display_mode *mode)
+{
+ struct analogix_dp_device *dp = bridge->driver_private;
+ struct drm_display_info *display_info = &dp->connector.display_info;
+ struct video_info *video = &dp->video_info;
+ struct device_node *dp_node = dp->dev->of_node;
+ int vic;
+
+ /* Input video interlaces & hsync pol & vsync pol */
+ video->interlaced = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
+ video->v_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NVSYNC);
+ video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
+
+ /* Input video dynamic_range & colorimetry */
+ vic = drm_match_cea_mode(mode);
+ if ((vic == 6) || (vic == 7) || (vic == 21) || (vic == 22) ||
+ (vic == 2) || (vic == 3) || (vic == 17) || (vic == 18)) {
+ video->dynamic_range = CEA;
+ video->ycbcr_coeff = COLOR_YCBCR601;
+ } else if (vic) {
+ video->dynamic_range = CEA;
+ video->ycbcr_coeff = COLOR_YCBCR709;
+ } else {
+ video->dynamic_range = VESA;
+ video->ycbcr_coeff = COLOR_YCBCR709;
+ }
+
+ /* Input vide bpc and color_formats */
+ switch (display_info->bpc) {
+ case 12:
+ video->color_depth = COLOR_12;
+ break;
+ case 10:
+ video->color_depth = COLOR_10;
+ break;
+ case 8:
+ video->color_depth = COLOR_8;
+ break;
+ case 6:
+ video->color_depth = COLOR_6;
+ break;
+ default:
+ video->color_depth = COLOR_8;
+ break;
+ }
+ if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB444)
+ video->color_space = COLOR_YCBCR444;
+ else if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB422)
+ video->color_space = COLOR_YCBCR422;
+ else if (display_info->color_formats & DRM_COLOR_FORMAT_RGB444)
+ video->color_space = COLOR_RGB;
+ else
+ video->color_space = COLOR_RGB;
+
+ /*
+* NOTE: those property parsing code is used for providing backward
+* compatibility for samsung platform.
+* Due to we used the "of_property_read_u32" interfaces, when this
+
[PATCH v14 10/17] dt-bindings: add document for rockchip variant of analogix_dp
Rockchip DP driver is a helper driver of analogix_dp coder driver,
so most of the DT property should be descriped in analogix_dp document.
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
Reviewed-by: Heiko Stuebner
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10:
- Add the ack from Rob Herring
Changes in v9:
- Document more details for 'ports' property.
Changes in v8:
- Modify the commit subject name. (Heiko)
Changes in v7: None
Changes in v6: None
Changes in v5:
- Split binding doc's from driver changes. (Rob)
- Add eDP hotplug pinctrl property. (Heiko)
Changes in v4: None
Changes in v3: None
Changes in v2: None
.../display/rockchip/analogix_dp-rockchip.txt | 91 ++
1 file changed, 91 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
diff --git
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
new file mode 100644
index 000..04d99e3
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -0,0 +1,91 @@
+Rockchip RK3288 specific extensions to the Analogix Display Port
+
+
+Required properties:
+- compatible: "rockchip,rk3288-edp";
+
+- reg: physical base address of the controller and length
+
+- clocks: from common clock binding: handle to dp clock.
+ of memory mapped region.
+
+- clock-names: from common clock binding:
+ Required elements: "dp" "pclk"
+
+- resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+
+- pinctrl-names: Names corresponding to the chip hotplug pinctrl states.
+- pinctrl-0: pin-control mode. should be <&edp_hpd>
+
+- reset-names: Must include the name "dp"
+
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+
+- ports: there are 2 port nodes with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+Port 0: contained 2 endpoints, connecting to the output of vop.
+Port 1: contained 1 endpoint, connecting to the input of panel.
+
+For the below properties, please refer to Analogix DP binding document:
+ * Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
+- phys (required)
+- phy-names (required)
+- hpd-gpios (optional)
+---
+
+Example:
+ dp-controller: dp@ff97 {
+ compatible = "rockchip,rk3288-dp";
+ reg = <0xff97 0x4000>;
+ interrupts = ;
+ clocks = <&cru SCLK_EDP>, <&cru PCLK_EDP_CTRL>;
+ clock-names = "dp", "pclk";
+ phys = <&dp_phy>;
+ phy-names = "dp";
+
+ rockchip,grf = <&grf>;
+ resets = <&cru 111>;
+ reset-names = "dp";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&edp_hpd>;
+
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ edp_in: port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ edp_in_vopb: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vopb_out_edp>;
+ };
+ edp_in_vopl: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&vopl_out_edp>;
+ };
+ };
+
+ edp_out: port@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ edp_out_panel: endpoint {
+ reg = <0>;
+ remote-endpoint = <&panel_in_edp>
+ };
+ };
+ };
+ };
+
+ pinctrl {
+ edp {
+ edp_hpd: edp-hpd {
+ rockchip,pins = <7 11 RK_FUNC_2
&pcfg_pull_none>;
+ };
+ };
+ };
--
1.9.1
[PATCH v14 07/17] dt-bindings: add document for analogix display port driver
Analogix dp driver is split from exynos dp driver, so we just
make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
Beside update some exynos dtsi file with the latest change
according to the devicetree binding documents.
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10:
- Add the ack from Rob Herring
Changes in v9: None
Changes in v8:
- Correct the right document path of display-timing.txt (Heiko)
- Correct the misspell of 'from' to 'frm'. (Heiko)
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Split all DTS changes, and provide backward compatibility. Mark old
properties as deprecated but still support them. (Krzysztof)
- Update "analogix,hpd-gpio" to "hpd-gpios" prop name. (Rob)
- Deprecated some properties which could parsed from Edid/Mode/DPCD. (Thierry)
"analogix,color-space" & "analogix,color-depth" &
"analogix,link-rate" & "analogix,lane-count"&
"analogix,ycbcr-coeff" & "analogix,dynamic-range" &
"vsync-active-high"& "hsync-active-high" & "interlaces"
Changes in v3:
- Add devicetree binding documents. (Heiko)
- Remove sync pol & colorimetry properies from the new analogix dp driver
devicetree binding. (Thierry)
- Update the exist exynos dtsi file with the latest DP DT properies.
Changes in v2: None
.../bindings/display/bridge/analogix_dp.txt| 50
.../bindings/display/exynos/exynos_dp.txt | 92 ++
2 files changed, 76 insertions(+), 66 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
new file mode 100644
index 000..7659a7a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
@@ -0,0 +1,50 @@
+Analogix Display Port bridge bindings
+
+Required properties for dp-controller:
+ -compatible:
+ platform specific such as:
+* "samsung,exynos5-dp"
+* "rockchip,rk3288-dp"
+ -reg:
+ physical base address of the controller and length
+ of memory mapped region.
+ -interrupts:
+ interrupt combiner values.
+ -clocks:
+ from common clock binding: handle to dp clock.
+ -clock-names:
+ from common clock binding: Shall be "dp".
+ -interrupt-parent:
+ phandle to Interrupt combiner node.
+ -phys:
+ from general PHY binding: the phandle for the PHY device.
+ -phy-names:
+ from general PHY binding: Should be "dp".
+
+Optional properties for dp-controller:
+ -hpd-gpios:
+ Hotplug detect GPIO.
+ Indicates which GPIO should be used for hotplug detection
+ -port@[X]: SoC specific port nodes with endpoint definitions as defined
+ in Documentation/devicetree/bindings/media/video-interfaces.txt,
+ please refer to the SoC specific binding document:
+ * Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+ *
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
+
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+---
+
+Example:
+
+ dp-controller {
+ compatible = "samsung,exynos5-dp";
+ reg = <0x145b 0x1>;
+ interrupts = <10 3>;
+ interrupt-parent = <&combiner>;
+ clocks = <&clock 342>;
+ clock-names = "dp";
+
+ phys = <&dp_phy>;
+ phy-names = "dp";
+ };
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
index fe4a7a2..4fa8aca 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
@@ -1,20 +1,3 @@
-Device-Tree bindings for Samsung Exynos Embedded DisplayPort Transmitter(eDP)
-
-DisplayPort is industry standard to accommodate the growing board adoption
-of digital display technology within the PC and CE industries.
-It consolidates the internal and external connection methods to reduce device
-complexity and cost. It also supports necessary features for important cross
-industry applications and provides performance scalability to enable the next
-generation of displays that feature higher color depths, refresh rates, and
-display resolutions.
-
-eDP (embedded display port) device is compliant with Embedded DisplayPort
-standard as follows,
-- DisplayPort standard 1.1a for Exynos5250 and Exynos5260.
-- DisplayPort standard 1.3 for Exynos5422s and Exynos5
[PATCH v14 05/17] drm: bridge: analogix/dp: remove duplicate configuration of link rate and link count
link_rate and lane_count already configured in analogix_dp_set_link_train(),
so we don't need to config those repeatly after training finished, just
remove them out.
Beside Display Port 1.2 already support 5.4Gbps link rate, the maximum sets
would change from {1.62Gbps, 2.7Gbps} to {1.62Gbps, 2.7Gbps, 5.4Gbps}.
Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas
---
Changes in v14: None
Changes in v13: None
Changes in v12:
- Remove the enum link_rate_type struct, using the marcos in drm_dp_helper.h
(Jingoo)
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Update commit message more readable. (Jingoo)
- Adjust the order from 05 to 04
Changes in v3:
- The link_rate and lane_count shouldn't config to the DT property value
directly, but we can take those as hardware limite. For example, RK3288
only support 4 physical lanes of 2.7/1.62 Gbps/lane, so DT property would
like "link-rate = 0x0a" "lane-count = 4". (Thierry)
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 14 +++---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 7 +--
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 2 +-
3 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 6901a6f..b948636 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -627,6 +627,8 @@ static void analogix_dp_get_max_rx_bandwidth(struct
analogix_dp_device *dp,
/*
* For DP rev.1.1, Maximum link rate of Main Link lanes
* 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps
+* For DP rev.1.2, Maximum link rate of Main Link lanes
+* 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps, 0x14 = 5.4Gbps
*/
analogix_dp_read_byte_from_dpcd(dp, DP_MAX_LINK_RATE, &data);
*bandwidth = data;
@@ -647,7 +649,7 @@ static void analogix_dp_get_max_rx_lane_count(struct
analogix_dp_device *dp,
static void analogix_dp_init_training(struct analogix_dp_device *dp,
enum link_lane_count_type max_lane,
- enum link_rate_type max_rate)
+ int max_rate)
{
/*
* MACRO_RST must be applied after the PLL_LOCK to avoid
@@ -659,11 +661,12 @@ static void analogix_dp_init_training(struct
analogix_dp_device *dp,
analogix_dp_get_max_rx_bandwidth(dp, &dp->link_train.link_rate);
analogix_dp_get_max_rx_lane_count(dp, &dp->link_train.lane_count);
- if ((dp->link_train.link_rate != LINK_RATE_1_62GBPS) &&
- (dp->link_train.link_rate != LINK_RATE_2_70GBPS)) {
+ if ((dp->link_train.link_rate != DP_LINK_BW_1_62) &&
+ (dp->link_train.link_rate != DP_LINK_BW_2_7) &&
+ (dp->link_train.link_rate != DP_LINK_BW_5_4)) {
dev_err(dp->dev, "Rx Max Link Rate is abnormal :%x !\n",
dp->link_train.link_rate);
- dp->link_train.link_rate = LINK_RATE_1_62GBPS;
+ dp->link_train.link_rate = DP_LINK_BW_1_62;
}
if (dp->link_train.lane_count == 0) {
@@ -901,9 +904,6 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
analogix_dp_enable_rx_to_enhanced_mode(dp, 1);
analogix_dp_enable_enhanced_mode(dp, 1);
- analogix_dp_set_lane_count(dp, dp->video_info->lane_count);
- analogix_dp_set_link_bandwidth(dp, dp->video_info->link_rate);
-
analogix_dp_init_video(dp);
ret = analogix_dp_config_video(dp);
if (ret)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index d4c4ae2..afb0a53 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -20,11 +20,6 @@
#define MAX_CR_LOOP 5
#define MAX_EQ_LOOP 5
-enum link_rate_type {
- LINK_RATE_1_62GBPS = 0x06,
- LINK_RATE_2_70GBPS = 0x0a
-};
-
enum link_lane_count_type {
LANE_COUNT1 = 1,
LANE_COUNT2 = 2,
@@ -128,7 +123,7 @@ struct video_info {
enum color_coefficient ycbcr_coeff;
enum color_depth color_depth;
- enum link_rate_type link_rate;
+ int link_rate;
enum link_lane_count_type lane_count;
};
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index a388c0a..eb0b63c 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -855,7 +855,7 @@ void analogix_dp_set_link_bandwidth(struct
analogix_dp_device *dp, u32 bwtype)
u32 reg;
reg = bwtype;
- if ((bwtype == LINK_RATE_2_70GBPS) || (bwtype == LINK_RATE_1_62GBPS))
+
[PATCH v14 03/17] drm: bridge: analogix/dp: rename register constants
From: Heiko Stuebner
In the original split we kept the register constants intact to keep the
diff small. Still the constants are Analogix-specific, so rename them now.
Signed-off-by: Heiko Stuebner
Signed-off-by: Yakir Yang
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 456 +++---
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 248 ++--
2 files changed, 352 insertions(+), 352 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 0b926ea..442cc66 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -29,13 +29,13 @@ void analogix_dp_enable_video_mute(struct
analogix_dp_device *dp, bool enable)
u32 reg;
if (enable) {
- reg = readl(dp->reg_base + EXYNOS_DP_VIDEO_CTL_1);
+ reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_1);
reg |= HDCP_VIDEO_MUTE;
- writel(reg, dp->reg_base + EXYNOS_DP_VIDEO_CTL_1);
+ writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_1);
} else {
- reg = readl(dp->reg_base + EXYNOS_DP_VIDEO_CTL_1);
+ reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_1);
reg &= ~HDCP_VIDEO_MUTE;
- writel(reg, dp->reg_base + EXYNOS_DP_VIDEO_CTL_1);
+ writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_1);
}
}
@@ -43,9 +43,9 @@ void analogix_dp_stop_video(struct analogix_dp_device *dp)
{
u32 reg;
- reg = readl(dp->reg_base + EXYNOS_DP_VIDEO_CTL_1);
+ reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_1);
reg &= ~VIDEO_EN;
- writel(reg, dp->reg_base + EXYNOS_DP_VIDEO_CTL_1);
+ writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_1);
}
void analogix_dp_lane_swap(struct analogix_dp_device *dp, bool enable)
@@ -59,7 +59,7 @@ void analogix_dp_lane_swap(struct analogix_dp_device *dp,
bool enable)
reg = LANE3_MAP_LOGIC_LANE_3 | LANE2_MAP_LOGIC_LANE_2 |
LANE1_MAP_LOGIC_LANE_1 | LANE0_MAP_LOGIC_LANE_0;
- writel(reg, dp->reg_base + EXYNOS_DP_LANE_MAP);
+ writel(reg, dp->reg_base + ANALOGIX_DP_LANE_MAP);
}
void analogix_dp_init_analog_param(struct analogix_dp_device *dp)
@@ -67,41 +67,41 @@ void analogix_dp_init_analog_param(struct
analogix_dp_device *dp)
u32 reg;
reg = TX_TERMINAL_CTRL_50_OHM;
- writel(reg, dp->reg_base + EXYNOS_DP_ANALOG_CTL_1);
+ writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_1);
reg = SEL_24M | TX_DVDD_BIT_1_0625V;
- writel(reg, dp->reg_base + EXYNOS_DP_ANALOG_CTL_2);
+ writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_2);
reg = DRIVE_DVDD_BIT_1_0625V | VCO_BIT_600_MICRO;
- writel(reg, dp->reg_base + EXYNOS_DP_ANALOG_CTL_3);
+ writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_3);
reg = PD_RING_OSC | AUX_TERMINAL_CTRL_50_OHM |
TX_CUR1_2X | TX_CUR_16_MA;
- writel(reg, dp->reg_base + EXYNOS_DP_PLL_FILTER_CTL_1);
+ writel(reg, dp->reg_base + ANALOGIX_DP_PLL_FILTER_CTL_1);
reg = CH3_AMP_400_MV | CH2_AMP_400_MV |
CH1_AMP_400_MV | CH0_AMP_400_MV;
- writel(reg, dp->reg_base + EXYNOS_DP_TX_AMP_TUNING_CTL);
+ writel(reg, dp->reg_base + ANALOGIX_DP_TX_AMP_TUNING_CTL);
}
void analogix_dp_init_interrupt(struct analogix_dp_device *dp)
{
/* Set interrupt pin assertion polarity as high */
- writel(INT_POL1 | INT_POL0, dp->reg_base + EXYNOS_DP_INT_CTL);
+ writel(INT_POL1 | INT_POL0, dp->reg_base + ANALOGIX_DP_INT_CTL);
/* Clear pending regisers */
- writel(0xff, dp->reg_base + EXYNOS_DP_COMMON_INT_STA_1);
- writel(0x4f, dp->reg_base + EXYNOS_DP_COMMON_INT_STA_2);
- writel(0xe0, dp->reg_base + EXYNOS_DP_COMMON_INT_STA_3);
- writel(0xe7, dp->reg_base + EXYNOS_DP_COMMON_INT_STA_4);
- writel(0x63, dp->reg_base + EXYNOS_DP_INT_STA);
+ writel(0xff, dp->reg_base + ANALOGIX_DP_COMMON_INT_STA_1);
+ writel(0x4f, dp->reg_base + ANALOGIX_DP_COMMON_INT_STA_2);
+ writel(0xe0, dp->reg_base + ANALOGIX_DP_COMMON_INT_STA_3);
+ writel(0xe7, dp->reg_base + ANALOGIX_DP_COMMON_INT_STA_4);
+ writel(0x63, dp->reg_base + ANALOGIX_DP_INT_STA);
/* 0:mask,1: unmask */
- writel(0x00, dp->reg_base + EXYNOS_DP_COMMON_INT_MASK_1);
- writel(0x00, dp->reg_base + EXYNOS_DP_COMMON_INT_MASK_2);
- writel(0x00, dp->reg_base + EXYNOS_DP_COMMON_INT_MASK_3);
- writel(0x00, dp->reg_base + EXYNOS_DP_COMMON_INT_MASK_4);
- writel(0x00, dp->reg_base + EXYNOS
[PATCH v14 09/17] drm: rockchip: dp: add rockchip platform dp driver
Rockchip have three clocks for dp controller, we leave pclk_edp
to analogix_dp driver control, and keep the sclk_edp_24m and
sclk_edp in platform driver.
Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas
---
Changes in v14: None
Changes in v13:
- Use .enable instead of preprare/commit in encoder_helper_funcs (Heiko)
- Fix the missing parameters with drm_encoder_init() helper function. (Heiko)
Changes in v12: None
Changes in v11: None
Changes in v10:
- Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here (Heiko)
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- Remove the empty line at the end of document, and correct the endpoint
numbers in the example DT node, and remove the regulator iomux setting
in driver code while using the pinctl in devicetree instead. (Heiko)
- Add device type declared, cause the previous "platform device type
support (v4 11/16)" already merge into (v5 02/14).
- Implement connector registration code. (Thierry)
Changes in v4:
- Remove some deprecated DT properties in rockchip dp document.
Changes in v3:
- Leave "sclk_edp_24m" to rockchip dp phy driver which name to "24m",
and leave "sclk_edp" to analogix dp core driver which name to "dp",
and leave "pclk_edp" to rockchip dp platform driver which name to
"pclk". (Thierry & Heiko)
- Add devicetree binding document. (Heiko)
- Remove "rockchip,panel" DT property, take use of remote point to get panel
node. (Heiko)
- Add the new function point dp_platdata->get_modes() init.
Changes in v2:
- Get panel node with remote-endpoint method, and create devicetree binding
for driver. (Heiko)
- Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m",
leave those clock to rockchip dp phy driver.
drivers/gpu/drm/rockchip/Kconfig| 9 +
drivers/gpu/drm/rockchip/Makefile | 1 +
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 384
include/drm/bridge/analogix_dp.h| 1 +
4 files changed, 395 insertions(+)
create mode 100644 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 8573985..9fe4e32 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -35,3 +35,12 @@ config ROCKCHIP_DW_MIPI_DSI
for the Synopsys DesignWare HDMI driver. If you want to
enable MIPI DSI on RK3288 based SoC, you should selet this
option.
+
+config ROCKCHIP_ANALOGIX_DP
+ tristate "Rockchip specific extensions for Analogix DP driver"
+ depends on DRM_ROCKCHIP
+ select DRM_ANALOGIX_DP
+ help
+ This selects support for Rockchip SoC specific extensions
+ for the Analogix Core DP driver. If you want to enable DP
+ on RK3288 based SoC, you should selet this option.
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index f6a809a..921fabf 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -8,5 +8,6 @@ rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) +=
rockchip_drm_fbdev.o
obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
+obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_vop_reg.o
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
new file mode 100644
index 000..b7af1b7
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -0,0 +1,384 @@
+/*
+ * Rockchip SoC DP (Display Port) interface driver.
+ *
+ * Copyright (C) Fuzhou Rockchip Electronics Co., Ltd.
+ * Author: Andy Yan
+ * Yakir Yang
+ * Jeff Chen
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#define to_dp(nm) container_of(nm, struct rockchip_dp_device, nm)
+
+/* dp grf register offset */
+#define GRF_SOC_CON60x025c
+#define GRF_EDP_LCD_SEL_MASKBIT(5)
+#define GRF_EDP_SEL_VOP_LIT BIT(5)
+#define GRF_EDP_SEL_VOP_BIG 0
+
+struct rockchip_dp_device {
+ struct drm_device*drm_dev;
+ struct device*dev;
+ struct drm_encoder encoder;
+ struct drm_display_mode mode;
+
+ struct clk *pclk;
+ struct regmap*grf;
+ struct reset_control *rst;
+
+ struct
[PATCH v14 11/17] drm: bridge: analogix/dp: add some rk3288 special registers setting
RK3288 need some special registers setting, we can separate
them out by the dev_type of plat_data.
Signed-off-by: Yakir Yang
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Fix compile failed dut to phy_pd_addr variable misspell error
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 76 ++-
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 12
2 files changed, 60 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 3858df5..1e24b37 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -15,6 +15,8 @@
#include
#include
+#include
+
#include "analogix_dp_core.h"
#include "analogix_dp_reg.h"
@@ -72,6 +74,14 @@ void analogix_dp_init_analog_param(struct analogix_dp_device
*dp)
reg = SEL_24M | TX_DVDD_BIT_1_0625V;
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_2);
+ if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP)) {
+ writel(REF_CLK_24M, dp->reg_base + ANALOGIX_DP_PLL_REG_1);
+ writel(0x95, dp->reg_base + ANALOGIX_DP_PLL_REG_2);
+ writel(0x40, dp->reg_base + ANALOGIX_DP_PLL_REG_3);
+ writel(0x58, dp->reg_base + ANALOGIX_DP_PLL_REG_4);
+ writel(0x22, dp->reg_base + ANALOGIX_DP_PLL_REG_5);
+ }
+
reg = DRIVE_DVDD_BIT_1_0625V | VCO_BIT_600_MICRO;
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_3);
@@ -206,81 +216,85 @@ void analogix_dp_set_analog_power_down(struct
analogix_dp_device *dp,
bool enable)
{
u32 reg;
+ u32 phy_pd_addr = ANALOGIX_DP_PHY_PD;
+
+ if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP))
+ phy_pd_addr = ANALOGIX_DP_PD;
switch (block) {
case AUX_BLOCK:
if (enable) {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg |= AUX_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
} else {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~AUX_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH0_BLOCK:
if (enable) {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH0_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
} else {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH0_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH1_BLOCK:
if (enable) {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH1_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
} else {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH1_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH2_BLOCK:
if (enable) {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH2_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
} else {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH2_PD;
- writel(reg, dp->reg_base + ANALOGIX_D
[PATCH v14 15/17] drm: bridge: analogix/dp: add edid modes parse in get_modes method
Display Port monitor could support kinds of mode which indicate
in monitor edid, not just one single display resolution which
defined in panel or devivetree property display timing.
Note: Gustavo Padovan try to remove the controller and phy
power on function in bind time at bellow commit:
drm/exynos: do not start enabling DP at bind() phase
But for now driver need to read edid message in .get_modes()
function, so controller must be inited in bind time, so we
need to add controller init back.
Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Call drm_panel_prepare() in .get_modes function, ensure panel should
power on before driver try to read edid message.
Changes in v3:
- Add edid modes parse support
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 17
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 46 +++---
2 files changed, 33 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index cfdf695..bc59e8d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -110,7 +110,7 @@ static unsigned char
analogix_dp_calc_edid_check_sum(unsigned char *edid_data)
static int analogix_dp_read_edid(struct analogix_dp_device *dp)
{
- unsigned char edid[EDID_BLOCK_LENGTH * 2];
+ unsigned char *edid = dp->edid;
unsigned int extend_block = 0;
unsigned char sum;
unsigned char test_vector;
@@ -904,12 +904,6 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
DRM_ERROR("failed to disable the panel\n");
}
- ret = analogix_dp_handle_edid(dp);
- if (ret) {
- dev_err(dp->dev, "unable to handle edid\n");
- return;
- }
-
ret = analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
dp->video_info.max_link_rate);
if (ret) {
@@ -939,8 +933,14 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
int analogix_dp_get_modes(struct drm_connector *connector)
{
struct analogix_dp_device *dp = to_dp(connector);
+ struct edid *edid = (struct edid *)dp->edid;
int num_modes = 0;
+ if (analogix_dp_handle_edid(dp) == 0) {
+ drm_mode_connector_update_edid_property(&dp->connector, edid);
+ num_modes += drm_add_edid_modes(&dp->connector, edid);
+ }
+
if (dp->plat_data->panel)
num_modes += drm_panel_get_modes(dp->plat_data->panel);
@@ -978,6 +978,7 @@ static void analogix_dp_connector_destroy(struct
drm_connector *connector)
{
drm_connector_unregister(connector);
drm_connector_cleanup(connector);
+
}
static const struct drm_connector_funcs analogix_dp_connector_funcs = {
@@ -1348,6 +1349,8 @@ int analogix_dp_bind(struct device *dev, struct
drm_device *drm_dev,
}
}
+ analogix_dp_init_dp(dp);
+
ret = devm_request_irq(&pdev->dev, dp->irq, analogix_dp_irq_handler,
irq_flags, "analogix-dp", dp);
if (ret) {
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 22aff07..48b4a87 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -20,6 +20,28 @@
#define MAX_CR_LOOP 5
#define MAX_EQ_LOOP 5
+/* I2C EDID Chip ID, Slave Address */
+#define I2C_EDID_DEVICE_ADDR 0x50
+#define I2C_E_EDID_DEVICE_ADDR 0x30
+
+#define EDID_BLOCK_LENGTH 0x80
+#define EDID_HEADER_PATTERN0x00
+#define EDID_EXTENSION_FLAG0x7e
+#define EDID_CHECKSUM 0x7f
+
+/* DP_MAX_LANE_COUNT */
+#define DPCD_ENHANCED_FRAME_CAP(x) (((x) >> 7) & 0x1)
+#define DPCD_MAX_LANE_COUNT(x) ((x) & 0x1f)
+
+/* DP_LANE_COUNT_SET */
+#define DPCD_LANE_COUNT_SET(x) ((x) & 0x1f)
+
+/* DP_TRAINING_LANE0_SET */
+#define DPCD_PRE_EMPHASIS_SET(x) (((x) & 0x3) << 3)
+#define DPCD_PRE_EMPHASIS_GET(x) (((x) >> 3) & 0x3)
+#define DPCD_VOLTAGE_SWING_SET(x) (((x) & 0x3) << 0)
+#define DPCD_VOLTAGE_SWING_GET(x) (((x) >> 0) & 0x3)
+
enum link_lane_count_type {
LANE_COUNT1 = 1,
LANE_COUNT2 = 2,
@@ -155,6 +177,7 @@ struct analogix_dp_device {
int dpms_mode;
int hpd_gpio;
boolforce_hpd;
+ unsigned char
[PATCH v14 16/17] drm: bridge: analogix/dp: add panel prepare/unprepare in suspend/resume time
Turn off the panel power in suspend time would help to reduce
power waste.
Signed-off-by: Yakir Yang
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index bc59e8d..5292b28 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1400,6 +1400,12 @@ int analogix_dp_suspend(struct device *dev)
struct analogix_dp_device *dp = dev_get_drvdata(dev);
clk_disable_unprepare(dp->clock);
+
+ if (dp->plat_data->panel) {
+ if (drm_panel_unprepare(dp->plat_data->panel))
+ DRM_ERROR("failed to turnoff the panel\n");
+ }
+
return 0;
}
EXPORT_SYMBOL_GPL(analogix_dp_suspend);
@@ -1415,6 +1421,13 @@ int analogix_dp_resume(struct device *dev)
return ret;
}
+ if (dp->plat_data->panel) {
+ if (drm_panel_prepare(dp->plat_data->panel)) {
+ DRM_ERROR("failed to setup the panel\n");
+ return -EBUSY;
+ }
+ }
+
return 0;
}
EXPORT_SYMBOL_GPL(analogix_dp_resume);
--
1.9.1
[PATCH v14 14/17] drm: bridge: analogix/dp: move hpd detect to connector detect function
This change just make a little clean to make code more like
drm core expect, move hdp detect code from bridge->enable(),
and place them into connector->detect().
Note: Gustavo Padovan try to remove the controller and phy
power on function in bind time at bellow commit:
drm/exynos: do not start enabling DP at bind() phase
But for now the connector status don't hardcode to connected,
need to operate dp phy in .detect function, so we need to revert
parts if Gustavo Padovan's changes, add phy poweron
function in bind time.
Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11:
- Revert parts of Gustavo Padovan's changes in commit:
drm/exynos: do not start enabling DP at bind() phase
Add dp phy poweron function in bind time.
- Move the panel prepare from get_modes time to bind time, and move
the panel unprepare from bridge->disable to unbind time. (Heiko)
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Take Jingoo suggest, add commit messages.
Changes in v3:
- move dp hpd detect to connector detect function.
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 38 --
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 13986b7..cfdf695 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -904,12 +904,6 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
DRM_ERROR("failed to disable the panel\n");
}
- ret = analogix_dp_detect_hpd(dp);
- if (ret) {
- /* Cable has been disconnected, we're done */
- return;
- }
-
ret = analogix_dp_handle_edid(dp);
if (ret) {
dev_err(dp->dev, "unable to handle edid\n");
@@ -972,6 +966,11 @@ static const struct drm_connector_helper_funcs
analogix_dp_connector_helper_func
enum drm_connector_status
analogix_dp_detect(struct drm_connector *connector, bool force)
{
+ struct analogix_dp_device *dp = to_dp(connector);
+
+ if (analogix_dp_detect_hpd(dp))
+ return connector_status_disconnected;
+
return connector_status_connected;
}
@@ -1051,13 +1050,6 @@ static void analogix_dp_bridge_enable(struct drm_bridge
*bridge)
pm_runtime_get_sync(dp->dev);
- if (dp->plat_data->panel) {
- if (drm_panel_prepare(dp->plat_data->panel)) {
- DRM_ERROR("failed to setup the panel\n");
- return;
- }
- }
-
if (dp->plat_data->power_on)
dp->plat_data->power_on(dp->plat_data);
@@ -1090,11 +1082,6 @@ static void analogix_dp_bridge_disable(struct drm_bridge
*bridge)
if (dp->plat_data->power_off)
dp->plat_data->power_off(dp->plat_data);
- if (dp->plat_data->panel) {
- if (drm_panel_unprepare(dp->plat_data->panel))
- DRM_ERROR("failed to turnoff the panel\n");
- }
-
pm_runtime_put_sync(dp->dev);
dp->dpms_mode = DRM_MODE_DPMS_OFF;
@@ -1352,6 +1339,15 @@ int analogix_dp_bind(struct device *dev, struct
drm_device *drm_dev,
pm_runtime_enable(dev);
+ phy_power_on(dp->phy);
+
+ if (dp->plat_data->panel) {
+ if (drm_panel_prepare(dp->plat_data->panel)) {
+ DRM_ERROR("failed to setup the panel\n");
+ return -EBUSY;
+ }
+ }
+
ret = devm_request_irq(&pdev->dev, dp->irq, analogix_dp_irq_handler,
irq_flags, "analogix-dp", dp);
if (ret) {
@@ -1385,6 +1381,12 @@ void analogix_dp_unbind(struct device *dev, struct
device *master,
struct analogix_dp_device *dp = dev_get_drvdata(dev);
analogix_dp_bridge_disable(dp->bridge);
+
+ if (dp->plat_data->panel) {
+ if (drm_panel_unprepare(dp->plat_data->panel))
+ DRM_ERROR("failed to turnoff the panel\n");
+ }
+
pm_runtime_disable(dev);
}
EXPORT_SYMBOL_GPL(analogix_dp_unbind);
--
1.9.1
[PATCH v14 12/17] drm: bridge: analogix/dp: add max link rate and lane count limit for RK3288
There are some IP limit on rk3288 that only support 4 physical lanes
of 2.7/1.6 Gbps/lane, so seprate them out by device_type flag.
Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10:
- Remove the surplus "plat_data" check. (Heiko)
- switch (dp->plat_data && dp->plat_data->dev_type) {
+ switch (dp->plat_data->dev_type) {
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Seprate the link-rate and lane-count limit out with the device_type
flag. (Thierry)
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 33 ++
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 4 +--
2 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 26359f4..a62e8d0 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -893,8 +893,8 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
return;
}
- ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
-dp->video_info.link_rate);
+ ret = analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
+dp->video_info.max_link_rate);
if (ret) {
dev_err(dp->dev, "unable to do link train\n");
return;
@@ -1203,16 +1203,25 @@ static int analogix_dp_dt_parse_pdata(struct
analogix_dp_device *dp)
struct device_node *dp_node = dp->dev->of_node;
struct video_info *video_info = &dp->video_info;
- if (of_property_read_u32(dp_node, "samsung,link-rate",
-&video_info->link_rate)) {
- dev_err(dp->dev, "failed to get link-rate\n");
- return -EINVAL;
- }
-
- if (of_property_read_u32(dp_node, "samsung,lane-count",
-&video_info->lane_count)) {
- dev_err(dp->dev, "failed to get lane-count\n");
- return -EINVAL;
+ switch (dp->plat_data->dev_type) {
+ case RK3288_DP:
+ /*
+* Like Rk3288 DisplayPort TRM indicate that "Main link
+* containing 4 physical lanes of 2.7/1.62 Gbps/lane".
+*/
+ video_info->max_link_rate = 0x0A;
+ video_info->max_lane_count = 0x04;
+ break;
+ case EXYNOS_DP:
+ /*
+* NOTE: those property parseing code is used for
+* providing backward compatibility for samsung platform.
+*/
+ of_property_read_u32(dp_node, "samsung,link-rate",
+&video_info->max_link_rate);
+ of_property_read_u32(dp_node, "samsung,lane-count",
+&video_info->max_lane_count);
+ break;
}
return 0;
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 123030f..02c0ecf 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -123,8 +123,8 @@ struct video_info {
enum color_coefficient ycbcr_coeff;
enum color_depth color_depth;
- int link_rate;
- enum link_lane_count_type lane_count;
+ int max_link_rate;
+ enum link_lane_count_type max_lane_count;
};
struct link_train {
--
1.9.1
[PATCH v14 17/17] drm: bridge: analogix/dp: Fix the possible dead lock in bridge disable time
It may caused a dead lock if we flush the hpd work in bridge disable time.
The normal flow would like:
IN --> DRM IOCTL
1. Acquire crtc_ww_class_mutex (DRM IOCTL)
IN --> analogix_dp_bridge
2. Acquire hpd work lock (Flush hpd work)
3. HPD work already in idle, no need to run the work function.
OUT <-- analogix_dp_bridge
OUT <-- DRM IOCTL
The dead lock flow would like:
IN --> DRM IOCTL
1. Acquire crtc_ww_class_mutex (DRM IOCTL)
IN --> analogix_dp_bridge
2. Acquire hpd work lock (Flush hpd work)
IN --> analogix_dp_hotplug
IN --> drm_helper_hpd_irq_event
3. Acquire mode_config lock (This lock already have been acquired in
previous step 1)
** Dead Lock Now **
It's wrong to flush the hpd work in bridge->disable time, I guess the
original code just want to ensure the delay work must be finish before
encoder disabled.
The flush work in bridge disable time is try to ensure the HPD event
won't be missed before display card disabled, actually we can take a
fast respond way(interrupt thread) to update DRM HPD event to fix the
delay update and possible dead lock.
Signed-off-by: Yakir Yang
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 62 ++
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 3 +-
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 26 +
3 files changed, 55 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 5292b28..7699597 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -851,47 +851,40 @@ static void analogix_dp_enable_scramble(struct
analogix_dp_device *dp,
}
}
-static irqreturn_t analogix_dp_irq_handler(int irq, void *arg)
+static irqreturn_t analogix_dp_hardirq(int irq, void *arg)
{
struct analogix_dp_device *dp = arg;
-
+ irqreturn_t ret = IRQ_NONE;
enum dp_irq_type irq_type;
irq_type = analogix_dp_get_irq_type(dp);
- switch (irq_type) {
- case DP_IRQ_TYPE_HP_CABLE_IN:
- dev_dbg(dp->dev, "Received irq - cable in\n");
- schedule_work(&dp->hotplug_work);
- analogix_dp_clear_hotplug_interrupts(dp);
- break;
- case DP_IRQ_TYPE_HP_CABLE_OUT:
- dev_dbg(dp->dev, "Received irq - cable out\n");
- analogix_dp_clear_hotplug_interrupts(dp);
- break;
- case DP_IRQ_TYPE_HP_CHANGE:
- /*
-* We get these change notifications once in a while, but there
-* is nothing we can do with them. Just ignore it for now and
-* only handle cable changes.
-*/
- dev_dbg(dp->dev, "Received irq - hotplug change; ignoring.\n");
- analogix_dp_clear_hotplug_interrupts(dp);
- break;
- default:
- dev_err(dp->dev, "Received irq - unknown type!\n");
- break;
+ if (irq_type != DP_IRQ_TYPE_UNKNOWN) {
+ analogix_dp_mute_hpd_interrupt(dp);
+ ret = IRQ_WAKE_THREAD;
}
- return IRQ_HANDLED;
+
+ return ret;
}
-static void analogix_dp_hotplug(struct work_struct *work)
+static irqreturn_t analogix_dp_irq_thread(int irq, void *arg)
{
- struct analogix_dp_device *dp;
+ struct analogix_dp_device *dp = arg;
+ enum dp_irq_type irq_type;
+
+ irq_type = analogix_dp_get_irq_type(dp);
+ if (irq_type & DP_IRQ_TYPE_HP_CABLE_IN ||
+ irq_type & DP_IRQ_TYPE_HP_CABLE_OUT) {
+ dev_dbg(dp->dev, "Detected cable status changed!\n");
+ if (dp->drm_dev)
+ drm_helper_hpd_irq_event(dp->drm_dev);
+ }
- dp = container_of(work, struct analogix_dp_device, hotplug_work);
+ if (irq_type != DP_IRQ_TYPE_UNKNOWN) {
+ analogix_dp_clear_hotplug_interrupts(dp);
+ analogix_dp_unmute_hpd_interrupt(dp);
+ }
- if (dp->drm_dev)
- drm_helper_hpd_irq_event(dp->drm_dev);
+ return IRQ_HANDLED;
}
static void analogix_dp_commit(struct analogix_dp_device *dp)
@@ -1077,7 +1070,6 @@ static void analogix_dp_bridge_disable(struct drm_bridge
*bridge)
}
disable_irq(dp->irq);
- flush_work(&dp->hotplug_work);
phy_power_off(dp->phy);
if (dp->plat_data->power_off)
@@ -1336,8 +1328,6 @@ int analogix_dp_bind(struct device *dev, struct
drm_device *drm_dev,
return -ENODEV;
}
- INIT_WORK(&dp->hotplug_work, analogix_dp_hotplug);
-
p
Re: [PATCH RFC] Introduce atomic and per-cpu add-max and sub-min operations
On Mon, Feb 15, 2016 at 1:50 PM, Will Deacon wrote: > Adding Peter and Paul, > > On Sun, Feb 14, 2016 at 12:09:00PM +0300, Konstantin Khlebnikov wrote: >> bool atomic_add_max(atomic_t *var, int add, int max); >> bool atomic_sub_min(atomic_t *var, int sub, int min); > > What are the memory-ordering requirements for these? Do you also want > relaxed/acquire/release versions for the use-cases you outline? > > One observation is that you provide no ordering guarantees if the > comparison fails, which is fine if that's what you want, but we should > probably write that down like we do for cmpxchg. Ok. Good point. > >> bool this_cpu_add_max(var, add, max); >> bool this_cpu_sub_min(var, sub, min); >> >> They add/subtract only if result will be not bigger than max/lower that min. >> Returns true if operation was done and false otherwise. >> >> Inside they check that (add <= max - var) and (sub <= var - min). Signed >> operations work if all possible values fits into range which length fits >> into non-negative range of that type: 0..INT_MAX, INT_MIN+1..0, -1000..1000. >> Unsigned operations work if value always in valid range: min <= var <= max. >> Char and short automatically casts to int, they never overflows. >> >> Patch adds the same for atomic_long_t, atomic64_t, local_t, local64_t. >> And unsigned variants: atomic_u32_add_max atomic_u32_sub_min for atomic_t, >> atomic_u64_add_max atomic_u64_sub_min for atomic64_t. >> >> Patch comes with test which hopefully covers all possible cornercases, >> see CONFIG_ATOMIC64_SELFTEST and CONFIG_PERCPU_TEST. >> >> All this allows to build any kind of counter in several lines: > > Do you have another patch converting people over to these new atomics? Thanks for comments. Sure, I'll try to use this as wide as possible. For now this solution is still incomlete. For example there is no simple way for handing cpu-hotplug: per-cpu batches must be updated when cpu disappears. Ideally cpu hotplug handlers should be registered in the same way as init/exit functions and placed into separate code segment. Memory hotplug could be handled in the same way too because resource limit or batching often depents on memory size.
[PATCH v14 13/17] drm: bridge: analogix/dp: try force hpd after plug in lookup failed
Some edp screen do not have hpd signal, so we can't just return
failed when hpd plug in detect failed.
This is an hardware property, so we need add a devicetree property
"analogix,need-force-hpd" to indicate this sutiation.
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
Tested-by: Javier Martinez Canillas
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11:
- Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
- Add the ack from Rob Herring
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- Add "analogix,need-force-hpd" to indicate whether driver need foce
hpd when hpd detect failed.
Changes in v2: None
.../bindings/display/bridge/analogix_dp.txt| 4 ++-
.../bindings/display/exynos/exynos_dp.txt | 1 +
.../display/rockchip/analogix_dp-rockchip.txt | 1 +
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 35 ++
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 ++
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 9 ++
6 files changed, 46 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
index 7659a7a..4f2ba8c 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
@@ -22,6 +22,9 @@ Required properties for dp-controller:
from general PHY binding: Should be "dp".
Optional properties for dp-controller:
+ -force-hpd:
+ Indicate driver need force hpd when hpd detect failed, this
+ is used for some eDP screen which don't have hpd signal.
-hpd-gpios:
Hotplug detect GPIO.
Indicates which GPIO should be used for hotplug detection
@@ -31,7 +34,6 @@ Optional properties for dp-controller:
* Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
*
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
-
[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
---
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
index 4fa8aca..ade5d8e 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
@@ -56,6 +56,7 @@ For the below properties, please refer to Analogix DP binding
document:
-phys (required)
-phy-names (required)
-hpd-gpios (optional)
+force-hpd (optional)
Deprecated properties for DisplayPort:
-interlaced:deprecated prop that can parsed from drm_display_mode.
diff --git
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
index 04d99e3..e832ff9 100644
---
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
+++
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -32,6 +32,7 @@ For the below properties, please refer to Analogix DP binding
document:
- phys (required)
- phy-names (required)
- hpd-gpios (optional)
+- force-hpd (optional)
---
Example:
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index a62e8d0..13986b7 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -62,15 +62,38 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device
*dp)
{
int timeout_loop = 0;
- while (analogix_dp_get_plug_in_status(dp) != 0) {
+ while (timeout_loop < DP_TIMEOUT_LOOP_COUNT) {
+ if (analogix_dp_get_plug_in_status(dp) == 0)
+ return 0;
+
timeout_loop++;
- if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
- dev_err(dp->dev, "failed to get hpd plug status\n");
- return -ETIMEDOUT;
- }
usleep_range(10, 11);
}
+ /*
+* Some edp screen do not have hpd signal, so we can't just
+* return failed when hpd plug in detect failed, DT property
+* "force-hpd" would indicate whether driver need this.
+*/
+ if (!dp->force_hpd)
+ return -ETIMEDOUT;
+
+ /*
+* The eDP TRM indicate that if HPD_STATUS(RO) is 0, AUX CH
+* will not work, so we need to give a force hpd action to
+* set HPD_STATUS manually.
+*/
+
Re: [PATCH] lib/ucs2_string: Correct ucs2 -> utf8 conversion
(Cc'ing Laszlo and linux-efi)
On Fri, 12 Feb, at 11:13:33PM, Jason Andryuk wrote:
> The comparisons should be >= since 0x800 and 0x80 require an additional bit
> to store.
>
> For the 3 byte case, the existing shift would drop off 2 more bits than
> intended.
>
> For the 2 byte case, there should be 5 bits bits in byte 1, and 6 bits in
> byte 2.
>
> Signed-off-by: Jason Andryuk
> ---
>
> Tested in user space, but not in the kernel. Conversions now match
> python's unicode conversions.
>
> lib/ucs2_string.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
Thanks Jason. Peter, Laszlo, any comments?
> diff --git a/lib/ucs2_string.c b/lib/ucs2_string.c
> index 17dd74e..f0b323a 100644
> --- a/lib/ucs2_string.c
> +++ b/lib/ucs2_string.c
> @@ -59,9 +59,9 @@ ucs2_utf8size(const ucs2_char_t *src)
> for (i = 0; i < ucs2_strlen(src); i++) {
> u16 c = src[i];
>
> - if (c > 0x800)
> + if (c >= 0x800)
> j += 3;
> - else if (c > 0x80)
> + else if (c >= 0x80)
> j += 2;
> else
> j += 1;
> @@ -88,19 +88,19 @@ ucs2_as_utf8(u8 *dest, const ucs2_char_t *src, unsigned
> long maxlength)
> for (i = 0; maxlength && i < limit; i++) {
> u16 c = src[i];
>
> - if (c > 0x800) {
> + if (c >= 0x800) {
> if (maxlength < 3)
> break;
> maxlength -= 3;
> dest[j++] = 0xe0 | (c & 0xf000) >> 12;
> - dest[j++] = 0x80 | (c & 0x0fc0) >> 8;
> + dest[j++] = 0x80 | (c & 0x0fc0) >> 6;
> dest[j++] = 0x80 | (c & 0x003f);
> - } else if (c > 0x80) {
> + } else if (c >= 0x80) {
> if (maxlength < 2)
> break;
> maxlength -= 2;
> - dest[j++] = 0xc0 | (c & 0xfe0) >> 5;
> - dest[j++] = 0x80 | (c & 0x01f);
> + dest[j++] = 0xc0 | (c & 0x7c0) >> 6;
> + dest[j++] = 0x80 | (c & 0x03f);
> } else {
> maxlength -= 1;
> dest[j++] = c & 0x7f;
> --
> 2.4.3
>
[PATCH v14 04/17] drm: bridge: analogix/dp: fix some obvious code style
Fix some obvious alignment problems, like alignment and line
over 80 characters problems, make this easy to be maintained
later.
Signed-off-by: Yakir Yang
Acked-by: Jingoo Han
Reviewed-by: Krzysztof Kozlowski
Tested-by: Javier Martinez Canillas
---
Changes in v14: None
Changes in v13: None
Changes in v12:
- Add the ack from Jingoo
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- Resequence this patch after analogix_dp driver have been split
from exynos_dp code, and rephrase reasonable commit message, and
remove some controversial style (Krzysztof)
- analogix_dp_write_byte_to_dpcd(
- dp, DP_TEST_RESPONSE,
+ analogix_dp_write_byte_to_dpcd(dp,
+ DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);
Changes in v4: None
Changes in v3: None
Changes in v2:
- Improved commit message more readable, and avoid using some
uncommon style like bellow: (Joe Preches)
- retval = exynos_dp_read_bytes_from_i2c(...
...);
+ retval =
+ exynos_dp_read_bytes_from_i2c(..);
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 129 ++---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 72 ++--
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 124 ++--
drivers/gpu/drm/exynos/exynos_dp.c | 6 +-
4 files changed, 166 insertions(+), 165 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 392c296..6901a6f 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -64,7 +64,7 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device
*dp)
while (analogix_dp_get_plug_in_status(dp) != 0) {
timeout_loop++;
- if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
+ if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
dev_err(dp->dev, "failed to get hpd plug status\n");
return -ETIMEDOUT;
}
@@ -101,8 +101,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device
*dp)
/* Read Extension Flag, Number of 128-byte EDID extension blocks */
retval = analogix_dp_read_byte_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
- EDID_EXTENSION_FLAG,
- &extend_block);
+ EDID_EXTENSION_FLAG,
+ &extend_block);
if (retval)
return retval;
@@ -110,7 +110,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device
*dp)
dev_dbg(dp->dev, "EDID data includes a single extension!\n");
/* Read EDID data */
- retval = analogix_dp_read_bytes_from_i2c(dp,
I2C_EDID_DEVICE_ADDR,
+ retval = analogix_dp_read_bytes_from_i2c(dp,
+ I2C_EDID_DEVICE_ADDR,
EDID_HEADER_PATTERN,
EDID_BLOCK_LENGTH,
&edid[EDID_HEADER_PATTERN]);
@@ -141,7 +142,7 @@ static int analogix_dp_read_edid(struct analogix_dp_device
*dp)
}
analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
- &test_vector);
+ &test_vector);
if (test_vector & DP_TEST_LINK_EDID_READ) {
analogix_dp_write_byte_to_dpcd(dp,
DP_TEST_EDID_CHECKSUM,
@@ -155,10 +156,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device
*dp)
/* Read EDID data */
retval = analogix_dp_read_bytes_from_i2c(dp,
- I2C_EDID_DEVICE_ADDR,
- EDID_HEADER_PATTERN,
- EDID_BLOCK_LENGTH,
- &edid[EDID_HEADER_PATTERN]);
+ I2C_EDID_DEVICE_ADDR, EDID_HEADER_PATTERN,
+ EDID_BLOCK_LENGTH, &edid[EDID_HEADER_PATTERN]);
if (retval != 0) {
dev_err(dp->dev, "EDID Read failed!\n");
return -EIO;
@@ -169,16 +168,13 @@ static int analogix_dp_read_edid(struct
analogix_dp_device *dp)
return -EIO;
}
- analogix_dp_read_byte_from_dpcd(dp,
- DP_TEST_REQUEST,
- &test_vector);
+ analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
+ &test_vector)
[PATCH v14 02/17] drm/exynos: dp: rename implementation specific driver part
From: Heiko Stuebner
The core functionality now resides in the generic bridge part so the
exynos-specific implementation details can get a more suitable nameing.
Signed-off-by: Heiko Stuebner
Signed-off-by: Yakir Yang
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/exynos/Makefile | 2 +-
drivers/gpu/drm/exynos/{exynos_dp_core.c => exynos_dp.c} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename drivers/gpu/drm/exynos/{exynos_dp_core.c => exynos_dp.c} (100%)
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 18244c5..533151b 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -13,7 +13,7 @@ exynosdrm-$(CONFIG_DRM_EXYNOS5433_DECON) +=
exynos5433_drm_decon.o
exynosdrm-$(CONFIG_DRM_EXYNOS7_DECON) += exynos7_drm_decon.o
exynosdrm-$(CONFIG_DRM_EXYNOS_DPI) += exynos_drm_dpi.o
exynosdrm-$(CONFIG_DRM_EXYNOS_DSI) += exynos_drm_dsi.o
-exynosdrm-$(CONFIG_DRM_EXYNOS_DP) += exynos_dp_core.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_DP) += exynos_dp.o
exynosdrm-$(CONFIG_DRM_EXYNOS_MIXER) += exynos_mixer.o
exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o
exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)+= exynos_drm_vidi.o
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp.c
similarity index 100%
rename from drivers/gpu/drm/exynos/exynos_dp_core.c
rename to drivers/gpu/drm/exynos/exynos_dp.c
--
1.9.1
Re: [PATCH v7 3/3] add support for DWC UFS Host Controller
Hi Akinobu,
On 2/13/2016 1:27 PM, Akinobu Mita wrote:
> Hi Joao,
>
> 2016-02-11 21:13 GMT+09:00 Joao Pinto :
>> +static int ufshcd_dwc_connection_setup(struct ufs_hba *hba)
>> +{
>> + int ret = 0;
>> +
>> + /* Local side Configuration */
>> + ret = ufshcd_dme_set(hba, UIC_ARG_MIB(T_CONNECTIONSTATE), 0);
>> + if (ret)
>> + goto out;
>> +
>> + ret = ufshcd_dme_set(hba, UIC_ARG_MIB(N_DEVICEID), 0);
>> + if (ret)
>> + goto out;
>> +
>> + ret = ufshcd_dme_set(hba, UIC_ARG_MIB(N_DEVICEID_VALID), 0);
>> + if (ret)
>> + goto out;
>> +
>> + ret = ufshcd_dme_set(hba, UIC_ARG_MIB(T_PEERDEVICEID), 1);
>> + if (ret)
>> + goto out;
>> +
>> + ret = ufshcd_dme_set(hba, UIC_ARG_MIB(T_PEERCPORTID), 0);
>> + if (ret)
>> + goto out;
>> +
>> + ret = ufshcd_dme_set(hba, UIC_ARG_MIB(T_TRAFFICCLASS), 0);
>> + if (ret)
>> + goto out;
>> +
>> + ret = ufshcd_dme_set(hba, UIC_ARG_MIB(T_CPORTFLAGS), 0x6);
>> + if (ret)
>> + goto out;
>> +
>> + ret = ufshcd_dme_set(hba, UIC_ARG_MIB(T_CPORTMODE), 1);
>> + if (ret)
>> + goto out;
>> +
>> + ret = ufshcd_dme_set(hba, UIC_ARG_MIB(T_CONNECTIONSTATE), 1);
>> + if (ret)
>> + goto out;
>> +
>> +
>> + /* Peer side Configuration */
>> + ret = ufshcd_dme_peer_set(hba, UIC_ARG_MIB(T_CONNECTIONSTATE), 0);
>> + if (ret)
>> + goto out;
>> +
>> + ret = ufshcd_dme_peer_set(hba, UIC_ARG_MIB(N_DEVICEID), 1);
>> + if (ret)
>> + goto out;
>> +
>> + ret = ufshcd_dme_peer_set(hba, UIC_ARG_MIB(N_DEVICEID_VALID), 1);
>> + if (ret)
>> + goto out;
>> +
>> + ret = ufshcd_dme_peer_set(hba, UIC_ARG_MIB(T_PEERDEVICEID), 1);
>> + if (ret)
>> + goto out;
>> +
>> + ret = ufshcd_dme_peer_set(hba, UIC_ARG_MIB(T_PEERCPORTID), 0);
>> + if (ret)
>> + goto out;
>> +
>> + ret = ufshcd_dme_peer_set(hba, UIC_ARG_MIB(T_TRAFFICCLASS), 0);
>> + if (ret)
>> + goto out;
>> +
>> + ret = ufshcd_dme_peer_set(hba, UIC_ARG_MIB(T_CPORTFLAGS), 0x6);
>> + if (ret)
>> + goto out;
>> +
>> + ret = ufshcd_dme_peer_set(hba, UIC_ARG_MIB(T_CPORTMODE), 1);
>> + if (ret)
>> + goto out;
>> +
>> + ret = ufshcd_dme_peer_set(hba, UIC_ARG_MIB(T_CONNECTIONSTATE), 1);
>> + if (ret)
>> + goto out;
>> +
>> +out:
>> + return ret;
>> +}
>
> This looks a bit redundant. The most part of the functions in this file is
> doing ufshcd_dme_set() or ufshcd_dme_peer_set(), so should we
> introduce ufshcd_dme_set_attrs() like below? It will also increase
> readability.
We can do that, it would make the function body lighter and more easy to read I
agree with you!
>
> struct ufshcd_dme_attr_val {
> u32 attr_sel;
> u32 mib_val;
> u8 peer;
> };
>
> int ufshcd_dme_set_attrs(struct ufs_hba *hba,
> const struct ufshcd_dme_attr_val *v, int n)
> {
> for (i = 0; i < n; i++) {
> int ret = ufshcd_dme_set_attr(hba, v[i].attr_sel, ...);
>
> if (ret)
> return ret;
> }
> return 0;
> }
>
> static int ufshcd_dwc_connection_setup(struct ufs_hba *hba)
> {
> const struct ufshcd_dme_attr setup_attrs[] = {
> { UIC_ARG_MIB(T_CONNECTIONSTATE), 0, DME_LOCAL },
> { UIC_ARG_MIB(T_DEVICEID), 0, DME_LOCAL },
> ...
> };
>
> return ufshcd_dme_set_attrs(hba, setup_attrs,
> ARRAY_SIZE(setup_attrs));
> }
>
>> +static int ufshcd_dwc_setup_tc(struct ufs_hba *hba)
>> +{
>> + int ret = 0;
>> +
>> +#ifdef CONFIG_SCSI_UFS_DWC_40BIT_RMMI
>> + dev_info(hba->dev, "Configuring Test Chip 40-bit RMMI");
>> + ret = ufshcd_dwc_setup_40bit_rmmi(hba);
>> + if (ret) {
>> + dev_err(hba->dev, "Configuration failed");
>
> Please add \n in the end of message.
> (and there are same issues in this file)
>
>> +
>> +/* Clock Divider Values: Hex equivalent of frequency in MHz */
>> +enum clk_div_values {
>> + UFSHCD_CLK_DIV_62_5 = 0x3e,
>> + UFSHCD_CLK_DIV_125 = 0x7d,
>> + UFSHCD_CLK_DIV_200 = 0xc8,
>> +};
>
> This is used as register value for DWC_UFS_REG_HCLKDIV. So should they
> have similar prefix (DWC_UFS_REG_HCLKDIV_*)?
I agree with you, they should have since they are DWC specific.
>
>> diff --git a/drivers/scsi/ufs/unipro.h b/drivers/scsi/ufs/unipro.h
>
> ...
>
>> +/*Other attributes*/
>> +#define VS_MPHYCFGUPDT 0xD085
>> +#define VS_DEBUGOMC0xD09E
>> +#define VS_POWERSTATE 0xD083
>
> Are these vendor specific attributes? If so, please move them to
> ufshci-dwc.h.
These are not DWC specific, that's why I added them to th
Re: [PATCH 1/1] MIPS: DTS: cavium-octeon: provide model attribute
Hello.
On 2/15/2016 8:26 AM, Heinrich Schuchardt wrote:
Downstream packages like Debian flash-kernel rely on
/proc/device-tree/model
to determine how to install an updated kernel image.
Most dts files provide this property.
It is suggested by IEEE Std 1275-1994.
This patch adds a model attribute for Octeon CPUs.
Signed-off-by: Heinrich Schuchardt
---
arch/mips/boot/dts/cavium-octeon/octeon_3xxx.dts | 1 +
arch/mips/boot/dts/cavium-octeon/octeon_68xx.dts | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/mips/boot/dts/cavium-octeon/octeon_3xxx.dts
b/arch/mips/boot/dts/cavium-octeon/octeon_3xxx.dts
index 9c48e05..a746678 100644
--- a/arch/mips/boot/dts/cavium-octeon/octeon_3xxx.dts
+++ b/arch/mips/boot/dts/cavium-octeon/octeon_3xxx.dts
@@ -8,6 +8,7 @@
*/
/ {
compatible = "cavium,octeon-3860";
+ model = "Cavium Octeon 3XXX";
#address-cells = <2>;
#size-cells = <2>;
interrupt-parent = <&ciu>;
diff --git a/arch/mips/boot/dts/cavium-octeon/octeon_68xx.dts
b/arch/mips/boot/dts/cavium-octeon/octeon_68xx.dts
index 79b46fc..c8a292a 100644
--- a/arch/mips/boot/dts/cavium-octeon/octeon_68xx.dts
+++ b/arch/mips/boot/dts/cavium-octeon/octeon_68xx.dts
@@ -8,6 +8,7 @@
*/
/ {
compatible = "cavium,octeon-6880";
+ model = "Cavium Octeon 68XX";
#address-cells = <2>;
#size-cells = <2>;
interrupt-parent = <&ciu2>;
The ePAPR 1.1 standard says:
2.3.2 model
Property: model
Value type:
Description:
The model property value is a that specifies the
manufacturer’s model number of the device.
The recommended format is: “manufacturer,model”, where manufacturer
is a string describing the name of the manufacturer (such as a stock
ticker symbol), and model specifies the model number.
Example:
model = “fsl,MPC8349EMITX”;
MBR, Sergei
Re: [PATCH 1/1] MIPS: DTS: cavium-octeon: provide model attribute
On Monday 15 February 2016 14:16:48 Sergei Shtylyov wrote: > > Property: model > Value type: > Description: > The model property value is a that specifies the > manufacturer’s model number of the device. > > The recommended format is: “manufacturer,model”, where manufacturer > is a string describing the name of the manufacturer (such as a stock > ticker symbol), and model specifies the model number. > > This also means that you absolutely cannot have wildcards in there (same rule as for the compatible strings) and that the property should be in the .dts file, not .dtsi. Arnd
Re: [PATCH v4 2/8] [media] VPU: mediatek: support Mediatek VPU
Hi Hans,
On Mon, 2016-02-15 at 11:07 +0100, Hans Verkuil wrote:
> Hi Tiffany,
>
> A small review comment below:
>
> On 02/04/2016 12:34 PM, Tiffany Lin wrote:
> > The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs.
> > It is able to handle video decoding/encoding of in a range of formats.
> > The driver provides with VPU firmware download, memory management and
> > the communication interface between CPU and VPU.
> > For VPU initialization, it will create virtual memory for CPU access and
> > IOMMU address for vcodec hw device access. When a decode/encode instance
> > opens a device node, vpu driver will download vpu firmware to the device.
> > A decode/encode instant will decode/encode a frame using VPU
> > interface to interrupt vpu to handle decoding/encoding jobs.
> >
> > Signed-off-by: Andrew-CT Chen
> > Signed-off-by: Tiffany Lin
> > ---
> > drivers/media/platform/Kconfig |9 +
> > drivers/media/platform/Makefile |2 +
> > drivers/media/platform/mtk-vpu/Makefile |1 +
> > drivers/media/platform/mtk-vpu/mtk_vpu.c | 994
> > ++
> > drivers/media/platform/mtk-vpu/mtk_vpu.h | 167 +
> > 5 files changed, 1173 insertions(+)
> > create mode 100644 drivers/media/platform/mtk-vpu/Makefile
> > create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.c
> > create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.h
> >
>
>
>
> > diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.c
> > b/drivers/media/platform/mtk-vpu/mtk_vpu.c
> > new file mode 100644
> > index 000..f54fd89
> > --- /dev/null
> > +++ b/drivers/media/platform/mtk-vpu/mtk_vpu.c
> > @@ -0,0 +1,994 @@
>
>
>
> > +static ssize_t vpu_debug_read(struct file *file, char __user *user_buf,
> > + size_t count, loff_t *ppos)
> > +{
> > + char buf[256];
> > + unsigned int len;
> > + unsigned int running, pc, vpu_to_host, host_to_vpu, wdt;
> > + int ret;
> > + struct device *dev = file->private_data;
> > + struct mtk_vpu *vpu = dev_get_drvdata(dev);
> > +
> > + ret = vpu_clock_enable(vpu);
> > + if (ret) {
> > + dev_err(vpu->dev, "[VPU] enable clock failed %d\n", ret);
> > + return 0;
> > + }
> > +
> > + /* vpu register status */
> > + running = vpu_running(vpu);
> > + pc = vpu_cfg_readl(vpu, VPU_PC_REG);
> > + wdt = vpu_cfg_readl(vpu, VPU_WDT_REG);
> > + host_to_vpu = vpu_cfg_readl(vpu, HOST_TO_VPU);
> > + vpu_to_host = vpu_cfg_readl(vpu, VPU_TO_HOST);
> > + vpu_clock_disable(vpu);
> > +
> > + if (running) {
> > + len = sprintf(buf, "VPU is running\n\n"
>
> Please use snprintf.
>
Got it, we will fix this in next version.
> > + "FW Version: %s\n"
> > + "PC: 0x%x\n"
> > + "WDT: 0x%x\n"
> > + "Host to VPU: 0x%x\n"
> > + "VPU to Host: 0x%x\n",
> > + vpu->run.fw_ver, pc, wdt,
> > + host_to_vpu, vpu_to_host);
> > + } else {
> > + len = sprintf(buf, "VPU not running\n");
>
> Ditto.
>
> sprintf always makes me feel uncomfortable :-)
>
Sorry about that, we will check patch series and remove all sprintf in
next version.
> > + }
> > +
> > + return simple_read_from_buffer(user_buf, count, ppos, buf, len);
> > +}
>
> Regards,
>
> Hans
>
Re: [PATCH v4 5/8] [Media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver
On 02/04/2016 12:35 PM, Tiffany Lin wrote: > From: Andrew-CT Chen > > Add v4l2 layer encoder driver for MT8173 > > Signed-off-by: Tiffany Lin If Andrew is the author, shouldn't there be a Signed-off-by from him as well? And in copyright notices (might want to update the year to 2016 BTW) PC Chen is mentioned among others. It might be useful to update the Signed-off-by lines. > --- > drivers/media/platform/Kconfig | 11 + > drivers/media/platform/Makefile|2 + > drivers/media/platform/mtk-vcodec/Makefile |8 + > drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h | 388 ++ > drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 1380 > > drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h | 46 + > .../media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 476 +++ > .../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 132 ++ > .../media/platform/mtk-vcodec/mtk_vcodec_intr.c| 102 ++ > .../media/platform/mtk-vcodec/mtk_vcodec_intr.h| 29 + > drivers/media/platform/mtk-vcodec/mtk_vcodec_pm.h | 26 + > .../media/platform/mtk-vcodec/mtk_vcodec_util.c| 106 ++ > .../media/platform/mtk-vcodec/mtk_vcodec_util.h| 85 ++ > drivers/media/platform/mtk-vcodec/venc_drv_base.h | 62 + > drivers/media/platform/mtk-vcodec/venc_drv_if.c| 100 ++ > drivers/media/platform/mtk-vcodec/venc_drv_if.h| 175 +++ > drivers/media/platform/mtk-vcodec/venc_ipi_msg.h | 212 +++ > include/uapi/linux/v4l2-controls.h |4 + > 18 files changed, 3344 insertions(+) > create mode 100644 drivers/media/platform/mtk-vcodec/Makefile > create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h > create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c > create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h > create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c > create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c > create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c > create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.h > create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_pm.h > create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c > create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h > create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_base.h > create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.c > create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.h > create mode 100644 drivers/media/platform/mtk-vcodec/venc_ipi_msg.h > mode change 100644 => 100755 include/uapi/linux/v4l2-controls.h > > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig > index ba812d6..3e831c5 100644 > --- a/drivers/media/platform/Kconfig > +++ b/drivers/media/platform/Kconfig > @@ -157,6 +157,17 @@ config VIDEO_MEDIATEK_VPU > codec embedded in new Mediatek's SOCs. It is able > to handle video decoding/encoding in a range of formats. > > +config VIDEO_MEDIATEK_VCODEC > +tristate "Mediatek Video Codec driver" > +depends on VIDEO_DEV && VIDEO_V4L2 > +depends on ARCH_MEDIATEK || COMPILE_TEST > +select VIDEOBUF2_DMA_CONTIG > +select V4L2_MEM2MEM_DEV > +select MEDIATEK_VPU > +default n > +---help--- > +Mediatek video codec driver for V4L2 > + > config VIDEO_MEM2MEM_DEINTERLACE > tristate "Deinterlace support" > depends on VIDEO_DEV && VIDEO_V4L2 && DMA_ENGINE > diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile > index e5b19c6..510e06b 100644 > --- a/drivers/media/platform/Makefile > +++ b/drivers/media/platform/Makefile > @@ -57,3 +57,5 @@ obj-$(CONFIG_VIDEO_XILINX) += xilinx/ > ccflags-y += -I$(srctree)/drivers/media/i2c > > obj-$(CONFIG_VIDEO_MEDIATEK_VPU) += mtk-vpu/ > + > +obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec/ > diff --git a/drivers/media/platform/mtk-vcodec/Makefile > b/drivers/media/platform/mtk-vcodec/Makefile > new file mode 100644 > index 000..ce38689 > --- /dev/null > +++ b/drivers/media/platform/mtk-vcodec/Makefile > @@ -0,0 +1,8 @@ > +obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk_vcodec_intr.o \ > +mtk_vcodec_util.o \ > +mtk_vcodec_enc_drv.o \ > +mtk_vcodec_enc.o \ > +mtk_vcodec_enc_pm.o \ > +venc_drv_if.o > + > +ccflags-y += -I$(srctree)/drivers/media/platform/mtk-vpu > diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h > b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h > new file mode 100644 > index 000..9da2818 > --- /dev/null > +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h > @@ -0,0 +1,388 @@
Re: [PATCH] ARM: drop redundant "PHONY += FORCE"
2016-02-07 18:59 GMT+09:00 Masahiro Yamada : > "PHONY += FORCE" is already cared by scripts/Makefile.build, > which this file is included from. > > Signed-off-by: Masahiro Yamada > --- > > arch/arm/boot/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile > index 9eca7ae..ba73a20 100644 > --- a/arch/arm/boot/Makefile > +++ b/arch/arm/boot/Makefile > @@ -88,7 +88,7 @@ $(obj)/bootpImage: $(obj)/bootp/bootp FORCE > $(call if_changed,objcopy) > @$(kecho) ' Kernel: $@ is ready' > > -PHONY += initrd FORCE > +PHONY += initrd > initrd: > @test "$(INITRD_PHYS)" != "" || \ > (echo This machine does not support INITRD; exit -1) > -- If there is no objection to this patch, I will put it into Russell's patch tracker. -- Best Regards Masahiro Yamada
Re: [media 1/7] raise adapter number limit
On Mon, Feb 15, 2016 at 7:08 AM, wrote: > From: Буди Романто, AreMa Inc > > The current limit is too low for latest cards with 8+ tuners on a single > slot, change to 64. > > Signed-off-by: Буди Романто, AreMa Inc I think that here goes only your name, not , .
[REGRESSION, bisected] 4.5rc4 sound fsl-soc
Hi,
The following commit :
5c408fee254633a5be69505bc86c6b034f871ab4 is the first bad commit
commit 5c408fee254633a5be69505bc86c6b034f871ab4
Author: Maciej S. Szmigiero
Date: Mon Jan 18 20:07:44 2016 +0100
ASoC: fsl_ssi: remove explicit register defaults
There is no guarantee that on fsl_ssi module load
SSI registers will have their power-on-reset values.
In fact, if the driver is reloaded the values in
registers will be whatever they were set to previously.
However, the cache needs to be fully populated at probe
time to avoid non-atomic allocations during register
access.
Special case here is imx21-class SSI, since
according to datasheet it don't have SACC{ST,EN,DIS}
regs.
This fixes hard lockup on fsl_ssi module reload,
at least in AC'97 mode.
Fixes: 05cf237972fe ("ASoC: fsl_ssi: Add driver suspend and resume to
support MEGA Fast")
Signed-off-by: Maciej S. Szmigiero
Tested-by: Fabio Estevam
Signed-off-by: Mark Brown
causes regmap init failure when loading the sgtl5000 codec on imx6q, and
leads to no audio.
With the mentioned patch reverted sound works ok.
--Mika
Re: [PATCH] ARM: remove 'i' and 'zi' targets
2016-02-07 18:56 GMT+09:00 Masahiro Yamada :
> These two were introduced by commit 13d5fadf45d1 ("[ARM] Make 'i' and
> 'zi' targets work") to short-circuit the dependencies for 'install'
> and 'zinstall'.
>
> After that, commit 19514fc665ff ('arm, kbuild: make "make install"
> not depend on vmlinux') eventually made "make (z)install" equivalent
> to "make (z)i".
>
> It is true that 'i' and 'zi' might be still useful as shorthands
> but the original intention had been already lost.
>
> They do not even show up in "make ARCH=arm help", so I hope this
> deletion does not have much impact.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> arch/arm/Makefile | 1 -
> arch/arm/boot/Makefile | 8
> 2 files changed, 9 deletions(-)
>
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index cd21135..1e83a45 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -353,7 +353,6 @@ archclean:
>
> # My testing targets (bypasses dependencies)
> bp:; $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/bootpImage
> -i zi:; $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $@
>
>
> define archhelp
> diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
> index ba73a20..48fab15 100644
> --- a/arch/arm/boot/Makefile
> +++ b/arch/arm/boot/Makefile
> @@ -107,12 +107,4 @@ uinstall:
> $(CONFIG_SHELL) $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" \
> $(obj)/uImage System.map "$(INSTALL_PATH)"
>
> -zi:
> - $(CONFIG_SHELL) $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" \
> - $(obj)/zImage System.map "$(INSTALL_PATH)"
> -
> -i:
> - $(CONFIG_SHELL) $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" \
> - $(obj)/Image System.map "$(INSTALL_PATH)"
> -
> subdir-:= bootp compressed dts
> --
If there is no objection to this patch,
I will put it into Russell's patch tracker.
--
Best Regards
Masahiro Yamada
Re: [PATCH v4 2/8] [media] VPU: mediatek: support Mediatek VPU
On Mon, 2016-02-15 at 11:13 +0100, Hans Verkuil wrote: > On 02/04/2016 12:34 PM, Tiffany Lin wrote: > > The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs. > > It is able to handle video decoding/encoding of in a range of formats. > > The driver provides with VPU firmware download, memory management and > > the communication interface between CPU and VPU. > > For VPU initialization, it will create virtual memory for CPU access and > > IOMMU address for vcodec hw device access. When a decode/encode instance > > opens a device node, vpu driver will download vpu firmware to the device. > > A decode/encode instant will decode/encode a frame using VPU > > interface to interrupt vpu to handle decoding/encoding jobs. > > > > Signed-off-by: Andrew-CT Chen > > Signed-off-by: Tiffany Lin > > --- > > drivers/media/platform/Kconfig |9 + > > drivers/media/platform/Makefile |2 + > > drivers/media/platform/mtk-vpu/Makefile |1 + > > drivers/media/platform/mtk-vpu/mtk_vpu.c | 994 > > ++ > > drivers/media/platform/mtk-vpu/mtk_vpu.h | 167 + > > 5 files changed, 1173 insertions(+) > > create mode 100644 drivers/media/platform/mtk-vpu/Makefile > > create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.c > > create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.h > > > > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig > > index ccbc974..ba812d6 100644 > > --- a/drivers/media/platform/Kconfig > > +++ b/drivers/media/platform/Kconfig > > @@ -148,6 +148,15 @@ config VIDEO_CODA > >Coda is a range of video codec IPs that supports > >H.264, MPEG-4, and other video formats. > > > > +config VIDEO_MEDIATEK_VPU > > + tristate "Mediatek Video Processor Unit" > > + depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MEDIATEK > > + ---help--- > > + This driver provides downloading VPU firmware and > > + communicating with VPU. This driver for hw video > > + codec embedded in new Mediatek's SOCs. It is able > > + to handle video decoding/encoding in a range of formats. > > Can you be more specific in this text and mention for which Mediatek SoCs > this driver is for? Just like you did in the commit log. > Got it. We will add more specific description in Kconfig in next version. > Also add something like this: > > To compile this driver as a module, choose M here: the module > will be called mtk-vpu. > > I always find it useful if the Kconfig text mentions the module name. > Got it. We will fix this. Thanks for sharing experience. best regards, Tiffany > Regards, > > Hans > > > + > > config VIDEO_MEM2MEM_DEINTERLACE > > tristate "Deinterlace support" > > depends on VIDEO_DEV && VIDEO_V4L2 && DMA_ENGINE >
Re: [PATCH v4 7/8] [media] vcodec: mediatek: Add Mediatek H264 Video Encoder Driver
On 02/04/2016 12:35 PM, Tiffany Lin wrote:
> Add h264 encoder driver for MT8173
>
> Signed-off-by: Daniel Hsiao
> Signed-off-by: Tiffany Lin
> ---
> drivers/media/platform/mtk-vcodec/Makefile |3 +-
> .../media/platform/mtk-vcodec/h264_enc/Makefile|6 +
> .../platform/mtk-vcodec/h264_enc/venc_h264_if.c| 540
>
> .../platform/mtk-vcodec/h264_enc/venc_h264_if.h| 165 ++
> .../platform/mtk-vcodec/h264_enc/venc_h264_vpu.c | 309 +++
> .../platform/mtk-vcodec/h264_enc/venc_h264_vpu.h | 30 ++
> drivers/media/platform/mtk-vcodec/venc_drv_if.c|3 +
> 7 files changed, 1055 insertions(+), 1 deletion(-)
> create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/Makefile
> create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.c
> create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.h
> create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.c
> create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.h
>
> diff --git a/drivers/media/platform/mtk-vcodec/Makefile
> b/drivers/media/platform/mtk-vcodec/Makefile
> index f4ef502..f47dfc7 100644
> --- a/drivers/media/platform/mtk-vcodec/Makefile
> +++ b/drivers/media/platform/mtk-vcodec/Makefile
> @@ -5,6 +5,7 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk_vcodec_intr.o \
> mtk_vcodec_enc_pm.o \
> venc_drv_if.o
>
> -obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += vp8_enc/
> +
> +obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += vp8_enc/ h264_enc/
>
> ccflags-y += -I$(srctree)/drivers/media/platform/mtk-vpu
> diff --git a/drivers/media/platform/mtk-vcodec/h264_enc/Makefile
> b/drivers/media/platform/mtk-vcodec/h264_enc/Makefile
> new file mode 100644
> index 000..765b45f
> --- /dev/null
> +++ b/drivers/media/platform/mtk-vcodec/h264_enc/Makefile
> @@ -0,0 +1,6 @@
> +obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += venc_h264_if.o venc_h264_vpu.o
> +
> +ccflags-y += \
> +-I$(srctree)/drivers/media/platform/mtk-vcodec/ \
> +-I$(srctree)/drivers/media/platform/mtk-vcodec/h264_enc \
> +-I$(srctree)/drivers/media/platform/mtk-vpu
> diff --git a/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.c
> b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.c
> new file mode 100644
> index 000..c35fb26
> --- /dev/null
> +++ b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.c
> @@ -0,0 +1,540 @@
> +/*
> + * Copyright (c) 2015 MediaTek Inc.
> + * Author: Jungchang Tsao
> + * Daniel Hsiao
> + * PoChun Lin
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include "mtk_vcodec_drv.h"
> +#include "mtk_vcodec_util.h"
> +#include "mtk_vcodec_intr.h"
> +#include "mtk_vcodec_enc.h"
> +#include "mtk_vcodec_pm.h"
> +#include "mtk_vpu.h"
> +
> +#include "venc_h264_if.h"
> +#include "venc_h264_vpu.h"
> +
> +#define VENC_PIC_BITSTREAM_BYTE_CNT 0x0098
> +
> +enum venc_h264_irq_status {
> + H264_IRQ_STATUS_ENC_SPS_INT = (1 << 0),
> + H264_IRQ_STATUS_ENC_PPS_INT = (1 << 1),
> + H264_IRQ_STATUS_ENC_FRM_INT = (1 << 2),
> +};
> +
> +static inline void h264_write_reg(struct venc_h264_inst *inst, u32 addr,
> + u32 val)
> +{
> + writel(val, inst->hw_base + addr);
> +}
> +
> +static inline u32 h264_read_reg(struct venc_h264_inst *inst, u32 addr)
> +{
> + return readl(inst->hw_base + addr);
> +}
> +
> +static void h264_enc_free_work_buf(struct venc_h264_inst *inst)
> +{
> + int i;
> +
> + mtk_vcodec_debug_enter(inst);
> +
> + /* Except the SKIP_FRAME buffers,
> + * other buffers need to be freed by AP.
> + */
> + for (i = 0; i < VENC_H264_VPU_WORK_BUF_MAX; i++) {
> + if (i != VENC_H264_VPU_WORK_BUF_SKIP_FRAME)
> + if (inst->work_bufs[i].va != NULL)
> + mtk_vcodec_mem_free(inst->ctx,
> + &inst->work_bufs[i]);
> + }
> +
> + if (inst->pps_buf.va != NULL)
> + mtk_vcodec_mem_free(inst->ctx, &inst->pps_buf);
> +
> + mtk_vcodec_debug_leave(inst);
> +}
> +
> +static int h264_enc_alloc_work_buf(struct venc_h264_inst *inst, void *param)
> +{
> + int i;
> + int ret = 0;
> + struct venc_h264_vpu_buf *wb = inst->vpu_inst.drv->work_bufs;
> + struct venc_enc_prm *enc_param = param;
> +
> + mtk_vcodec_debug_enter(inst);
> +
> + for (i = 0; i < VENC_H264
Re: [RFC PATCH 1/7] arm64/perf: Basic uncore counter support for Cavium ThunderX
On Fri, Feb 12, 2016 at 05:47:25PM -0800, David Daney wrote:
> On 02/12/2016 09:36 AM, Mark Rutland wrote:
> >On Fri, Feb 12, 2016 at 05:55:06PM +0100, Jan Glauber wrote:
> [...]
> >>2) Counters are summarized across the different units of the same type,
> >>e.g. L2C TAD 0..7 is presented as a single counter (adding the
> >>values from TAD 0 to 7). Although losing the ability to read a
> >>single value the merged values are easier to use and yield
> >>enough information.
> >
> >I'm not sure I follow this. What is easier? What are you doing, and what
> >are you comparing that with to say that your approach is easier?
> >
> >It sounds like it should be possible to handle multiple counters like
> >this, so I don't follow why you want to amalgamate them in-kernel.
> >
>
> The values of the individual counters are close to meaningless. The
> only thing that is meaningful to someone reading the counters is the
> aggregate sum of all the counts.
I obviously know nowhere near enough about your system to say with
certainty, but it may turn out that being able to track counters
individually is useful for some profiling/debugging scenario. How
meaningful the individual counts are really depends on what you're
trying to figure out.
If you believe that aggregate values are sufficient, then I'm happy to
leave that as-is.
> >>+void thunder_uncore_read(struct perf_event *event)
> >>+{
> >>+ struct thunder_uncore *uncore = event_to_thunder_uncore(event);
> >>+ struct hw_perf_event *hwc = &event->hw;
> >>+ u64 prev, new = 0;
> >>+ s64 delta;
> >>+ int i;
> >>+
> >>+ /*
> >>+* since we do not enable counter overflow interrupts,
> >>+* we do not have to worry about prev_count changing on us
> >>+*/
> >
> >Without overflow interrupts, how do you ensure that you account for
> >overflow in a reasonable time window (i.e. before the counter runs past
> >its initial value)?
>
> Two reasons:
>
> 1) There are no interrupts.
>
> 2) The counters are 64-bit, they never overflow.
Ok. Please point this out in the comment so that reviewers aren't
misled. Stating that we don't enable an interrupt implies that said
interrupt exists.
> >>+ /* and we do not enable counter overflow interrupts */
> >
> >That statement raises far more questions than it answers.
> >
> >_why_ do we not user overflow interrupts?
>
> As stated above, there are *no* overflow interrupts.
Ok. As stated above, please fix this comment to not mislead.
> The events we are counting cannot be attributed to any one (or even
> any) CPU, they run asynchronous to the CPU, so even if there were
> interrupts, they would be meaningless.
Yes, they are meaningless w.r.t. the state of an arbitrary CPU.
Were they to exist you could use them to drive other snapshotting of the
state of the uncore PMU, to get an idea of the frequency/stability of
events over time, etc. Userspace might then decide to snapshot other
whole system state based on events fed to it.
That's moot if they don't exist.
Mark.
Re: richacl(7) man page review comments
On Mon, Feb 15, 2016 at 11:25 AM, Michael Kerrisk (man-pages) wrote: > You're right. I was confusing with xattr(7). So, I think it might > make some sense to eventually move both of these into man-pages (for > richacl(7), at least, it's probably worth delaying this for a bit), > since they're describing kernel-user-space interfaces. Well, the actual user-space interface is xattrs in both cases. > I can see counter-arguments too, such as these pages are closely > related to the corresponding user-space libraries you maintain. > What do you think? I would keep the man-pages where they are right now, but I don't have a strong preference. Andreas
Re: Re: [PATCH RESEND] arm64: add alignment fault hanling
> How do you end up with Device nGnRnE in user space? I thought we should > have got some guard page. I guess it is a device file that is mmaped in the user space and later remapped in the kernel using pgprot_noncached(). I can't find the code that inserts a guard page in between vma's can you please help me find that code? > do_strncpy_from_user() relies on unsafe_get_user() not being able to > read 8 bytes. The problem now is that it doesn't get a page fault but an > alignment one is isn't handled. Yes. > Why addr >= TASK_SIZE? addr here should be the fault address, not pc. You're right. I should have used user_mode(regs). > The simplest would be to use do_bad_area() here without any additional > function. Yes, I should've probably used do_bad_area(). I just wanted to do the minimal stuff.
