Re: [PATCH v2 06/10] usb: xhci: Enable runtime pm in xhci-plat
Hi, On Sat, Mar 2, 2013 at 9:23 PM, Alan Stern st...@rowland.harvard.edu wrote: On Sat, 2 Mar 2013, Vivek Gautam wrote: By enabling runtime pm in this driver allows users of xhci-plat to enter into runtime pm. This is not full runtime pm support (AKA xhci-plat doesn't actually power anything off when in runtime suspend mode) but, just basic enablement. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com CC: Doug Anderson diand...@chromium.org --- drivers/usb/host/xhci-plat.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c index c9c7e13..595cb52 100644 --- a/drivers/usb/host/xhci-plat.c +++ b/drivers/usb/host/xhci-plat.c @@ -12,6 +12,7 @@ */ #include linux/platform_device.h +#include linux/pm_runtime.h #include linux/module.h #include linux/slab.h @@ -149,6 +150,8 @@ static int xhci_plat_probe(struct platform_device *pdev) if (ret) goto put_usb3_hcd; + pm_runtime_enable(pdev-dev); This is generally not a good idea. You shouldn't enable a device for runtime PM without first telling the PM core what state it is in. Right, but i am not completely sure on any fixed path to follow for enabling runtime power management on a device. :-( Does it become necessary to pm_runtime_set_active or pm_runtime_set_suspended a device before pm_runtime_enable ? pm_runtime_enable would just try to decrement the disable_depth of the device. @@ -174,6 +177,10 @@ static int xhci_plat_remove(struct platform_device *dev) struct usb_hcd *hcd = platform_get_drvdata(dev); struct xhci_hcd *xhci = hcd_to_xhci(hcd); + if (!pm_runtime_suspended(dev-dev)) + pm_runtime_put(dev-dev); + pm_runtime_disable(dev-dev); + usb_remove_hcd(xhci-shared_hcd); usb_put_hcd(xhci-shared_hcd); This is very strange. Why have a pm_runtime_put with no balancing pm_runtime_get? And why use an async routine when you're about to unbind the driver? Don't you want the callback to occur before the unbinding? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Thanks Regards Vivek -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: MFC decode failed in S5PV210 in kernel 3.8
Hi, From: Lonsn [mailto:lonsn2...@gmail.com] Sent: Sunday, March 03, 2013 4:10 AM Which firmware should be used for S5PV210 for kernel 3.8? Here: https://git.kernel.org/cgit/linux/kernel/git/firmware/linux- firmware.git/commit/?id=fb5cda9c70277f633ca0c1e81b6fa7b13007bbf6 It only says for Exynos4 series : for s5p-mfc.fw- For v5 firmware used in Exynos4 series Does the firmware have any relation with compiler armhf or armef? There is no relation. s5p-mfc.fw is good for Exynos4 you are using (S5PV210). Thanks. -- Kamil Debski Linux Platform Group Samsung Poland RD Center [snip] -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: MFC decode failed in S5PV210 in kernel 3.8
Hi Lonsn, From: Lonsn [mailto:lonsn2...@gmail.com] Sent: Saturday, March 02, 2013 5:00 AM Hi, I tested the MFC decode example v4l2_decode from http://git.infradead.org/users/kmpark/public-apps and meet some problems as following: # ./v4l2_decode -f /dev/video5 -m /dev/video9 -d /dev/fb0 -c mpeg4 -i shrek.m4v V4L2 Codec decoding example application Kamil Debski k.deb...@samsung.com Copyright 2012 Samsung Electronics Co., Ltd. (fb.c:fb_open:51): Framebuffer properties: xres=1024, yres=768, bpp=32 (fb.c:fb_open:53): Virtual resolution: vxres=1024 vyres=768 (fimc.c:fimc_open:56): FIMC Info (/dev/video5): driver=s5pv210-fimc bus_info= card=s5pv210-fimc fd=0x5 (mfc.c:mfc_open:57): MFC Info (/dev/video9): driver=s5p-mfc bus_info= card=s5p-mfc fd=0x6 (main.c:main:415): Successfully opened all necessary files and devices (mfc.c:mfc_dec_setup_output:101): Setup MFC decoding OUTPUT buffer size=1048576 (requested=1048576) (mfc.c:mfc_dec_setup_output:118): Number of MFC OUTPUT buffers is 2 (requested 2) (mfc.c:mfc_dec_setup_output:148): Succesfully mmapped 2 MFC OUTPUT buffers (main.c:extract_and_process_header:84): Extracted header of size 13089 (mfc.c:mfc_dec_queue_buf:178): Queued buffer on OUTPUT queue with index 0 (mfc.c:mfc_stream:236): Stream ON on OUTPUT queue (mfc.c:mfc_dec_setup_capture:277): MFC buffer parameters: 0x0 plane[0]=0 plane[1]=0 Error (mfc.c:mfc_dec_setup_capture:283): Failed to get crop information And kernel print: s5p_mfc_handle_error:420: Interrupt Error: 0035 vidioc_g_crop:782: Cannont set crop It seems MFC buffer parameters error first. The shrek.m4v comes from http://www.uky.edu/~drlane/com351/shrek.m4v and is H264 format. But if I use -c h264, then v4l2_decode will print: Error (parser.c:parse_h264_stream:337): Output buffer too small for current frame Error (main.c:extract_and_process_header:71): Failed to extract header from stream Any suggestions? As far as I know shrek.m4v is an MPEG4 stream. Did you try it as an MPEG4 stream? Thanks. Best wishes, -- Kamil Debski Linux Platform Group Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: MFC decode failed in S5PV210 in kernel 3.8
Hi, This problem is known to us and Marek is planning a fix. However, the problem proved to be quite difficult, so please be patient. Best wishes, -- Kamil Debski Linux Platform Group Samsung Poland RD Center -Original Message- From: Lonsn [mailto:lonsn2...@gmail.com] Sent: Saturday, March 02, 2013 10:20 AM To: undisclosed-recipients: Cc: linux-samsung-soc@vger.kernel.org; linux-me...@vger.kernel.org; k.deb...@samsung.com; Sylwester Nawrocki Subject: Re: MFC decode failed in S5PV210 in kernel 3.8 于 2013/3/2 12:00, Lonsn 写道: Hi, I tested the MFC decode example v4l2_decode from http://git.infradead.org/users/kmpark/public-apps and meet some problems as following: # ./v4l2_decode -f /dev/video5 -m /dev/video9 -d /dev/fb0 -c mpeg4 -i shrek.m4v V4L2 Codec decoding example application Kamil Debski k.deb...@samsung.com Copyright 2012 Samsung Electronics Co., Ltd. (fb.c:fb_open:51): Framebuffer properties: xres=1024, yres=768, bpp=32 (fb.c:fb_open:53): Virtual resolution: vxres=1024 vyres=768 (fimc.c:fimc_open:56): FIMC Info (/dev/video5): driver=s5pv210-fimc bus_info= card=s5pv210-fimc fd=0x5 (mfc.c:mfc_open:57): MFC Info (/dev/video9): driver=s5p-mfc bus_info= card=s5p-mfc fd=0x6 (main.c:main:415): Successfully opened all necessary files and devices (mfc.c:mfc_dec_setup_output:101): Setup MFC decoding OUTPUT buffer size=1048576 (requested=1048576) (mfc.c:mfc_dec_setup_output:118): Number of MFC OUTPUT buffers is 2 (requested 2) (mfc.c:mfc_dec_setup_output:148): Succesfully mmapped 2 MFC OUTPUT buffers (main.c:extract_and_process_header:84): Extracted header of size 13089 (mfc.c:mfc_dec_queue_buf:178): Queued buffer on OUTPUT queue with index 0 (mfc.c:mfc_stream:236): Stream ON on OUTPUT queue (mfc.c:mfc_dec_setup_capture:277): MFC buffer parameters: 0x0 plane[0]=0 plane[1]=0 Error (mfc.c:mfc_dec_setup_capture:283): Failed to get crop information And kernel print: s5p_mfc_handle_error:420: Interrupt Error: 0035 vidioc_g_crop:782: Cannont set crop It seems MFC buffer parameters error first. The shrek.m4v comes from http://www.uky.edu/~drlane/com351/shrek.m4v and is H264 format. But if I use -c h264, then v4l2_decode will print: Error (parser.c:parse_h264_stream:337): Output buffer too small for current frame Error (main.c:extract_and_process_header:71): Failed to extract header from stream Any suggestions? Thanks. Maybe the up issue due to the input file format. Now I use a H264 ES file as input, failed with different output. #./v4l2_decode -f /dev/video5 -m /dev/video9 -d /dev/fb0 -c h264 -i c.h264 Kernel print: Unable to handle kernel NULL pointer dereference at virtual address pgd = afa78000 [] *pgd=4ea37831, *pte=, *ppte= Internal error: Oops: 17 [#1] PREEMPT ARM Modules linked in: CPU: 0Not tainted (3.8.0-dirty #26) PC is at dma_cache_maint_page+0x58/0xa8 LR is at 0x8000 pc : [80014f2c]lr : [8000]psr: a013 sp : ae939ac8 ip : 8050378c fp : aead2240 r10: r9 : 0001 r8 : 804aceec r7 : 0001 r6 : 804b5b70 r5 : fc03 r4 : r3 : 0001 r2 : 0006c000 r1 : r0 : fc03bc00 Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 4fa78019 DAC: 0015 Process v4l2_decode (pid: 2433, stack limit = 0xae938230) Stack: (0xae939ac8 to 0xae93a000) 9ac0: 0001 80778000 80015054 80019398 006c 9ae0: ace36e00 aead2b40 80015d34 0001 8050378c 9b00: ae939b54 aead2b40 804aceec 0001 0001 aead2240 804b5b70 9b20: 80245a4c 00d0 0001 802e41c8 0006c000 aead2280 9b40: 72601000 006c 805037a8 006c af9f8e00 0004306b 1020 acc3d400 9b60: ae939b98 accb9550 acc3d400 accb9550 805116c4 802411c8 9b80: afb1d900 acc3d400 805116c4 0006c000 0006c000 72601000 76f43000 9ba0: 0003 afa0ca98 1080 6193 803604cc ae939bdc 800480a8 9bc0: 804ba074 af907000 00036000 00036000 725cb000 0c36d194 80036da4 9be0: 2113 2193 0401 acd982b8 afb1d900 0003 af9f6144 802b8698 9c00: af9f6000 afb1d900 af9f6144 acd982b8 1080 802bc324 af9f6000 80342690 9c20: afb1d900 1088 af9f6000 afb1d900 1088 af9f6070 c802a8c0 9c40: 1088 802b5338 af9f6000 afb1d900 af9f6038 acf01ee4 8030bdcc 9c60: af9f6000 80360504 af9f6000 8030d39c afb1d900 0011 804d8988 804ab47c 9c80: acf01ee4 8030e5c0 4003 0002 804ab47c af989800 0002 afb1d918 9ca0: 109c 804d8988 acf03310 1402a8c0 c802a8c0 afb1d900 9cc0: 80387d54 804aab68 804d8988 804d8988 0011 0001 802e41c8 9ce0: afb1d900 acf03310 afb1d918 ae939d5c 009c3f49 009c3ecd 802e3da8 9d00: af989800 0084 0029 804ab4ec 804aa66c ae938000 ae939d5c 0008
[PATCH 1/2] ARM: EXYNOS: Add PCIe driver support
Exynos5440 has two PCIe controllers which can be used as Root Complex.
This driver supports the PCIe controllers as Root Complex mode.
Signed-off-by: Surendranath Gurivireddy Balla suren.re...@samsung.com
Signed-off-by: Siva Reddy Kallam siva.kal...@samsung.com
Signed-off-by: Jingoo Han jg1@samsung.com
---
.../devicetree/bindings/pci/exynos-pcie.txt| 58 ++
arch/arm/Kconfig |2 +
arch/arm/mach-exynos/Kconfig |8 +
arch/arm/mach-exynos/Makefile |2 +
arch/arm/mach-exynos/include/mach/pcie.h | 146 +++
arch/arm/mach-exynos/pcie.c| 1009
6 files changed, 1225 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pci/exynos-pcie.txt
create mode 100644 arch/arm/mach-exynos/include/mach/pcie.h
create mode 100644 arch/arm/mach-exynos/pcie.c
diff --git a/Documentation/devicetree/bindings/pci/exynos-pcie.txt
b/Documentation/devicetree/bindings/pci/exynos-pcie.txt
new file mode 100644
index 000..4fe05b5
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/exynos-pcie.txt
@@ -0,0 +1,58 @@
+* Samsung Exynos PCIe interface
+
+Required properties:
+-compatible: should be samsung,pcie-host
+-reg: base addresses and lengths of the pcie conteroller,
+ additional register for the pcie controller,
+ the phy controller,
+ additional register for the phy controller.
+- interrupts: interrupt values for level interrupt,
+ pulse interrupt, special interrupt.
+- pcie-host,io_size: memory size for IO
+- pcie-host,cfg0_size: memory size for CFG0
+- pcie-host,cfg1_size: memory size for CFG1
+- pcie-host,mem_size: memory size for MEM
+- pcie-host,in_mem_size: memory size for Inbound MEM
+- reset-gpio: gpio pin number of power good signal
+
+Example:
+
+SoC specific DT Entry:
+
+ pcie0@4000 {
+ compatible = samsung,pcie-host;
+ reg = 0x4000 0x4000
+ 0x29 0x1000
+ 0x27 0x1000
+ 0x271000 0x40;
+ interrupts = 0 20 0, 0 21 0, 0 22 0;
+ pcie-host,io_size = 0x4000;
+ pcie-host,cfg0_size = 0x10;
+ pcie-host,cfg1_size = 0x10;
+ pcie-host,mem_size = 0x1000;
+ pcie-host,in_mem_size = 0x800;
+ };
+
+ pcie1@6000 {
+ compatible = samsung,pcie-host;
+ reg = 0x6000 0x4000
+ 0x2a 0x1000
+ 0x272000 0x1000
+ 0x271040 0x40;
+ interrupts = 0 23 0, 0 24 0, 0 25 0;
+ pcie-host,io_size = 0x4000;
+ pcie-host,cfg0_size = 0x10;
+ pcie-host,cfg1_size = 0x10;
+ pcie-host,mem_size = 0x1000;
+ pcie-host,in_mem_size = 0x800;
+ };
+
+Board specific DT Entry:
+
+ pcie0@4000 {
+ reset-gpio = 5;
+ };
+
+ pcie1@6000 {
+ reset-gpio = 22;
+ };
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index dedf02b..abfe5ee 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1505,6 +1505,8 @@ config PCI_HOST_ITE8152
source drivers/pci/Kconfig
+source drivers/pci/pcie/Kconfig
+
source drivers/pcmcia/Kconfig
endmenu
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 70f94c8..32de893 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -444,6 +444,14 @@ config EXYNOS4_SDHCI_CH2_8BIT
If selected, Channel 3 is disabled.
endif
+config EXYNOS_PCI
+ bool PCI Express support
+ depends on SOC_EXYNOS5440
+ select PCI
+ select PCIEPORTBUS
+ help
+ Support Exynos PCIe Host controler
+
endmenu
endif
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index 435757e..f87c5f2 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -30,6 +30,8 @@ obj-$(CONFIG_EXYNOS4_MCT) += mct.o
obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
+obj-$(CONFIG_EXYNOS_PCI) += pcie.o
+
# machine support
obj-$(CONFIG_MACH_SMDKC210)+= mach-smdkv310.o
diff --git a/arch/arm/mach-exynos/include/mach/pcie.h
b/arch/arm/mach-exynos/include/mach/pcie.h
new file mode 100644
index 000..6ddd440
--- /dev/null
+++ b/arch/arm/mach-exynos/include/mach/pcie.h
@@ -0,0 +1,146 @@
+/*
+ * PCIe host controller support for EXYNOS SoCs
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * 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.
+ */
+
+#ifndef __MACH_PCIE_H
+#define __MACH_PCIE_H
+
+#include linux/clk.h
+#include linux/pci.h
+#include
[PATCH 2/2] ARM: dts: Add pcie controller node for Samsung EXYNOS5440 SoC
Exynos5440 has two PCIe controllers which can be used as root complex
for PCIe interface.
Signed-off-by: Jingoo Han jg1@samsung.com
---
arch/arm/boot/dts/exynos5440-ssdk5440.dts |8 +++
arch/arm/boot/dts/exynos5440.dtsi | 32 +
2 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5440-ssdk5440.dts
b/arch/arm/boot/dts/exynos5440-ssdk5440.dts
index 81e2c96..ecf6906 100644
--- a/arch/arm/boot/dts/exynos5440-ssdk5440.dts
+++ b/arch/arm/boot/dts/exynos5440-ssdk5440.dts
@@ -43,4 +43,12 @@
rtc {
status = disabled;
};
+
+ pcie0@4000 {
+ reset-gpio = 5;
+ };
+
+ pcie1@6000 {
+ reset-gpio = 22;
+ };
};
diff --git a/arch/arm/boot/dts/exynos5440.dtsi
b/arch/arm/boot/dts/exynos5440.dtsi
index 0bde96d..16bb994 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -151,4 +151,36 @@
reg = 0x13 0x1000;
interrupts = 0 17 0, 0 16 0;
};
+
+ pcie0@4000 {
+ compatible = samsung,pcie-host;
+ reg = 0x4000 0x4000
+ 0x29 0x1000
+ 0x27 0x1000
+ 0x271000 0x40;
+ interrupts = 0 20 0, 0 21 0, 0 22 0;
+ pcie-host,io_size = 0x4000;
+ pcie-host,cfg0_size = 0x10;
+ pcie-host,cfg1_size = 0x10;
+ pcie-host,mem_size = 0x1000;
+ pcie-host,in_mem_size = 0x800;
+ #address-cells = 1;
+ #size-cells = 0;
+ };
+
+ pcie1@6000 {
+ compatible = samsung,pcie-host;
+ reg = 0x6000 0x4000
+ 0x2a 0x1000
+ 0x272000 0x1000
+ 0x271040 0x40;
+ interrupts = 0 23 0, 0 24 0, 0 25 0;
+ pcie-host,io_size = 0x4000;
+ pcie-host,cfg0_size = 0x10;
+ pcie-host,cfg1_size = 0x10;
+ pcie-host,mem_size = 0x1000;
+ pcie-host,in_mem_size = 0x800;
+ #address-cells = 1;
+ #size-cells = 0;
+ };
};
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: EXYNOS: Add PCIe driver support
On 4 March 2013 15:52, Jingoo Han jg1@samsung.com wrote:
Exynos5440 has two PCIe controllers which can be used as Root Complex.
This driver supports the PCIe controllers as Root Complex mode.
Signed-off-by: Surendranath Gurivireddy Balla suren.re...@samsung.com
Signed-off-by: Siva Reddy Kallam siva.kal...@samsung.com
Signed-off-by: Jingoo Han jg1@samsung.com
---
.../devicetree/bindings/pci/exynos-pcie.txt| 58 ++
arch/arm/Kconfig |2 +
arch/arm/mach-exynos/Kconfig |8 +
arch/arm/mach-exynos/Makefile |2 +
arch/arm/mach-exynos/include/mach/pcie.h | 146 +++
arch/arm/mach-exynos/pcie.c| 1009
Is there any reason to place this code in arch/arm/...? As you know,
there is a constant effort to relocate as much code as possible from
arch/arm/mach-exynos. So there must be a strong justification for
keeping this code in arch/arm/mach-exynos.
Thanks,
Thomas.
6 files changed, 1225 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pci/exynos-pcie.txt
create mode 100644 arch/arm/mach-exynos/include/mach/pcie.h
create mode 100644 arch/arm/mach-exynos/pcie.c
diff --git a/Documentation/devicetree/bindings/pci/exynos-pcie.txt
b/Documentation/devicetree/bindings/pci/exynos-pcie.txt
new file mode 100644
index 000..4fe05b5
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/exynos-pcie.txt
@@ -0,0 +1,58 @@
+* Samsung Exynos PCIe interface
+
+Required properties:
+-compatible: should be samsung,pcie-host
+-reg: base addresses and lengths of the pcie conteroller,
+ additional register for the pcie controller,
+ the phy controller,
+ additional register for the phy controller.
+- interrupts: interrupt values for level interrupt,
+ pulse interrupt, special interrupt.
+- pcie-host,io_size: memory size for IO
+- pcie-host,cfg0_size: memory size for CFG0
+- pcie-host,cfg1_size: memory size for CFG1
+- pcie-host,mem_size: memory size for MEM
+- pcie-host,in_mem_size: memory size for Inbound MEM
+- reset-gpio: gpio pin number of power good signal
+
+Example:
+
+SoC specific DT Entry:
+
+ pcie0@4000 {
+ compatible = samsung,pcie-host;
+ reg = 0x4000 0x4000
+ 0x29 0x1000
+ 0x27 0x1000
+ 0x271000 0x40;
+ interrupts = 0 20 0, 0 21 0, 0 22 0;
+ pcie-host,io_size = 0x4000;
+ pcie-host,cfg0_size = 0x10;
+ pcie-host,cfg1_size = 0x10;
+ pcie-host,mem_size = 0x1000;
+ pcie-host,in_mem_size = 0x800;
+ };
+
+ pcie1@6000 {
+ compatible = samsung,pcie-host;
+ reg = 0x6000 0x4000
+ 0x2a 0x1000
+ 0x272000 0x1000
+ 0x271040 0x40;
+ interrupts = 0 23 0, 0 24 0, 0 25 0;
+ pcie-host,io_size = 0x4000;
+ pcie-host,cfg0_size = 0x10;
+ pcie-host,cfg1_size = 0x10;
+ pcie-host,mem_size = 0x1000;
+ pcie-host,in_mem_size = 0x800;
+ };
+
+Board specific DT Entry:
+
+ pcie0@4000 {
+ reset-gpio = 5;
+ };
+
+ pcie1@6000 {
+ reset-gpio = 22;
+ };
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index dedf02b..abfe5ee 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1505,6 +1505,8 @@ config PCI_HOST_ITE8152
source drivers/pci/Kconfig
+source drivers/pci/pcie/Kconfig
+
source drivers/pcmcia/Kconfig
endmenu
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 70f94c8..32de893 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -444,6 +444,14 @@ config EXYNOS4_SDHCI_CH2_8BIT
If selected, Channel 3 is disabled.
endif
+config EXYNOS_PCI
+ bool PCI Express support
+ depends on SOC_EXYNOS5440
+ select PCI
+ select PCIEPORTBUS
+ help
+ Support Exynos PCIe Host controler
+
endmenu
endif
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index 435757e..f87c5f2 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -30,6 +30,8 @@ obj-$(CONFIG_EXYNOS4_MCT) += mct.o
obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
+obj-$(CONFIG_EXYNOS_PCI) += pcie.o
+
# machine support
obj-$(CONFIG_MACH_SMDKC210)+= mach-smdkv310.o
diff --git a/arch/arm/mach-exynos/include/mach/pcie.h
b/arch/arm/mach-exynos/include/mach/pcie.h
new file mode 100644
index 000..6ddd440
--- /dev/null
+++ b/arch/arm/mach-exynos/include/mach/pcie.h
@@ -0,0 +1,146 @@
+/*
+
Re: MFC decode failed in S5PV210 in kernel 3.8
于 2013/3/4 17:30, Kamil Debski 写道: Hi, This problem is known to us and Marek is planning a fix. However, the problem proved to be quite difficult, so please be patient. Best wishes, Kamil, Thanks for your information. Is there any workaround method which can let me continue the MFC decoder test? Is it a MFC driver or v4l2_deocde app question? If it is just an app question, then I would like to use gstreamer with mfc plugin to have a test. Regards, Lonsn -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 03/14] MAINTAINERS: remove arch/arm/plat-s3c24xx/
Cesar Eduardo Barros wrote: This directory was removed by commit 09ec1d7 (ARM: S3C24XX: Remove plat-s3c24xx directory in arch/arm/). Cc: Kukjin Kim kgene@samsung.com Acked-by: Kukjin Kim kgene@samsung.com Thanks. - Kukjin Cc: Ben Dooks ben-li...@fluff.org Cc: Russell King rmk+ker...@arm.linux.org.uk Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Signed-off-by: Cesar Eduardo Barros ces...@cesarb.net --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 3c074d5..5af82f9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1119,7 +1119,6 @@ L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers) W: http://www.fluff.org/ben/linux/ S: Maintained F: arch/arm/plat-samsung/ -F: arch/arm/plat-s3c24xx/ F: arch/arm/mach-s3c24*/ F: arch/arm/mach-s3c64xx/ F: drivers/*/*s3c2410* -- 1.7.11.7 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: S5PV210: Fix PL330 DMA controller clkdev entries
Lonsn wrote: 于 2013/3/2 20:38, Sylwester Nawrocki 写道: Since the DMA controller clocks are managed at amba bus level, the PL330 device clocks handling has been removed from the driver in commit 7c71b8eb268ee38235f7e924d943ea9d90e59469 DMA: PL330: Remove redundant runtime_suspend/resume functions However, this left the S5PV210 platform with only clkdev entries linking apb_pclk clock conn_id to a dummy clock, rather than to corresponding platform PL330 DMAC clock. As a result the DMA controller is now attempted to be used on S5PV210 with the clock disabled and the driver fails with an error: dma-pl330 dma-pl330.0: PERIPH_ID 0x0, PCELL_ID 0x0 ! dma-pl330: probe of dma-pl330.0 failed with error -22 dma-pl330 dma-pl330.1: PERIPH_ID 0x0, PCELL_ID 0x0 ! dma-pl330: probe of dma-pl330.1 failed with error -22 Fix this by adding apb_pclk clkdev entries for the Peripheral DMA controllers 0/1 and removing the dummy apb_pclk clock. Reported-by: Lonsn lonsn2...@gmail.com Cc: Inderpal Singh inderpal.si...@linaro.org Cc: Boojin Kim boojin@samsung.com Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com --- Lonsn, could you check if this patch solves the problem for you, please ? Any Tested-by are welcome. I didn't test this patch on any hardware yet. Once it is confirmed I would resend it, also for stable kernels. It seems this issue is present since v3.7. Sylwester, I have tested this patch and confirmed it's OK in my S5PV210 platform. Looks good to me, applied into -fixes. Sylwester, why did you want to re-send this patch? Thanks. - Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] DMA: PL330: Add check if device tree compatible
On Monday 04 March 2013, Padmavathi Venna wrote:
+
+ if (adev-dev.of_node) {
+ ret = of_dma_controller_register(adev-dev.of_node,
+of_dma_pl330_xlate, pdmac);
+ if (ret) {
+ dev_err(adev-dev,
+ unable to register DMA to the generic DT DMA
helpers\n);
+ goto probe_err4;
+ }
}
Hmm, when I did the same thing in dw_dma, Andy commented that this should
not be a failure at all, since the device is still usable. Could we
instead make of_dma_controller_register return silently when it
gets a NULL of_node?
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: S5PV210: Fix compilation error in mach-goni.c
Sachin Kamat wrote: Hi Sylwester, On 25 February 2013 15:34, Sylwester Nawrocki s.nawro...@samsung.com wrote: Hi Sachin, On 02/25/2013 09:12 AM, Sachin Kamat wrote: Commit 56bc91 ([media] s5p-fimc: Redefine platform data structure for fimc-is) split bus_type into fimc_bus_type and sensor_bus_type and converted all instances of it. This file however escaped the change. Without this patch we get the following build error: arch/arm/mach-s5pv210/mach-goni.c:848:3: error: unknown field 'bus_type' specified in initializer Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Cc: Sylwester Nawrocki s.nawro...@samsung.com Thanks for the patch. My apologies for this omission, there is already similar patch from Arnd [1], [2]. Yes, they fix the same issue. I had not noticed them earlier. So, when can be fixed? arch/arm/mach-s5pv210/mach-goni.c:848:3: error: unknown field 'bus_type' specified in initializer CC arch/arm/mm/idmap.o make[2]: *** [arch/arm/mach-s5pv210/mach-goni.o] Error 1 make[2]: *** Waiting for unfinished jobs - Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] i2c: s3c24xx: allow device core to setup default pin configuration
With device core now able to setup the default pin configuration,
the call to devm_pinctrl_get_select_default can be removed. And
the pin configuration code based on the deprecated Samsung specific
gpio bindings is also removed.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
Hi Heiko, Tomasz,
We have to make a choice on the path forward for pinctrl support
on Samsung platforms. We have three cases to deal with.
A. Samsung platforms without DT support.
B. Samsung platforms with DT support using old Samsung specific
gpio bindings for pin-configuration (s3c24xx and s3x64xx).
C. Samsung platforms with DT support using using pinctrl based
pin-configurations (Exynos4 and Exynos5).
For [A], we just let the platform specific callbacks handle the
pin setup. For [B] and [C], based on Linus Walleij's pin grab
by device core patch and subsequent discussions with him on the
mailing list, would it be acceptable that we discontinue support
for [B] in Samsung SoC device drivers. This will impact your
current DT work on s3c24xx and s3c64xx platforms. Pinctrl is
inevitable and we have to migrate to it. Instead of workarounds
to maintain support for [B], it might be better that we migrate
s3c24xx and s3c64xx platforms to pinctrl.
Please do let us know your opinion on this.
Thanks,
Thomas.
drivers/i2c/busses/i2c-s3c2410.c | 67 +-
1 files changed, 1 insertions(+), 66 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index f6b880b..703272c 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -37,8 +37,6 @@
#include linux/slab.h
#include linux/io.h
#include linux/of_i2c.h
-#include linux/of_gpio.h
-#include linux/pinctrl/consumer.h
#include asm/irq.h
@@ -84,8 +82,6 @@ struct s3c24xx_i2c {
struct i2c_adapter adap;
struct s3c2410_platform_i2c *pdata;
- int gpios[2];
- struct pinctrl *pctrl;
#ifdef CONFIG_CPU_FREQ
struct notifier_block freq_transition;
#endif
@@ -856,57 +852,6 @@ static inline void s3c24xx_i2c_deregister_cpufreq(struct
s3c24xx_i2c *i2c)
}
#endif
-#ifdef CONFIG_OF
-static int s3c24xx_i2c_parse_dt_gpio(struct s3c24xx_i2c *i2c)
-{
- int idx, gpio, ret;
-
- if (i2c-quirks QUIRK_NO_GPIO)
- return 0;
-
- for (idx = 0; idx 2; idx++) {
- gpio = of_get_gpio(i2c-dev-of_node, idx);
- if (!gpio_is_valid(gpio)) {
- dev_err(i2c-dev, invalid gpio[%d]: %d\n, idx, gpio);
- goto free_gpio;
- }
- i2c-gpios[idx] = gpio;
-
- ret = gpio_request(gpio, i2c-bus);
- if (ret) {
- dev_err(i2c-dev, gpio [%d] request failed\n, gpio);
- goto free_gpio;
- }
- }
- return 0;
-
-free_gpio:
- while (--idx = 0)
- gpio_free(i2c-gpios[idx]);
- return -EINVAL;
-}
-
-static void s3c24xx_i2c_dt_gpio_free(struct s3c24xx_i2c *i2c)
-{
- unsigned int idx;
-
- if (i2c-quirks QUIRK_NO_GPIO)
- return;
-
- for (idx = 0; idx 2; idx++)
- gpio_free(i2c-gpios[idx]);
-}
-#else
-static int s3c24xx_i2c_parse_dt_gpio(struct s3c24xx_i2c *i2c)
-{
- return 0;
-}
-
-static void s3c24xx_i2c_dt_gpio_free(struct s3c24xx_i2c *i2c)
-{
-}
-#endif
-
/* s3c24xx_i2c_init
*
* initialise the controller, set the IO lines and frequency
@@ -1054,15 +999,9 @@ static int s3c24xx_i2c_probe(struct platform_device *pdev)
i2c-adap.algo_data = i2c;
i2c-adap.dev.parent = pdev-dev;
- i2c-pctrl = devm_pinctrl_get_select_default(i2c-dev);
-
/* inititalise the i2c gpio lines */
-
- if (i2c-pdata-cfg_gpio) {
+ if (i2c-pdata-cfg_gpio)
i2c-pdata-cfg_gpio(to_platform_device(i2c-dev));
- } else if (IS_ERR(i2c-pctrl) s3c24xx_i2c_parse_dt_gpio(i2c)) {
- return -EINVAL;
- }
/* initialise the i2c controller */
@@ -1140,10 +1079,6 @@ static int s3c24xx_i2c_remove(struct platform_device
*pdev)
i2c_del_adapter(i2c-adap);
clk_disable_unprepare(i2c-clk);
-
- if (pdev-dev.of_node IS_ERR(i2c-pctrl))
- s3c24xx_i2c_dt_gpio_free(i2c);
-
return 0;
}
--
1.6.6.rc2
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: S5PV210: Fix PL330 DMA controller clkdev entries
On 03/04/2013 02:00 PM, Kukjin Kim wrote: Looks good to me, applied into -fixes. Sylwester, why did you want to re-send this patch? Only to add Tested-by: Lonsn lonsn2...@gmail.com Cc: sta...@vger.kernel.org # 3.7 tags, and any other in case someone else tests the patch. I think we would need this fix for stable 3.7 as well. Thanks for applying it. Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: s3c24xx: allow device core to setup default pin configuration
Hi Thomas,
Am Montag, 4. März 2013, 14:42:53 schrieb Thomas Abraham:
With device core now able to setup the default pin configuration,
the call to devm_pinctrl_get_select_default can be removed. And
the pin configuration code based on the deprecated Samsung specific
gpio bindings is also removed.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
Hi Heiko, Tomasz,
We have to make a choice on the path forward for pinctrl support
on Samsung platforms. We have three cases to deal with.
A. Samsung platforms without DT support.
B. Samsung platforms with DT support using old Samsung specific
gpio bindings for pin-configuration (s3c24xx and s3x64xx).
C. Samsung platforms with DT support using using pinctrl based
pin-configurations (Exynos4 and Exynos5).
For [A], we just let the platform specific callbacks handle the
pin setup. For [B] and [C], based on Linus Walleij's pin grab
by device core patch and subsequent discussions with him on the
mailing list, would it be acceptable that we discontinue support
for [B] in Samsung SoC device drivers. This will impact your
current DT work on s3c24xx and s3c64xx platforms. Pinctrl is
inevitable and we have to migrate to it. Instead of workarounds
to maintain support for [B], it might be better that we migrate
s3c24xx and s3c64xx platforms to pinctrl.
Please do let us know your opinion on this.
As discusses in the other thread, I'm in favor of going forward this way and
not to invest unnecessary energy in keeping the non-pinctrl stuff alive.
Pinctrl for at least the s3c2416 [0] is already on my playground-wishlist, but
I'm still in the process of getting to know it.
So for this patch:
Acked-by: Heiko Stuebner he...@sntech.de
Heiko
[0] in contrast to what the gpio-samsung driver implies, the s3c24xx pin banks
are not uniform between SoCs, making this more difficult still :-)
drivers/i2c/busses/i2c-s3c2410.c | 67
+- 1 files changed, 1 insertions(+),
66 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c
b/drivers/i2c/busses/i2c-s3c2410.c index f6b880b..703272c 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -37,8 +37,6 @@
#include linux/slab.h
#include linux/io.h
#include linux/of_i2c.h
-#include linux/of_gpio.h
-#include linux/pinctrl/consumer.h
#include asm/irq.h
@@ -84,8 +82,6 @@ struct s3c24xx_i2c {
struct i2c_adapter adap;
struct s3c2410_platform_i2c *pdata;
- int gpios[2];
- struct pinctrl *pctrl;
#ifdef CONFIG_CPU_FREQ
struct notifier_block freq_transition;
#endif
@@ -856,57 +852,6 @@ static inline void
s3c24xx_i2c_deregister_cpufreq(struct s3c24xx_i2c *i2c) }
#endif
-#ifdef CONFIG_OF
-static int s3c24xx_i2c_parse_dt_gpio(struct s3c24xx_i2c *i2c)
-{
- int idx, gpio, ret;
-
- if (i2c-quirks QUIRK_NO_GPIO)
- return 0;
-
- for (idx = 0; idx 2; idx++) {
- gpio = of_get_gpio(i2c-dev-of_node, idx);
- if (!gpio_is_valid(gpio)) {
- dev_err(i2c-dev, invalid gpio[%d]: %d\n, idx, gpio);
- goto free_gpio;
- }
- i2c-gpios[idx] = gpio;
-
- ret = gpio_request(gpio, i2c-bus);
- if (ret) {
- dev_err(i2c-dev, gpio [%d] request failed\n, gpio);
- goto free_gpio;
- }
- }
- return 0;
-
-free_gpio:
- while (--idx = 0)
- gpio_free(i2c-gpios[idx]);
- return -EINVAL;
-}
-
-static void s3c24xx_i2c_dt_gpio_free(struct s3c24xx_i2c *i2c)
-{
- unsigned int idx;
-
- if (i2c-quirks QUIRK_NO_GPIO)
- return;
-
- for (idx = 0; idx 2; idx++)
- gpio_free(i2c-gpios[idx]);
-}
-#else
-static int s3c24xx_i2c_parse_dt_gpio(struct s3c24xx_i2c *i2c)
-{
- return 0;
-}
-
-static void s3c24xx_i2c_dt_gpio_free(struct s3c24xx_i2c *i2c)
-{
-}
-#endif
-
/* s3c24xx_i2c_init
*
* initialise the controller, set the IO lines and frequency
@@ -1054,15 +999,9 @@ static int s3c24xx_i2c_probe(struct platform_device
*pdev) i2c-adap.algo_data = i2c;
i2c-adap.dev.parent = pdev-dev;
- i2c-pctrl = devm_pinctrl_get_select_default(i2c-dev);
-
/* inititalise the i2c gpio lines */
-
- if (i2c-pdata-cfg_gpio) {
+ if (i2c-pdata-cfg_gpio)
i2c-pdata-cfg_gpio(to_platform_device(i2c-dev));
- } else if (IS_ERR(i2c-pctrl) s3c24xx_i2c_parse_dt_gpio(i2c)) {
- return -EINVAL;
- }
/* initialise the i2c controller */
@@ -1140,10 +1079,6 @@ static int s3c24xx_i2c_remove(struct platform_device
*pdev) i2c_del_adapter(i2c-adap);
clk_disable_unprepare(i2c-clk);
-
- if (pdev-dev.of_node IS_ERR(i2c-pctrl))
- s3c24xx_i2c_dt_gpio_free(i2c);
-
return 0;
}
--
To
Re: State of pinctrl and exynos5250?
Hi Doug, On 2 March 2013 17:18, Tomasz Figa tomasz.f...@gmail.com wrote: Hello Doug, On Friday 01 of March 2013 16:19:39 Doug Anderson wrote: Thomas and Tomasz, I'm trying to get my head wrapped around the state of pinctrl for exynos5250. I see various patches that have floated around at times but it doesn't look like anything has landed. It would be really nice to get this resolved since I think it blocks getting eint support landed for exynos5250 and that blocks getting many peripherals working on the ARM Chromebook. It's great that finally someone noticed the problem (despite my comments to patches adding more and more cruft using the GPIO specifier hack). I'm still a little new to the world on pinctrl so hopefully nothing below is too stupidly wrong... It's always better to ask than to get something completely wrong. Patches that seem to be relevant (NOTE: all of these need pinctrl-exynos5250 fixed to exynos5250-pinctrl): pinctrl: exynos: add exynos5250 SoC specific data - https://patchwork.kernel.org/patch/1871901/ gpio: samsung: skip gpiolib registration if pinctrl support is enabled for exynos5250 - https://patchwork.kernel.org/patch/1871911/ arm: exynos: skip wakeup interrupt registration for exynos5250 if pinctrl is enabled - https://patchwork.kernel.org/patch/1871921/ The 4 patches above are already merged in Kgene's for-next-next (for 3.10) branch. ARM: dts: add pinctrl nodes for Exynos5250 SoC - https://patchwork.kernel.org/patch/1871991/ This one is not merged yet. Since I do not know much about Exynos 5250, I could not verify any hardware-specific details in the patch, just the general correctness of the patch. This patch was not merged since individual drivers needed modification without which it would break existing Exynos5250 based platforms. -- NOTE: Appears to be missing pinctrl_1 and pinctrl_2. That prevents me from compiling with i2c arbitration patches landed since I need gpf0. Indeed. I would prefer adding all of them at once. Ok. I will repost this patch again with pinctrl_1 and pinctrl_2 included. I had not included this in the earlier patch since I was not sure of the best pin grouping for the camera and c2c interface. -- NOTE: Appears (IIRC) to have incorrect interrupt for pinctrl_3. I believe that 45 is pinctrl_1. Maybe 3 is 47? I can't verify this, unfortunately. The documentation does not state this clearly. I will recheck on this and correct as needed. -- NIT NOTE: It appears sd0_busN is strangely specified. Specifically sd0_bus4 includes the pins for sd0_bus1 but sd0_bus8 doesn't. Yes, it is at least somewhat inconsitent. For now this is not really a problem, but eventually it will have to be sanitized. However, note that although sd0_bus8 has the same samsung,pin-function as sd0_bus4, this is no longer the case for sd2_bus8 and sd2_bus4. I would suggest making all the three separate from each other, so 1-bit bus node would just specify sd0_bus1, 4-bit would specify sd0_bus1 and sd0_bus4 and 8-bit all the three. Ok. I will do this change in the next version of the patch. --- I've got all of the above patches fixed up in my local tree (including adding really basic support for pinctrl_1 and pinctrl_2). ...but my machine doesn't boot all the way. I think that's because many of the peripherals don't yet understand pinctrl. Specifically I get delightful looking error messages at bootup that look like: [0.44] _gpio_request: gpio-36 (i2c-bus) status -16 [0.445000] s3c-i2c s3c2440-i2c.0: gpio [36] request failed I then replaced some of the muxing via GPIO with muxing via pinctrl for i2c parts, like: - gpios = gpb3 0 2 3 0, - gpb3 1 2 3 0; + pinctrl-0 = i2c0_bus; + pinctrl-names = default; ...and I got rid of those errors, but it looks like we're missing pinctrl support for the ever-important dw_mmc. [0.91] Synopsys Designware Multimedia Card Interface Driver [0.915000] dwmmc_exynos dw_mmc.0: Using internal DMA controller. [0.92] dwmmc_exynos dw_mmc.0: DW MMC controller at irq 107, 32 bit host data width, 128 deep fifo [0.93] of_get_named_gpio_flags exited with status 40 [0.935000] of_get_named_gpio_flags: can't parse gpios property [0.94] dwmmc_exynos dw_mmc.0: invalid gpio: -2 [0.945000] dwmmc_exynos: probe of dw_mmc.0 failed with error -22 We also need it for spi-s3c64xx.c but that's less of a critical component. [0.405000] of_get_named_gpio_flags exited with status 18 [0.41] /spi@12d3: could not get #gpio-cells for /pinctrl@1140/i2c0-bus [0.415000] of_get_named_gpio_flags: can't parse gpios property [0.42] s3c64xx-spi exynos4210-spi.1: invalid gpio[1]: -22 [0.425000] s3c64xx-spi: probe of exynos4210-spi.1 failed with error -16 Those are the drivers that have their muxing state defined using the old
Re: [PATCH] i2c: s3c24xx: allow device core to setup default pin configuration
On 4 March 2013 19:33, Heiko Stübner he...@sntech.de wrote:
Hi Thomas,
Am Montag, 4. März 2013, 14:42:53 schrieb Thomas Abraham:
With device core now able to setup the default pin configuration,
the call to devm_pinctrl_get_select_default can be removed. And
the pin configuration code based on the deprecated Samsung specific
gpio bindings is also removed.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
Hi Heiko, Tomasz,
We have to make a choice on the path forward for pinctrl support
on Samsung platforms. We have three cases to deal with.
A. Samsung platforms without DT support.
B. Samsung platforms with DT support using old Samsung specific
gpio bindings for pin-configuration (s3c24xx and s3x64xx).
C. Samsung platforms with DT support using using pinctrl based
pin-configurations (Exynos4 and Exynos5).
For [A], we just let the platform specific callbacks handle the
pin setup. For [B] and [C], based on Linus Walleij's pin grab
by device core patch and subsequent discussions with him on the
mailing list, would it be acceptable that we discontinue support
for [B] in Samsung SoC device drivers. This will impact your
current DT work on s3c24xx and s3c64xx platforms. Pinctrl is
inevitable and we have to migrate to it. Instead of workarounds
to maintain support for [B], it might be better that we migrate
s3c24xx and s3c64xx platforms to pinctrl.
Please do let us know your opinion on this.
As discusses in the other thread, I'm in favor of going forward this way and
not to invest unnecessary energy in keeping the non-pinctrl stuff alive.
Pinctrl for at least the s3c2416 [0] is already on my playground-wishlist, but
I'm still in the process of getting to know it.
So for this patch:
Acked-by: Heiko Stuebner he...@sntech.de
Heiko
[0] in contrast to what the gpio-samsung driver implies, the s3c24xx pin banks
are not uniform between SoCs, making this more difficult still :-)
Hi Heiko,
Thanks for the Ack. If the common samsung pinctrl support
(pinctrl-samsung.c) is not well suited for s3c24xx platforms, we could
write a separate pinctrl driver for s3c24xx platforms. But I guess we
might be able to support s3c24xx which some changes to existing code.
If there is anything that I can help with here, please do let me know.
Thanks,
Thomas.
drivers/i2c/busses/i2c-s3c2410.c | 67
+- 1 files changed, 1 insertions(+),
66 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c
b/drivers/i2c/busses/i2c-s3c2410.c index f6b880b..703272c 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -37,8 +37,6 @@
#include linux/slab.h
#include linux/io.h
#include linux/of_i2c.h
-#include linux/of_gpio.h
-#include linux/pinctrl/consumer.h
#include asm/irq.h
@@ -84,8 +82,6 @@ struct s3c24xx_i2c {
struct i2c_adapter adap;
struct s3c2410_platform_i2c *pdata;
- int gpios[2];
- struct pinctrl *pctrl;
#ifdef CONFIG_CPU_FREQ
struct notifier_block freq_transition;
#endif
@@ -856,57 +852,6 @@ static inline void
s3c24xx_i2c_deregister_cpufreq(struct s3c24xx_i2c *i2c) }
#endif
-#ifdef CONFIG_OF
-static int s3c24xx_i2c_parse_dt_gpio(struct s3c24xx_i2c *i2c)
-{
- int idx, gpio, ret;
-
- if (i2c-quirks QUIRK_NO_GPIO)
- return 0;
-
- for (idx = 0; idx 2; idx++) {
- gpio = of_get_gpio(i2c-dev-of_node, idx);
- if (!gpio_is_valid(gpio)) {
- dev_err(i2c-dev, invalid gpio[%d]: %d\n, idx, gpio);
- goto free_gpio;
- }
- i2c-gpios[idx] = gpio;
-
- ret = gpio_request(gpio, i2c-bus);
- if (ret) {
- dev_err(i2c-dev, gpio [%d] request failed\n, gpio);
- goto free_gpio;
- }
- }
- return 0;
-
-free_gpio:
- while (--idx = 0)
- gpio_free(i2c-gpios[idx]);
- return -EINVAL;
-}
-
-static void s3c24xx_i2c_dt_gpio_free(struct s3c24xx_i2c *i2c)
-{
- unsigned int idx;
-
- if (i2c-quirks QUIRK_NO_GPIO)
- return;
-
- for (idx = 0; idx 2; idx++)
- gpio_free(i2c-gpios[idx]);
-}
-#else
-static int s3c24xx_i2c_parse_dt_gpio(struct s3c24xx_i2c *i2c)
-{
- return 0;
-}
-
-static void s3c24xx_i2c_dt_gpio_free(struct s3c24xx_i2c *i2c)
-{
-}
-#endif
-
/* s3c24xx_i2c_init
*
* initialise the controller, set the IO lines and frequency
@@ -1054,15 +999,9 @@ static int s3c24xx_i2c_probe(struct platform_device
*pdev) i2c-adap.algo_data = i2c;
i2c-adap.dev.parent = pdev-dev;
- i2c-pctrl = devm_pinctrl_get_select_default(i2c-dev);
-
/* inititalise the i2c gpio lines */
-
- if (i2c-pdata-cfg_gpio) {
+ if (i2c-pdata-cfg_gpio)
i2c-pdata-cfg_gpio(to_platform_device(i2c-dev));
- } else if
Re: [PATCH] ARM: S5PV210: Fix compilation error in mach-goni.c
On 03/04/2013 02:11 PM, Kukjin Kim wrote: Sachin Kamat wrote: On 25 February 2013 15:34, Sylwester Nawrocki s.nawro...@samsung.com wrote: On 02/25/2013 09:12 AM, Sachin Kamat wrote: Commit 56bc91 ([media] s5p-fimc: Redefine platform data structure for fimc-is) split bus_type into fimc_bus_type and sensor_bus_type and converted all instances of it. This file however escaped the change. Without this patch we get the following build error: arch/arm/mach-s5pv210/mach-goni.c:848:3: error: unknown field 'bus_type' specified in initializer Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Cc: Sylwester Nawrocki s.nawro...@samsung.com Thanks for the patch. My apologies for this omission, there is already similar patch from Arnd [1], [2]. Yes, they fix the same issue. I had not noticed them earlier. So, when can be fixed? Could you apply patch from Arnd: [PATCH 8/9] s5p-fimc: fix s5pv210 build or teh $subject patch from Sachin ? It may take long time to push the fix through the media tree, as Mauro sends bug fixes to Linus usually only twice per whole -rc cycle. And now the issue is only at arch/arm, hence the arm-soc tree may be more appropriate. My apologies for overlooking this, I'll be more careful next time. arch/arm/mach-s5pv210/mach-goni.c:848:3: error: unknown field 'bus_type' specified in initializer CC arch/arm/mm/idmap.o make[2]: *** [arch/arm/mach-s5pv210/mach-goni.o] Error 1 make[2]: *** Waiting for unfinished jobs - Kukjin Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] usb: dwc3: Get PHY from platform specific dwc3 dt node.
Hi, On Fri, Mar 01, 2013 at 08:41:29AM +0200, Felipe Balbi wrote: Moreover, SoCs having multiple dwc3 controllers will have multiple PHYs, which eventually be added using usb_add_phy_dev(), and not using usb_add_phy(). So each dwc3 controller won't be able to get PHYs by simply calling devm_usb_get_phy() also. No. We have added usb_get_phy_dev() for that purpose in the case of non-dt. I think, instead you can have a patch to use devm_usb_get_phy_dev() here and in exynos platform specific code use usb_bind_phy() to bind the phy and controller till you change it to dt. We have dt support for dwc3-exynos, in such case we should go ahead with of_platform_populate(), right ? But if when i use of_platform_populate() i will not be able to set dma_mask to dwc3-dev. :-( do you have a special need for dma_mask because OF already sets it. If i am not wrong of_platform_device_create_pdata() will set dev-dev.coherent_dma_mask = DMA_BIT_MASK(32) and not dma_mask. I fact we had some discussion sometime back when we needed the same for dwc3-exynos in the thread: [PATCH v2 1/2] USB: dwc3-exynos: Add support for device tree But couldn't get final node on it. So suggestions here please. :-) hmm.. you're right there. Grant, Rob ? Any hints ? Any suggestions on this ? anyone ? ping ? -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 06/10] usb: xhci: Enable runtime pm in xhci-plat
On Mon, 4 Mar 2013, Vivek Gautam wrote: @@ -149,6 +150,8 @@ static int xhci_plat_probe(struct platform_device *pdev) if (ret) goto put_usb3_hcd; + pm_runtime_enable(pdev-dev); This is generally not a good idea. You shouldn't enable a device for runtime PM without first telling the PM core what state it is in. Right, but i am not completely sure on any fixed path to follow for enabling runtime power management on a device. :-( Does it become necessary to pm_runtime_set_active or pm_runtime_set_suspended a device before pm_runtime_enable ? Yes, it usually is necesary. And especially here, because the runtime PM core sets the initial status of every device to RPM_SUSPENDED. pm_runtime_enable would just try to decrement the disable_depth of the device. That's right. And once that happens, the PM core would think the device was suspended even though it was really at full power. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/10] usb: phy: Add APIs for runtime power management
Hi,
On Sat, Mar 02, 2013 at 06:53:02PM +0530, Vivek Gautam wrote:
Adding APIs to handle runtime power management on PHY
devices. PHY consumers may need to wake-up/suspend PHYs
when they work across autosuspend.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
include/linux/usb/phy.h | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 15847cb..0fe7cac 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -276,4 +276,30 @@ static inline const char *usb_phy_type_string(enum
usb_phy_type type)
return UNKNOWN PHY TYPE;
}
}
+
+#define USB_PHY_AUTOPM(function) \
+static inline int usb_phy_autopm_##function(struct usb_phy *x)
\
+{\
+ if (!x || !x-dev) {\
+ dev_err(x-dev, no PHY or attached device available\n); \
+ return -ENODEV; \
+ } \
+ \
+ pm_runtime_##function(x-dev); \
please make the definitions explicit (not using a macro) and use:
return pm_runtime_foo();
where applicable. We don't want to return 0 if pm_runtime_get_sync()
fails.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 06/10] usb: xhci: Enable runtime pm in xhci-plat
On Sun, 3 Mar 2013, Felipe Balbi wrote: this is good point and, in fact, a doubt I have myself. How are we supposed to check if device is suspended ? In case it _is_ suspended we might not be able to read device's registers due to clocks possibly being gated. That's really a separate question. It has a simple answer, though: If you want to access a device's registers, call pm_runtime_get_sync() beforehand and pm_runtime_put() (or _put_sync()) afterward. Then it won't matter if the device was suspended originally. that's alright, but how do you want me to check if my device is enabled or not before pm_runtime_enable() ? You're not supposed to check. Just make sure your own pm_runtime_enable() and _disable() calls are done correctly, and let the PM core worry about the rest. :-) More to the point, the question of what code enables a device for runtime PM is decided by the subsystem. Many subsystems will do it automatically so that their drivers don't have to worry about it. Other subsystems will leave it entirely up to the drivers. You have to know what the subsystem wants. In this case, it's appropriate to do the enable here in the probe routine because the platform core doesn't do it for you. This also means the driver should disable the device in the remove routine. I don't know much about clock handling. In general, the pm_runtime_set_active() and pm_runtime_enable() parts should be done by the subsystem, not the driver, whenever possible. good to know :-) Though I disagree with calling pm_runtime_enable() at the subsystem level. It depends on the subsystem. For some (like the USB host subsystem), it is appropriate. Whichever piece of code is responsible for associating a clock with a device should also be responsible for making sure that neither is suspended when the driver's probe routine runs. I'm not sure how different platforms do this; using a PM domain could be one answer. that's alright, but it generates a different set of problems. That same piece of code which associates a device with its clock, doesn't really know if the driver is even available which means we could be enabling clocks for no reason and just wasting precious battery juice ;-) Better than wasting our precious bodily fluids... :-) I guess the best answer is to set up the association but then leave the device and clocks in a runtime-suspended status. Then do a pm_runtime_get_sync() just before calling the driver's probe routine and a pm_runtime_put_sync() just after calling the remove routine. That should leave the device and the clocks in the state the driver expects. (But be careful that these two calls don't invoke the driver's runtime-PM callbacks!) Probably nobody has thought these problems through very carefully for the platform subsystem. Nevertheless, that's where the decisions need to be made. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/4] cpufreq: exynos: Adding cpufreq driver for exynos5440
On 2 March 2013 15:04, Amit Daniel Kachhap amit.dan...@samsung.com wrote:
This patch adds dvfs support for exynos5440 SOC. This soc has 4 cores and
they run at same frequency. The nature of exynos5440 clock controller is
different from previous exynos controllers so not using the common exynos
cpufreq framework. The major difference being interrupt notfication for
frequency change. Also, OPP library is used for device tree parsing to get
different parameters like frequency, voltage etc. Since the opp library sorts
the frequency table in ascending order so they are again re-arranged in
descending order. This will have one-to-one mapping with the clock controller
state management logic.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
Changes in V2:
* Added OPP library support to parse DT parameters.
* Removed a hack to handle interrupts in bootup.
* Added many review comments from Viresh and Inder.
Added? Thanks :)
All these patches are dependent on Thomas Abraham common clock patches.
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg15860.html
.../bindings/cpufreq/cpufreq-exynos5440.txt| 32 ++
drivers/cpufreq/Kconfig.arm|9 +
drivers/cpufreq/Makefile |1 +
drivers/cpufreq/exynos5440-cpufreq.c | 450
4 files changed, 492 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
create mode 100644 drivers/cpufreq/exynos5440-cpufreq.c
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
new file mode 100644
index 000..caa3f8d
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
@@ -0,0 +1,32 @@
+
+Exynos5440 cpufreq driver
+---
+
+Exynos5440 SoC cpufreq driver for CPU frequency scaling.
+
+Required properties:
+- interrupts: Interrupt to know the completion of cpu frequency change.
+- operating-points: Table of frequencies and voltage CPU could be
transitioned into,
+ in the decreasing order. Frequency should be in KHZ units and voltage
+ should be in microvolts.
+- clocks: phandle of the clock from common clock binding. More description
can
+ be found in
Documentation/devicetree/bindings/clock/clock-bindings.txt.
+
+Optional properties:
+- clock-latency: Clock transition latency in microsecond.
+
+All the required listed above must be defined under node cpufreq.
+
+Example:
+
+ cpufreq@16 {
+ compatible = samsung,exynos5440-cpufreq;
+ reg = 0x16 0x1000;
+ interrupts = 0 57 0;
+ operating-points =
+ 100 975000
+ 80 925000;
+ clocks = clock 2;
+ clock-latency = 10;
+ };
+
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 030ddf6..7ed9c4a 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -77,6 +77,15 @@ config ARM_EXYNOS5250_CPUFREQ
This adds the CPUFreq driver for Samsung EXYNOS5250
SoC.
+config ARM_EXYNOS5440_CPUFREQ
+ def_bool SOC_EXYNOS5440
+ depends on HAVE_CLK PM_OPP OF
+ help
+ This adds the CPUFreq driver for Samsung EXYNOS5440
+ SoC. The nature of exynos5440 clock controller is
+ different than previous exynos controllers so not using
+ the common exynos framework.
+
config ARM_KIRKWOOD_CPUFREQ
def_bool ARCH_KIRKWOOD OF
help
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 863fd18..c841438 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += exynos-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos4x12-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o
+obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o
obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o
obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)+= omap-cpufreq.o
obj-$(CONFIG_ARM_SPEAR_CPUFREQ)+= spear-cpufreq.o
diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
b/drivers/cpufreq/exynos5440-cpufreq.c
new file mode 100644
index 000..2dc43b1
--- /dev/null
+++ b/drivers/cpufreq/exynos5440-cpufreq.c
@@ -0,0 +1,450 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Amit Daniel Kachhap amit.dan...@samsung.com
+ *
+ * EXYNOS5440 - CPU frequency scaling support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU
Re: [PATCH] DMA: PL330: Add check if device tree compatible
Hi Arnd,
On Mon, Mar 4, 2013 at 6:28 PM, Arnd Bergmann a...@arndb.de wrote:
On Monday 04 March 2013, Padmavathi Venna wrote:
+
+ if (adev-dev.of_node) {
+ ret = of_dma_controller_register(adev-dev.of_node,
+of_dma_pl330_xlate, pdmac);
+ if (ret) {
+ dev_err(adev-dev,
+ unable to register DMA to the generic DT DMA
helpers\n);
+ goto probe_err4;
+ }
}
Hmm, when I did the same thing in dw_dma, Andy commented that this should
not be a failure at all, since the device is still usable. Could we
instead make of_dma_controller_register return silently when it
gets a NULL of_node?
Ok. I will do that.
Thanks
Padma
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
