Re: [PATCH] ARM: dts: Add peach-pit board support
Hi Sachin,
Thank you for the review.
Will address you comments and post the next version.
Regards
Arun
On Mon, Apr 21, 2014 at 10:59 AM, Sachin Kamat sachin.ka...@linaro.org wrote:
Hi Arun,
On 20 April 2014 10:56, Arun Kumar K arun...@samsung.com wrote:
Adds the google peach-pit board dts file which uses
exynos5420 SoC.
Signed-off-by: Arun Kumar K arun...@samsung.com
Signed-off-by: Doug Anderson diand...@chromium.org
---
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/exynos5420-peach-pit.dts | 225
2 files changed, 226 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5420-peach-pit.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b9d6a8b..09bcb8d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -74,6 +74,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos5250-snow.dtb \
exynos5420-arndale-octa.dtb \
exynos5420-smdk5420.dtb \
+ exynos5420-peach-pit.dtb \
Please arrange alphabetically. This should be added above smdk.
exynos5440-sd5v1.dtb \
exynos5440-ssdk5440.dtb
dtb-$(CONFIG_ARCH_HI3xxx) += hi3620-hi4511.dtb
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
new file mode 100644
index 000..4d61a5e
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -0,0 +1,225 @@
+/*
+ * Google Peach Pit Rev 6+ board device tree source
+ *
+ * Copyright (c) 2014 Google, Inc
+ *
+ * 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.
+ */
+
+/dts-v1/;
+#include exynos5420.dtsi
+
+/ {
+ model = Google Peach Pit Rev 6+;
+
+ compatible = google,pit-rev16,
+ google,pit-rev15, google,pit-rev14,
+ google,pit-rev13, google,pit-rev12,
+ google,pit-rev11, google,pit-rev10,
+ google,pit-rev9, google,pit-rev8,
+ google,pit-rev7, google,pit-rev6,
+ google,pit, google,peach, samsung,exynos5420;
Please include the generic samsung,exynos5 string.
+
+ memory {
+ reg = 0x2000 0x8000;
+ };
+
+ fixed-rate-clocks {
+ oscclk {
+ compatible = samsung,exynos5420-oscclk;
+ clock-frequency = 2400;
+ };
+ };
+
+ pinctrl@1340 {
+ lid_irq: lid-irq {
+ samsung,pins = gpx3-4;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ power_key_irq: power-key-irq {
+ samsung,pins = gpx1-2;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ tpm_irq: tpm-irq {
+ samsung,pins = gpx1-0;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+ };
+
+ pinctrl@1401 {
+ spi_flash_cs: spi-flash-cs {
+ samsung,pins = gpa2-5;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 3;
+ };
+
+ backlight_pwm: backlight-pwm {
+ samsung,pins = gpb2-0;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+ };
+
+ gpio-keys {
+ compatible = gpio-keys;
+
+ pinctrl-names = default;
+ pinctrl-0 = power_key_irq lid_irq;
+
+ power {
+ label = Power;
+ gpios = gpx1 2 1;
+ linux,code = 116; /* KEY_POWER */
You may use the macro directly (instead of code) by including the
appropriate header file
(include/dt-bindings/input/input.h).
--
With warm regards,
Sachin
--
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: dts: disable MDMA1 node for smdk5420 board
On Tue, April 22, 2014, Tushar Behera wrote:
On 22 April 2014 07:48, Kukjin Kim kgene@samsung.com wrote:
Seungwon Jeon wrote:
+ Javi Merino and Tushar Behera
This change is similar to commit 3da355c(ARM: dts: Disable MDMA1 node
for arndale-octa board). If MDMA1 region is configured with secure mode,
it makes the boot failure with the following.
Unhandled fault: imprecise external abort (0x1406) at 0x
If so, how about adding the 'disabled' status in 5420 dtsi file? Then if
'enabling' is required, we
can enable in each board dt file...
That should be okay. While at it, we can remove the node disabling
code from Arndale-Octa board DTS file.
OK, I'll consider both.
Thanks,
Seungwon Jeon
- Kukjin
Signed-off-by: Seungwon Jeon tgih@samsung.com
---
arch/arm/boot/dts/exynos5420-smdk5420.dts |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 6910485..9a48e3f 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -373,4 +373,10 @@
};
};
};
+
+ amba {
+ mdma1: mdma@11C1 {
+ status = disabled;
+ };
+ };
};
--
1.7.0.4
--
Tushar Behera
--
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/9] drm/exynos: dp: support hotplug detection via GPIO
On Tuesday, April 22, 2014 7:39 AM, Ajay Kumar wrote: From: Andrew Bresticker abres...@chromium.org Certain bridge chips use a GPIO to indicate the cable status instead of the I_DP_HPD pin. This adds an optional device-tree property, samsung,hpd-gpio, to the exynos-dp controller which indicates that the specified GPIO should be used for hotplug detection. The GPIO is then set up as an edge-triggered interrupt where the rising edge indicates hotplug-in and the falling edge indicates hotplug-out. Signed-off-by: Andrew Bresticker abres...@chromium.org Signed-off-by: Rahul Sharma rahul.sha...@samsung.com Signed-off-by: Ajay Kumar ajaykumar...@samsung.com Acked-by: Jingoo Han jg1@samsung.com Best regards, Jingoo Han --- Changes since V1: Address reiew comments from Jingoo Han .../devicetree/bindings/video/exynos_dp.txt|4 ++ drivers/gpu/drm/exynos/exynos_dp_core.c| 32 -- drivers/gpu/drm/exynos/exynos_dp_core.h|1 + drivers/gpu/drm/exynos/exynos_dp_reg.c | 44 ++-- 4 files changed, 66 insertions(+), 15 deletions(-) [.] -- 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 3/9] drm/panel: Add driver for exynos_dp based panels
On Tuesday, April 22, 2014 7:39 AM, Ajay Kumar wrote: This patch adds a simple driver to handle all the LCD and LED powerup/down routines needed to support eDP/eDP-LVDS panels supported on exynos boards. The LCD and LED units are usually powered up via regulators, and almost on all boards, we will have a BL_EN pin to enable/ disable the backlight. Sometimes, we can have LCD_EN switches as well. The routines in this driver can be used to control panel power sequence on such boards. Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- Changes since V1: Added routine for post_disable, removed few unwanted headers. Refactored a lot of code. .../devicetree/bindings/panel/exynos-dp-panel.txt | 45 drivers/gpu/drm/panel/Kconfig |9 + drivers/gpu/drm/panel/Makefile |1 + drivers/gpu/drm/panel/panel-exynos-dp.c| 251 4 files changed, 306 insertions(+) create mode 100644 Documentation/devicetree/bindings/panel/exynos-dp-panel.txt create mode 100644 drivers/gpu/drm/panel/panel-exynos-dp.c diff --git a/Documentation/devicetree/bindings/panel/exynos-dp-panel.txt b/Documentation/devicetree/bindings/panel/exynos-dp-panel.txt new file mode 100644 index 000..3fbca54 --- /dev/null +++ b/Documentation/devicetree/bindings/panel/exynos-dp-panel.txt @@ -0,0 +1,45 @@ +exynos_DP_panel/DP_to_LVDS_panel Please fix it as below. +Exynos DP panel/DP to LVDS panel [] diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index 4ec874d..ea9d5ac 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -30,4 +30,13 @@ config DRM_PANEL_S6E8AA0 select DRM_MIPI_DSI select VIDEOMODE_HELPERS +config DRM_PANEL_EXYNOS_DP + tristate support for DP panels It looks very general. Please fix it as below. + tristate support for Exynos DP panels Best regards, Jingoo Han + depends on OF DRM_PANEL DRM_EXYNOS_DP + help + DRM panel driver for DP panels and LVDS connected via DP bridges + that need at most a regulator for LCD unit, a regulator for LED unit + and/or enable GPIOs for LCD or LED units. Delay values can also be + specified to support powerup and powerdown process. + [.] -- 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/2] v4l: Add resolution change event.
Hi Pawel, From: Pawel Osciak [mailto:posc...@chromium.org] Sent: Monday, April 21, 2014 12:27 PM To: Arun Kumar K Cc: linux-me...@vger.kernel.org; linux-samsung-soc; Kamil Debski; Sylwester Nawrocki; Hans Verkuil; Laurent Pinchart Subject: Re: [PATCH v2 1/2] v4l: Add resolution change event. As a side note, because this is not really codified in the API, I would like this event to indicate not only resolution change mid-stream, but also detection of initial resolution, which should be a subset of resolution change. I think this would make sense for the codec interface: Video decode: 1. S_FMT to given codec on OUTPUT queue. 2. REQBUFS(n) and STREAMON on OUTPUT queue. 3. Keep QBUFing until we get an resolution change event on the CAPTURE queue; until then, the driver/codec HW will operate on the OUTPUT queue only and try to detect relevant headers in the OUTPUT buffers, and will send resolution change event once it finds resolution, profile, etc. info). DQEVENT. 4. G_FMT on CAPTURE to get the discovered output format (resolution), REQBUFS and STREAMON on the CAPTURE queue. 5. Normal mem-to-mem decoding. 6. If a resolution change event arrives on CAPTURE queue, DQEVENT, STREAMOFF, REQBUFS(0) only on CAPTURE queue, and goto 4. OUTPUT queue operates completely independently of this. Also, this event should invariably indicate all of the below: - all output buffers from before resolution change are already ready on the CAPTURE queue to DQBUF (so it's ready to REQBUFS(0) after DQBUFs), and - there will be no more new ready buffers on the CAPTURE queue until the streamoff-reqbufs(0)-g_fmt-reqbufs()-streamon is performed, and - OUTPUT queue is completely independent of all of the above and can be still used as normal, i.e. stream buffers can still keep being queued at any stage of the resolution change and they will be decoded after resolution change sequence is finished; If we all agree to the above, I will prepare a subsequent patch for the documentation to include the above. If I understand correctly this will keep the old application working. By this I mean application that do not use events and rely on the current mechanism to detect initial header parsing and resolution change. If backward compatibility is kept I am all for the changes proposed by you. Thanks, Pawel Best wishes, -- Kamil Debski Samsung RD Institute Poland -- 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: [RFC v2 PATCH v2 06/14] drm/exynos: support MIPI DSI command mode
On Mon, Apr 21, 2014 at 09:28:33PM +0900, YoungJun Cho wrote:
[...]
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 7209df1..244d197 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -49,6 +49,7 @@ struct mipi_dsi_msg {
* @detach: detach DSI device from DSI host
* @transfer: send and/or receive DSI packet, return number of received
bytes,
* or error
+ * @te_handler: call CRTC TE handler callback from DSI host
Perhaps you can explain some more what this means or why it would be
necessary.
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index c2ab77a..0ad64ed 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -46,6 +46,13 @@ struct drm_panel {
struct list_head list;
};
+struct drm_panel_cpu_timings {
+ unsigned int cs_setup;
+ unsigned int wr_setup;
+ unsigned int wr_act;
+ unsigned int wr_hold;
+};
Similarily here. What's this?
Thierry
pgpa1qjawTH3P.pgp
Description: PGP signature
Re: [PATCH] ARM: dts: Remove mau_pd node for Exynos5420
Hi Tushar
On Tue, Apr 22, 2014 at 11:09 AM, Tushar Behera
tushar.beh...@linaro.org wrote:
MAU powerdomain provides clocks for Audio sub-system block. This block
comprises of the I2S audio controller, audio DMA blocks and Audio
sub-system clock registers.
Right now, there is no way to hook up power-domains with clock providers.
During late boot when this power-domain gets disabled, we get following
external abort.
?? which abort?? Can you please mention it here?
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
arch/arm/boot/dts/exynos5420.dtsi |5 -
1 file changed, 5 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index c3a9a66..68e0f24 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -219,11 +219,6 @@
reg = 0x100440C0 0x20;
};
- mau_pd: power-domain@100440E0 {
- compatible = samsung,exynos4210-pd;
- reg = 0x100440E0 0x20;
- };
-
g2d_pd: power-domain@10044100 {
compatible = samsung,exynos4210-pd;
reg = 0x10044100 0x20;
--
1.7.9.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
--
Regards,
Alim
--
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 v3 5/5] regulator: tps65090: Make FETs more reliable by adding retries
Mark, On Fri, Apr 18, 2014 at 10:43 AM, Mark Brown broo...@kernel.org wrote: On Wed, Apr 16, 2014 at 04:12:29PM -0700, Doug Anderson wrote: An issue was discovered with tps65090 where sometimes the FETs wouldn't actually turn on when requested (they would report overcurrent). The most problematic FET was the one used for the LCD This is basically fine but you said it depends on one of the previous patches which you didn't CC me on so I've no idea what's going on there? Sorry about that. :( Lee has Acked the caching patch. Lee: what's the best way for you and Mark to coordinate there? Should he apply the caching patch with your Ack? If there are cross-subsystem dependencies I prefer to use immutable branches to eliminate any change of merge conflicts in -next or the next merge window. I'm happy to either create on with Mark's Acks, or receive a pull-request from Mark with mine applied. Up to Mark. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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: dts: Add peach-pit board support
Hi Doug,
Thank you for the review.
On Tue, Apr 22, 2014 at 4:26 AM, Doug Anderson diand...@google.com wrote:
Arun,
On Sat, Apr 19, 2014 at 10:26 PM, Arun Kumar K arun...@samsung.com wrote:
Adds the google peach-pit board dts file which uses
exynos5420 SoC.
Signed-off-by: Arun Kumar K arun...@samsung.com
Signed-off-by: Doug Anderson diand...@chromium.org
---
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/exynos5420-peach-pit.dts | 225
2 files changed, 226 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5420-peach-pit.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b9d6a8b..09bcb8d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -74,6 +74,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos5250-snow.dtb \
exynos5420-arndale-octa.dtb \
exynos5420-smdk5420.dtb \
+ exynos5420-peach-pit.dtb \
exynos5440-sd5v1.dtb \
exynos5440-ssdk5440.dtb
dtb-$(CONFIG_ARCH_HI3xxx) += hi3620-hi4511.dtb
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
new file mode 100644
index 000..4d61a5e
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -0,0 +1,225 @@
+/*
+ * Google Peach Pit Rev 6+ board device tree source
+ *
+ * Copyright (c) 2014 Google, Inc
+ *
+ * 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.
+ */
+
+/dts-v1/;
+#include exynos5420.dtsi
+
+/ {
+ model = Google Peach Pit Rev 6+;
+
+ compatible = google,pit-rev16,
+ google,pit-rev15, google,pit-rev14,
+ google,pit-rev13, google,pit-rev12,
+ google,pit-rev11, google,pit-rev10,
+ google,pit-rev9, google,pit-rev8,
+ google,pit-rev7, google,pit-rev6,
+ google,pit, google,peach, samsung,exynos5420;
+
+ memory {
+ reg = 0x2000 0x8000;
+ };
+
+ fixed-rate-clocks {
+ oscclk {
+ compatible = samsung,exynos5420-oscclk;
+ clock-frequency = 2400;
+ };
+ };
+
+ pinctrl@1340 {
+ lid_irq: lid-irq {
+ samsung,pins = gpx3-4;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ power_key_irq: power-key-irq {
+ samsung,pins = gpx1-2;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ tpm_irq: tpm-irq {
+ samsung,pins = gpx1-0;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+ };
+
+ pinctrl@1401 {
+ spi_flash_cs: spi-flash-cs {
+ samsung,pins = gpa2-5;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 3;
+ };
+
+ backlight_pwm: backlight-pwm {
+ samsung,pins = gpb2-0;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+ };
+
+ gpio-keys {
+ compatible = gpio-keys;
+
+ pinctrl-names = default;
+ pinctrl-0 = power_key_irq lid_irq;
+
+ power {
+ label = Power;
+ gpios = gpx1 2 1;
We should probably make the final number GPIO_ACTIVE_LOW instead of 1.
You'll probably need to add this to the top:
#include dt-bindings/gpio/gpio.h
Yes I will use macro directly.
+ linux,code = 116; /* KEY_POWER */
I believe you can just use KEY_POWER instead of 116 now, though you might
need:
#include dt-bindings/input/input.h
See tegra124-venice2.dts.
+ gpio-key,wakeup;
+ };
+
+ lid-switch {
+ label = Lid;
+ gpios = gpx3 4 1;
+ linux,input-type = 5; /* EV_SW */
+ linux,code = 0; /* SW_LID */
Similar here. Use #defines directly.
Here there is a small issue as code 0 is reserved.
I should add a new code for SW_LID and use it here.
In that case I think its better to add as a separate patch.
+ debounce-interval = 1;
+
Re: [PATCH] ARM: dts: Add peach-pit board support
Hi Tushar,
Thank you for the review.
On Tue, Apr 22, 2014 at 11:13 AM, Tushar Behera
tushar.beh...@linaro.org wrote:
On 20 April 2014 10:56, Arun Kumar K arun...@samsung.com wrote:
Adds the google peach-pit board dts file which uses
exynos5420 SoC.
Signed-off-by: Arun Kumar K arun...@samsung.com
Signed-off-by: Doug Anderson diand...@chromium.org
---
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/exynos5420-peach-pit.dts | 225
2 files changed, 226 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5420-peach-pit.dts
[ snip ]
+ pinctrl@1340 {
+ lid_irq: lid-irq {
+ samsung,pins = gpx3-4;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ power_key_irq: power-key-irq {
+ samsung,pins = gpx1-2;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ tpm_irq: tpm-irq {
+ samsung,pins = gpx1-0;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+ };
+
If you plan to respin, please consider keeping the above entries
sorted based on the pin numbers.
tpm_irq
power_key_irq
lid_irq
Ok will change the order
Regards
Arun
--
Tushar Behera
--
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 v5 0/2] Add Exynos5 USB 3.0 phy driver based on generic PHY framework
Based on 'next' branch of Kishon's phy tree (linux-phy). Tested on 'usb-next' of Greg's usb tree. Changes from v4: 1) Separated out the device tree related arch patches from this patch series. Shall be posting these below mentioned patches (which were part of V4 version of this series) in a separate patch series based on Kgene's next branch. [PATCH v4 2/5]dt: exynos5420: Enable support for USB 3.0 PHY controller [PATCH v4 3/5]dt: exynos5420: Enable support for DWC3 controller [PATCH v4 4/5]dt: exynos5250: Enable support for generic USB DRD phy [PATCH v4 5/5]usb-phy: samsung-usb3: Remove older phy-samsung-usb3 driver 2) Also clubbed the reworked VBUS patch for usb3-drd phy, which was earlier sent as a separate patch: [PATCH] phy: exynos5-usbdrd: Add facility to toggle vbus gpio on/off. https://lkml.org/lkml/2014/4/9/186 1) Removed the mention of separate sclk_usbphy30*, instead this clock will be used as 'ref' phy reference clock while adding the device nodes. 2) Reading the PHYCLKRST register to restore any previous settings, instead of using a separate variable for saving/restoring purpose. 3) Renamed 'samsung,syscon-phandle' property to 'samsung,pmu-syscon'. 4) Removed unnecessary check for of_node property at the starting of driver probe, since this is exclusively DT enabled driver. Changes from V3: 1) Separated out the phy init sequences for utmi and pipe3 phys. 2) Changed the nomenclature across the phy to 'usbdrd-phy' to indicate USB 3.0 DRD PHY controller; and thereby changed the names of functions correspondingly, including specific functions for utmi and pipe3 phys. 3) Modified the DT nodes for the updated nomenclature. 4) Using BIT macro for single bit definitions. 5) Keeping track of reference clock after getting till the removal of phy, and getting the ref clock using devm_clk_get() api. 6) Removed aliases for mutiple channel PHYs, and instead using 'samsung,pmu-offset' property for PHY power control register offset. 7) Keeping the phy_init() and phy_power_on() separately in order to align with phy handling in the consumer (DWC3). Changes from v2: 1) Added support for multiple PHYs (UTMI+ and PIPE3) and related changes in the driver structuring. 2) Added a xlate function to get the required phy out of number of PHYs in mutiple PHY scenerio. 3) Changed the names of few structures and variables to have a clearer meaning. 4) Added 'usb3phy_config' structure to take care of mutiple phys for a SoC having 'exynos5_usb3phy_drv_data' driver data. 5) Not deleting support for old driver 'phy-samsung-usb3' until required support for generic phy is added to DWC3. Changes from RFC patch-set: 1) fixes in documentation file - added provision for syscon interface for using PMU register. - added clock names and description - modified description style for 'compatible property' - made usb30_sclk as additional clock rather then making it optional, since it is actually an additional clock for Exynos5420 Soc. 2) fixes in phy-exynos5-usb3 driver file - removed unnecessary #ifndef around KHZ and MHZ definitions - removed 'samsung_cpu_type', 'usb3phy_state' enums; and merged necessary necessary from 'usb3phy_instance' structure to 'usb3phy_driver'. - changed name 'sclk_usbphy30' to 'usb30_sclk_100m' since this is the name indicated as input to the PHY block; and also added (!IS_ERR()) check for using usb30_sclk. - removed unnecessary 'state' check code. - moved 'of_device_id' structure definitions before 'probe()' to avoid unnecessary declaration. - added (pdev-dev.of_node == NULL) check at the starting of probe() - moved 'devm_of_phy_provider_register()' call to end of the probe(). - removed 'label' for usb3drd phy. - corrected macros definition 'PHYCLKRST_MPLL_MULTIPLIER_50M_REF' from 0x02 to 0x32 after confirming same from PHY's data sheet. - replaced pmu register handling, used for power-isolation, with syscon interface api's. - added '.init' and '.exit' callbacks and using them for one time PHY-initialization and deinitialization. - Filtering out the PHY 'power-on' and 'power-off' sequence to '.power_on and .power_off callbacks. - Removed drivers/usb/phy/phy-samsung-usb3.c driver and related code. 3) fixes in dt files - added reference for 'samsung,syscon-phandle' to used for PMU register. - removed second register field which was earlier used for PMU. Vivek Gautam (2): phy: Add new Exynos5 USB 3.0 PHY driver phy: exynos5-usbdrd: Add facility for VBUS supply .../devicetree/bindings/phy/samsung-phy.txt| 40 ++ drivers/phy/Kconfig| 11 + drivers/phy/Makefile |1 + drivers/phy/phy-exynos5-usbdrd.c
[PATCH v5 2/2] phy: exynos5-usbdrd: Add facility for VBUS supply
Adding support to enable/disable VBUS controlled by a
regulator, to enable vbus supply on the port.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
This is v2 version of patch:
[PATCH] phy: exynos5-usbdrd: Add facility to toggle vbus gpio on/off
https://lkml.org/lkml/2014/4/9/186
Changes from v1:
- Using regulator APIs instead of gpio to control VBUS.
drivers/phy/phy-exynos5-usbdrd.c | 36 +++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index 89d7ae8..d7e3745 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -23,6 +23,7 @@
#include linux/mutex.h
#include linux/mfd/syscon.h
#include linux/regmap.h
+#include linux/regulator/consumer.h
/* Exynos USB PHY registers */
#define EXYNOS5_FSEL_9MHZ6 0x0
@@ -172,6 +173,7 @@ struct exynos5_usbdrd_phy {
unsigned int extrefclk;
struct clk *ref_clk;
unsigned long ref_rate;
+ struct regulator *vbus;
};
#define to_usbdrd_phy(inst) \
@@ -442,6 +444,7 @@ static int exynos5_usbdrd_phy_exit(struct phy *phy)
static int exynos5_usbdrd_phy_power_on(struct phy *phy)
{
+ int ret;
struct phy_usb_instance *inst = phy_get_drvdata(phy);
struct exynos5_usbdrd_phy *phy_drd = to_usbdrd_phy(inst);
@@ -449,10 +452,26 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
clk_prepare_enable(phy_drd-ref_clk);
+ /* Enable VBUS supply */
+ if (phy_drd-vbus) {
+ ret = regulator_enable(phy_drd-vbus);
+ if (ret) {
+ dev_err(phy_drd-dev, Failed to enable VBUS supply\n);
+ goto fail_vbus;
+ }
+ }
+
/* Power-on PHY*/
inst-phy_cfg-phy_isol(inst, 0);
return 0;
+
+fail_vbus:
+ clk_disable_unprepare(phy_drd-ref_clk);
+ if (!IS_ERR(phy_drd-usb30_sclk))
+ clk_disable_unprepare(phy_drd-usb30_sclk);
+
+ return ret;
}
static int exynos5_usbdrd_phy_power_off(struct phy *phy)
@@ -465,6 +484,10 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
/* Power-off the PHY */
inst-phy_cfg-phy_isol(inst, 1);
+ /* Disable VBUS supply */
+ if (phy_drd-vbus)
+ regulator_disable(phy_drd-vbus);
+
clk_disable_unprepare(phy_drd-ref_clk);
return 0;
@@ -537,7 +560,7 @@ static int exynos5_usbdrd_phy_probe(struct platform_device
*pdev)
const struct exynos5_usbdrd_phy_drvdata *drv_data;
struct regmap *reg_pmu;
u32 pmu_offset;
- int i;
+ int i, ret;
phy_drd = devm_kzalloc(dev, sizeof(*phy_drd), GFP_KERNEL);
if (!phy_drd)
@@ -580,6 +603,17 @@ static int exynos5_usbdrd_phy_probe(struct platform_device
*pdev)
return PTR_ERR(reg_pmu);
}
+ /* Get required GPIO for vbus */
+ phy_drd-vbus = devm_regulator_get(dev, vbus);
+ if (IS_ERR(phy_drd-vbus)) {
+ ret = PTR_ERR(phy_drd-vbus);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+
+ dev_warn(dev, Failed to get VBUS supply regulator\n);
+ phy_drd-vbus = NULL;
+ }
+
if (of_property_read_u32(node, samsung,pmu-offset, pmu_offset)) {
dev_err(dev, Missing pmu-offset for phy isolation\n);
return -EINVAL;
--
1.7.10.4
--
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 v5 1/2] phy: Add new Exynos5 USB 3.0 PHY driver
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.
Thereby, removing old phy-samsung-usb3 driver and related code
used untill now which was based on usb/phy framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
.../devicetree/bindings/phy/samsung-phy.txt| 40 ++
drivers/phy/Kconfig| 11 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos5-usbdrd.c | 629
4 files changed, 681 insertions(+)
create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index b422e38..51efe4c 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -114,3 +114,43 @@ Example:
compatible = samsung,exynos-sataphy-i2c;
reg = 0x38;
};
+
+Samsung Exynos5 SoC series USB DRD PHY controller
+--
+
+Required properties:
+- compatible : Should be set to one of the following supported values:
+ - samsung,exynos5250-usbdrd-phy - for exynos5250 SoC,
+ - samsung,exynos5420-usbdrd-phy - for exynos5420 SoC.
+- reg : Register offset and length of USB DRD PHY register set;
+- clocks: Clock IDs array as required by the controller
+- clock-names: names of clocks correseponding to IDs in the clock property;
+ Required clocks:
+ - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
+ used for register access.
+ - ref: PHY's reference clock (usually crystal clock), used for
+ PHY operations, associated by phy name. It is used to
+ determine bit values for clock settings register.
+ For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
+- samsung,pmu-syscon: phandle for PMU system controller interface, used to
+ control pmu registers for power isolation.
+- samsung,pmu-offset: phy power control register offset to
pmu-system-controller
+ base.
+- #phy-cells : from the generic PHY bindings, must be 1;
+
+For samsung,exynos5250-usbdrd-phy and samsung,exynos5420-usbdrd-phy
+compatible PHYs, the second cell in the PHY specifier identifies the
+PHY id, which is interpreted as follows:
+ 0 - UTMI+ type phy,
+ 1 - PIPE3 type phy,
+
+Example:
+ usb3_phy: usbphy@1210 {
+ compatible = samsung,exynos5250-usbdrd-phy;
+ reg = 0x1210 0x100;
+ clocks = clock 286, clock 1;
+ clock-names = phy, ref;
+ samsung,pmu-syscon = pmu_system_controller;
+ samsung,pmu-offset = 0x704;
+ #phy-cells = 1;
+ };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 3bb05f1..8a5d2b4 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -166,4 +166,15 @@ config PHY_XGENE
help
This option enables support for APM X-Gene SoC multi-purpose PHY.
+config PHY_EXYNOS5_USBDRD
+ tristate Exynos5 SoC series USB DRD PHY driver
+ depends on ARCH_EXYNOS5 OF
+ depends on HAS_IOMEM
+ select GENERIC_PHY
+ select MFD_SYSCON
+ help
+ Enable USB DRD PHY support for Exynos 5 SoC series.
+ This driver provides PHY interface for USB 3.0 DRD controller
+ present on Exynos5 SoC series.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 2faf78e..31baa0c 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_PHY_EXYNOS4210_USB2) += phy-exynos4210-usb2.o
obj-$(CONFIG_PHY_EXYNOS4X12_USB2) += phy-exynos4x12-usb2.o
obj-$(CONFIG_PHY_EXYNOS5250_USB2) += phy-exynos5250-usb2.o
obj-$(CONFIG_PHY_XGENE)+= phy-xgene.o
+obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
new file mode 100644
index 000..89d7ae8
--- /dev/null
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -0,0 +1,629 @@
+/*
+ * Samsung EXYNOS5 SoC series USB DRD PHY driver
+ *
+ * Phy provider for USB 3.0 DRD controller on Exynos5 SoC series
+ *
+ * Copyright (C) 2014 Samsung Electronics Co., Ltd.
+ * Author: Vivek Gautam gautam.vi...@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.
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/phy/phy.h
+#include linux/platform_device.h
+#include
Re: [PATCH V2 2/9] drm/panel: add pre_enable and post_disable routines
On Tue, Apr 22, 2014 at 04:09:11AM +0530, Ajay Kumar wrote: Most of the panels need an init sequence as mentioned below: -- poweron LCD unit/LCD_EN -- start video data -- poweron LED unit/BL_EN And, a de-init sequence as mentioned below: -- poweroff LED unit/BL_EN -- stop video data -- poweroff LCD unit/LCD_EN With existing callbacks for drm panel, we cannot accomodate such panels, since only two callbacks, i.e panel_enable and panel_disable are supported. This patch adds: -- pre_enable callback which can be called before the actual video data is on, and then call the enable callback after the video data is available. -- post_disable callback which can be called after the video data is off, and use disable callback to do something before switching off the video data. Now, we can easily map the above scenario as shown below: poweron LCD unit/LCD_EN = pre_enable callback poweron LED unit/BL_EN = enable callback poweroff LED unit/BL_EN = disable callback poweroff LCD unit/LCD_EN = post_disable callback I don't like this. What happens when the next panel comes around that has a yet slightly different requirement? Will we introduce a new pre_pre_enable() and post_post_disable() function then? There's got to be a better way to solve this. Thierry pgpNU101IOjXC.pgp Description: PGP signature
Re: [PATCH] ARM: dts: Remove mau_pd node for Exynos5420
On 22 April 2014 13:08, Alim Akhtar alim.akh...@gmail.com wrote: Hi Tushar On Tue, Apr 22, 2014 at 11:09 AM, Tushar Behera tushar.beh...@linaro.org wrote: MAU powerdomain provides clocks for Audio sub-system block. This block comprises of the I2S audio controller, audio DMA blocks and Audio sub-system clock registers. Right now, there is no way to hook up power-domains with clock providers. During late boot when this power-domain gets disabled, we get following external abort. ?? which abort?? Can you please mention it here? Thanks Alim for spotting this ... I somehow missed adding this. Unhandled fault: imprecise external abort (0x1406) at 0x Kernel panic - not syncing: Attempted to kill init! exitcode=0x0007 Kukjin, Let me know if I need to resend the patch. -- Tushar Behera -- 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: dts: disable MDMA1 node for smdk5420 board
On 22 April 2014 12:31, Seungwon Jeon tgih@samsung.com wrote: On Tue, April 22, 2014, Tushar Behera wrote: On 22 April 2014 07:48, Kukjin Kim kgene@samsung.com wrote: Seungwon Jeon wrote: + Javi Merino and Tushar Behera This change is similar to commit 3da355c(ARM: dts: Disable MDMA1 node for arndale-octa board). If MDMA1 region is configured with secure mode, it makes the boot failure with the following. Unhandled fault: imprecise external abort (0x1406) at 0x If so, how about adding the 'disabled' status in 5420 dtsi file? Then if 'enabling' is required, we can enable in each board dt file... That should be okay. While at it, we can remove the node disabling code from Arndale-Octa board DTS file. OK, I'll consider both. Seungwon, Please move the comments for MDMA1 from Arndale-Octa dts file too. Thanks. -- Tushar Behera -- 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 3/9] drm/panel: Add driver for exynos_dp based panels
On Tue, Apr 22, 2014 at 04:09:12AM +0530, Ajay Kumar wrote: This patch adds a simple driver to handle all the LCD and LED powerup/down routines needed to support eDP/eDP-LVDS panels supported on exynos boards. The LCD and LED units are usually powered up via regulators, and almost on all boards, we will have a BL_EN pin to enable/ disable the backlight. Sometimes, we can have LCD_EN switches as well. The routines in this driver can be used to control panel power sequence on such boards. Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- Changes since V1: Added routine for post_disable, removed few unwanted headers. Refactored a lot of code. .../devicetree/bindings/panel/exynos-dp-panel.txt | 45 drivers/gpu/drm/panel/Kconfig |9 + drivers/gpu/drm/panel/Makefile |1 + drivers/gpu/drm/panel/panel-exynos-dp.c| 251 4 files changed, 306 insertions(+) create mode 100644 Documentation/devicetree/bindings/panel/exynos-dp-panel.txt create mode 100644 drivers/gpu/drm/panel/panel-exynos-dp.c What this patch does is in no way Exynos specific. It is also not eDP specific. This conflates panel drivers with board drivers in a strange way. Panel drivers should be for *panels*, not for a given SoC or specific outputs on that SoC. Thierry pgpyjTKjSpTcF.pgp Description: PGP signature
Re: [PATCH V2 4/9] drm/exynos: add exynos_dp_panel driver registration to drm driver
On Tue, Apr 22, 2014 at 04:09:13AM +0530, Ajay Kumar wrote: Register exynos_dp_panel before the list of exynos crtcs and connectors are probed. This is needed because exynos_dp_panel should be registered to the drm_panel list via panel-exynos-dp probe, i.e much before exynos_dp_bind calls of_drm_find_panel(). Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- Changes since V1: Added platform_driver_unregister(exynos_dp_panel_driver) to exynos_drm_platform_remove as per Jingoo Han's correction drivers/gpu/drm/exynos/exynos_drm_drv.c | 15 +++ drivers/gpu/drm/exynos/exynos_drm_drv.h |1 + 2 files changed, 16 insertions(+) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index 1d653f8..2db7f67 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -530,12 +530,23 @@ static int exynos_drm_platform_probe(struct platform_device *pdev) goto err_unregister_ipp_drv; #endif +#ifdef CONFIG_DRM_PANEL_EXYNOS_DP + ret = platform_driver_register(exynos_dp_panel_driver); + if (ret 0) + goto err_unregister_dp_panel; +#endif No, this is not how you're supposed to use DRM panel drivers. The idea is that you write a standalone driver for a given panel. What you do here has a number of problems. For one it's a driver that's tightly coupled to Exynos SoCs. But if I have a different SoC that uses the same panel I want to be able to use the same driver, and not have to rewrite the driver for my SoC. Another problem is that you're assuming here that the driver is built in and it will break if you try to build either Exynos DRM or the panel driver as a module. This is perhaps nothing you care about right now, but eventually people will want to ship a single kernel that can run on a number of SoCs. But if we keep adding things like this, that kernel will keep growing in size until it no longer fits in any kind of memory. Thierry pgpql268hNZYb.pgp Description: PGP signature
Re: [PATCH V2 5/9] drm/exynos: dp: modify driver to support drm_panel
On Tue, Apr 22, 2014 at 04:09:14AM +0530, Ajay Kumar wrote:
[...]
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
[...]
@@ -1299,6 +1308,15 @@ static int exynos_dp_bind(struct device *dev, struct
device *master, void *data)
INIT_WORK(dp-hotplug_work, exynos_dp_hotplug);
+ panel_node = of_find_compatible_node(NULL, NULL,
+ samsung,exynos-dp-panel);
No, please don't do this. It will break as soon as you have two panels
of the same type in one system.
Also the compatible value of a panel should describe the specific panel
in use (e.g. samsung,s6e8aa0), so you shouldn't rely on magic like
this. Use a phandle to find the panel's struct device_node.
[...]
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h
b/drivers/gpu/drm/exynos/exynos_dp_core.h
index 56fa43e..9dc7991 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.h
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
@@ -148,6 +148,7 @@ struct exynos_dp_device {
struct drm_device *drm_dev;
struct drm_connectorconnector;
struct drm_encoder *encoder;
+ struct drm_panel*drm_panel;
I don't think you need the drm_ prefix here.
Thierry
pgppxVpV2ak3y.pgp
Description: PGP signature
Re: [PATCH RFC 3/3] drm/exynos: use pending_components for components tracking
Hi Russel, My answer little bit later due to Easter. On 04/18/2014 02:42 PM, Russell King - ARM Linux wrote: On Fri, Apr 18, 2014 at 01:27:53PM +0200, Andrzej Hajda wrote: Hi Russel, Thanks for comments. On 04/17/2014 11:47 PM, Russell King - ARM Linux wrote: On Thu, Apr 17, 2014 at 01:28:50PM +0200, Andrzej Hajda wrote: +out: + if (ret != -EPROBE_DEFER) + exynos_drm_dev_ready(pdev-dev); So we end up with everyone needing a ready call in each sub-driver back into the main driver... this makes it impossible to write a generic subcomponent driver which is not tied in any way to the main driver. That is quite some restriction, and would prevent, for example, the TDA998x driver being used both with Armada DRM, tilcdc and any other driver. As I see in armada driver drm is deferred in case tda998x is not yet available. The same solution can be still used with pending_devices approach - the main driver will not report its readiness until tda998x is present. Anyway it still seems to be better than componentize every driver which can probably become a part of some superdevice. If you want to get rid of deferred probe one can make global list of 'ready' devices with notifications systems for master devices. Maybe it would be good to consider notification system for devices probe result, it will require that driver register all its interfaces in probe, ie its readiness cannot be reported later but will not require to add new framework. I hope just extending current notification system should be enough. You aren't addressing my point. If I were to convert tda998x to use your infrastructure, then I would have to add in ifdefs to tie it into armada DRM _and_ a different set of ifdefs to tie it into tilcdc. Then when someone else wanted to use it in their driver, they'd have to add yet more ifdefs into it to tie it into their driver. This does not scale. As I already answered, you should not use 'my' framework for tda998x driver, you can still use current approach with deferred probe. I am not sure why have you used ifdefs in armada, tilcdc also uses tda998x and without ifdefs. 'My' framework (I think helper library is a better name) was created to use with devices which are closely tied together by another framework - case of some SoC devices. So, please address my point: in your system, how can a single component be shared between multiple different master drivers? I have answered this question above, again. But your question suggests you want to componentize also drivers which are shared by different DRMs. How do you want to do it? - componentize all DRM drivers sharing given driver? - componentize shared device in a way that it can used by non-componentized devices? how? I guess it will be possible but will have some price. Regards Andrzej -- 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 8/9] drm/bridge: Add PS8622 bridge driver
On Tuesday, April 22, 2014 7:39 AM, Ajay Kumar wrote:
This patch adds a drm_bridge driver for the PS8622 DisplayPort to LVDS
bridge chip.
Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Sean Paul seanp...@chromium.org
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
Changes since V1:
Pushing V1 for this as V2 because this patch holds good in this series.
drivers/gpu/drm/bridge/Kconfig |7 +
drivers/gpu/drm/bridge/Makefile |1 +
drivers/gpu/drm/bridge/ps8622.c | 566
+++
include/drm/bridge/ps8622.h | 42 +++
4 files changed, 616 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/ps8622.c
create mode 100644 include/drm/bridge/ps8622.h
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3bc6845..aba21fc 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -4,3 +4,10 @@ config DRM_PTN3460
select DRM_KMS_HELPER
select DRM_PANEL
---help---
+
+config DRM_PS8622
+ tristate Parade eDP/LVDS bridge
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_PANEL
Please add the following select.
+ select BACKLIGHT_LCD_SUPPORT
+ select BACKLIGHT_CLASS_DEVICE
Without this, the following build issues happen.
drivers/gpu/drm/bridge/ps8622.c:353: undefined reference to
`backlight_device_unregister'
drivers/built-in.o: In function `ps8622_init':
drivers/gpu/drm/bridge/ps8622.c:559: undefined reference to
`backlight_device_unregister'
drivers/gpu/drm/bridge/ps8622.c:507: undefined reference to
`backlight_device_register'
+ ---help---
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index b4733e1..d1b5daa 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,3 +1,4 @@
ccflags-y := -Iinclude/drm
obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
+obj-$(CONFIG_DRM_PS8622) += ps8622.o
diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
new file mode 100644
index 000..1e6b3ca
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ps8622.c
[.]
+static int ps8622_send_config(struct ps8622_bridge *ps_bridge)
+{
+ struct i2c_client *cl = ps_bridge-client;
+ int err = 0;
+
+ /* wait 20ms after power ON */
+ usleep_range(2, 3);
+
+ err |= ps8622_set(cl, 0x02, 0xa1, 0x01); /* HPD low */
+ /* SW setting */
+ err |= ps8622_set(cl, 0x04, 0x14, 0x01); /* [1:0] SW output 1.2V voltage
+ * is lower to 96% */
The comment style looks awkward.
Please choose one of two options. And change all comments in this file.
1.
+ /* SW setting */
+ err |= ps8622_set(cl, 0x04, 0x14, 0x01); /* [1:0] SW output 1.2V
voltage is lower to 96% */
2.
+ /* SW setting */
+ /* [1:0] SW output 1.2V voltage is lower to 96% */
+ err |= ps8622_set(cl, 0x04, 0x14, 0x01);
+ /* RCO SS setting */
+ err |= ps8622_set(cl, 0x04, 0xe3, 0x20); /* [5:4] = b01 0.5%, b10 1%,
+ * b11 1.5% */
+ err |= ps8622_set(cl, 0x04, 0xe2, 0x80); /* [7] RCO SS enable */
+ /* RPHY Setting */
+ err |= ps8622_set(cl, 0x04, 0x8a, 0x0c); /* [3:2] CDR tune wait cycle
+ * before measure for fine tune
+ * b00: 1us b01: 0.5us b10:2us
+ * b11: 4us */
+ err |= ps8622_set(cl, 0x04, 0x89, 0x08); /* [3] RFD always on */
+ err |= ps8622_set(cl, 0x04, 0x71, 0x2d); /* CTN lock in/out:
+ * 2ppm/8ppm.
+ * Lock out 2 times. */
+ /* 2.7G CDR settings */
+ err |= ps8622_set(cl, 0x04, 0x7d, 0x07); /* NOF=40LSB for HBR CDR
+ * setting */
+ err |= ps8622_set(cl, 0x04, 0x7b, 0x00); /* [1:0] Fmin=+4bands */
+ err |= ps8622_set(cl, 0x04, 0x7a, 0xfd); /* [7:5] DCO_FTRNG=+-40% */
+ /* 1.62G CDR settings */
+ err |= ps8622_set(cl, 0x04, 0xc0, 0x12); /* [5:2]NOF=64LSB [1:0]DCO
+ * scale is 2/5 */
+ err |= ps8622_set(cl, 0x04, 0xc1, 0x92); /* Gitune=-37% */
+ err |= ps8622_set(cl, 0x04, 0xc2, 0x1c); /* Fbstep=100% */
+ err |= ps8622_set(cl, 0x04, 0x32, 0x80); /* [7] LOS signal disable */
+ /* RPIO Setting */
+ err |= ps8622_set(cl, 0x04, 0x00, 0xb0); /* [7:4] LVDS driver bias
+ * current : 75% (250mV swing)
+ * */
+ err |= ps8622_set(cl, 0x04, 0x15, 0x40); /* [7:6] Right-bar GPIO output
+ * strength
Re: [PATCH V2 6/9] drm/bridge: ptn3460: enable polling based detection
On Tue, Apr 22, 2014 at 04:09:15AM +0530, Ajay Kumar wrote: From: Rahul Sharma rahul.sha...@samsung.com Add DRM_CONNECTOR_POLL_HPD to the set of connector flags while registering drm_connector for ptn3460. Signed-off-by: Rahul Sharma rahul.sha...@samsung.com Signed-off-by: Ajay Kumar ajaykumar...@samsung.com This needs to explain *why* you think this change is necessary. As far as I can see, the PTN3460 bridge doesn't support hotplug detection at all, in which case setting DRM_CONNECTOR_POLL_HPD would be completely wrong. Thierry pgp9Kms_yD1xd.pgp Description: PGP signature
RE: [PATCH v2 1/2] v4l: Add resolution change event.
Hi Pawel, From: Pawel Osciak [mailto:posc...@chromium.org] Sent: Tuesday, April 22, 2014 9:46 AM To: Kamil Debski Cc: Arun Kumar K; linux-me...@vger.kernel.org; linux-samsung-soc; Sylwester Nawrocki; Hans Verkuil; Laurent Pinchart Subject: Re: [PATCH v2 1/2] v4l: Add resolution change event. Hi Kamil, On Tue, Apr 22, 2014 at 4:34 PM, Kamil Debski k.deb...@samsung.com wrote: Hi Pawel, From: Pawel Osciak [mailto:posc...@chromium.org] Sent: Monday, April 21, 2014 12:27 PM To: Arun Kumar K Cc: linux-me...@vger.kernel.org; linux-samsung-soc; Kamil Debski; Sylwester Nawrocki; Hans Verkuil; Laurent Pinchart Subject: Re: [PATCH v2 1/2] v4l: Add resolution change event. As a side note, because this is not really codified in the API, I would like this event to indicate not only resolution change mid- stream, but also detection of initial resolution, which should be a subset of resolution change. I think this would make sense for the codec interface: Video decode: 1. S_FMT to given codec on OUTPUT queue. 2. REQBUFS(n) and STREAMON on OUTPUT queue. 3. Keep QBUFing until we get an resolution change event on the CAPTURE queue; until then, the driver/codec HW will operate on the OUTPUT queue only and try to detect relevant headers in the OUTPUT buffers, and will send resolution change event once it finds resolution, profile, etc. info). DQEVENT. 4. G_FMT on CAPTURE to get the discovered output format (resolution), REQBUFS and STREAMON on the CAPTURE queue. 5. Normal mem-to-mem decoding. 6. If a resolution change event arrives on CAPTURE queue, DQEVENT, STREAMOFF, REQBUFS(0) only on CAPTURE queue, and goto 4. OUTPUT queue operates completely independently of this. Also, this event should invariably indicate all of the below: - all output buffers from before resolution change are already ready on the CAPTURE queue to DQBUF (so it's ready to REQBUFS(0) after DQBUFs), and - there will be no more new ready buffers on the CAPTURE queue until the streamoff-reqbufs(0)-g_fmt-reqbufs()-streamon is performed, and - OUTPUT queue is completely independent of all of the above and can be still used as normal, i.e. stream buffers can still keep being queued at any stage of the resolution change and they will be decoded after resolution change sequence is finished; If we all agree to the above, I will prepare a subsequent patch for the documentation to include the above. If I understand correctly this will keep the old application working. By this I mean application that do not use events and rely on the current mechanism to detect initial header parsing and resolution change. If backward compatibility is kept I am all for the changes proposed by you. MFC codec depends on the userspace to parse the stream and pass the stream header with resolution info before calling G_FMT. So if it ignores the events but keeps doing this, things should keep working I think, as the G_FMT should still work as before. This event will help userspace that doesn't want to bother itself with parsing the stream to know if the right header was queued and rely on events to know when to call G_FMT instead. What do you think? Am I missing something? Do you think this will work with all MFC versions? I guess that your focus is on the newer MFC version such as v6 or even v7. I had worked mostly with the v5 version and I am not sure how well it will handle the situation when it does not receive the header as the first frame. Do you have a target with v5 of MFC at hand? I really like your idea. If you haven't got the possibility to check how it works on v5 then I suggest you go ahead with patches and later I will do some testing on MFC v5. Best wishes, -- Kamil Debski Samsung RD Institute Poland -- 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 9/9] drm/exynos: Add ps8622 lvds bridge discovery to DP driver
On Tue, Apr 22, 2014 at 04:09:18AM +0530, Ajay Kumar wrote:
This patch adds ps8622 lvds bridge discovery code to the dp driver.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
Changes since V1:
Pushing V1 for this as V2 because this patch holds good in this series.
drivers/gpu/drm/exynos/exynos_dp_core.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 4853f31..0006412 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -30,6 +30,7 @@
#include drm/drm_crtc_helper.h
#include drm/drm_panel.h
#include drm/bridge/ptn3460.h
+#include drm/bridge/ps8622.h
#include exynos_drm_drv.h
#include exynos_dp_core.h
@@ -999,7 +1000,15 @@ static int exynos_drm_attach_lcd_bridge(struct
drm_device *dev,
panel);
if (!ret)
return 1;
+ } else if (find_bridge(parade,ps8625, bridge)) {
So this is where the inspiration for the of_find_compatible_node() in
the earlier patch came from.
+ ret = ps8622_init(dev, encoder, bridge.client, bridge.node,
+ panel);
Long-term I don't think this is going to scale very well. In my opinion
it would be much more useful to have the bridge driver initialize what
it can and then have the DRM driver call a generic initialization
function to bind it to the DRM device or encoder. Otherwise we have to
keep knowledge about the type of bridge in each driver that uses it,
whereas the goal (I think) would be to create a proper abstraction so
that the DRM driver doesn't have to know that kind of detail.
Thierry
pgpD0K6ubYmVm.pgp
Description: PGP signature
Re: [PATCH v2] serial_core: Commonalize crlf when working w/ a non open console port
I've moved the handling to uart_poll_put_char() to fix the above problems. Now when I use kdb (and don't point console= to the same UART) I no longer get: [0]kdb [0]kdb [0]kdb Signed-off-by: Doug Anderson diand...@chromium.org This seems sensible Reviewed-by: Alan Cox a...@linux.intel.com -- 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 3/4] exynos: cpuidle: do not allow cpuidle registration for Exynos5420
On 04/21/2014 01:49 PM, Chander Kashyap wrote: Exynos5420 is big.Little Soc. It uses cpuidle-big-litle generic cpuidle driver. Hence do not allow exynos cpuidle driver registration for Exynos5420. Signed-off-by: Chander Kashyap chander.kash...@linaro.org Signed-off-by: Chander Kashyap k.chan...@samsung.com --- Acked-by: Daniel Lezcano daniel.lezc...@linaro.org but will conflict with: http://www.spinics.net/lists/arm-kernel/msg319862.html arch/arm/mach-exynos/cpuidle.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c index c57cae0..242f75d 100644 --- a/arch/arm/mach-exynos/cpuidle.c +++ b/arch/arm/mach-exynos/cpuidle.c @@ -219,6 +219,9 @@ static int exynos_cpuidle_probe(struct platform_device *pdev) int cpu_id, ret; struct cpuidle_device *device; + if (soc_is_exynos5420()) + return -ENODEV; + if (soc_is_exynos5250()) exynos5_core_down_clk(); -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- 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 2/4] driver: cpuidle: cpuidle-big-little: init driver for Exynos5420
On 04/21/2014 01:49 PM, Chander Kashyap wrote: Add samsung,exynos5420 compatible string to initialize generic big-little cpuidle driver for Exynos5420. Signed-off-by: Chander Kashyap chander.kash...@linaro.org Signed-off-by: Chander Kashyap k.chan...@samsung.org --- To be migrated to platform_driver but until that: Acked-by: Daniel Lezcano daniel.lezc...@linaro.org drivers/cpuidle/cpuidle-big_little.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/cpuidle/cpuidle-big_little.c b/drivers/cpuidle/cpuidle-big_little.c index b45fc62..d0fac53 100644 --- a/drivers/cpuidle/cpuidle-big_little.c +++ b/drivers/cpuidle/cpuidle-big_little.c @@ -170,7 +170,8 @@ static int __init bl_idle_init(void) /* * Initialize the driver just for a compliant set of machines */ - if (!of_machine_is_compatible(arm,vexpress,v2p-ca15_a7)) + if (!of_machine_is_compatible(arm,vexpress,v2p-ca15_a7) + (!of_machine_is_compatible(samsung,exynos5420))) return -ENODEV; /* * For now the differentiation between little and big cores -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- 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/4] cpuidle: config: Add SOC_EXYNOS5420 entry to select cpuidle-big-little driver
On 04/21/2014 01:49 PM, Chander Kashyap wrote: Exynos5420 is a big-little SoC from Samsung. It has 4 A15 and 4 A7 cores. In order to use generic cpuidle-big-little driver, this patch adds Exynos5420 specific check to initialize generic cpuidle driver. Signed-off-by: Chander Kashyap chander.kash...@linaro.org Signed-off-by: Chander Kashyap k.chan...@samsung.com --- drivers/cpuidle/Kconfig.arm |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm index 97ccc31..5244d87 100644 --- a/drivers/cpuidle/Kconfig.arm +++ b/drivers/cpuidle/Kconfig.arm @@ -4,7 +4,7 @@ config ARM_BIG_LITTLE_CPUIDLE bool Support for ARM big.LITTLE processors - depends on ARCH_VEXPRESS_TC2_PM + depends on ARCH_VEXPRESS_TC2_PM || SOC_EXYNOS5420 For the sake of consistency, I would prefer: depends on ARCH_VEXPRESS_TC2_PM || ARCH_EXYNOS and let the current code (and future platform driver) to handle the loading of the driver. select ARM_CPU_SUSPEND select CPU_IDLE_MULTIPLE_DRIVERS help -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- 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] ASoC: SAMSUNG: Add sound card driver for Snow board
On Tue, Apr 22, 2014 at 01:33:54PM +0530, Tushar Behera wrote:
Added machine driver to instantiate I2S based sound card on Snow
board. It has MAX98095 audio codec on board.
In general this isn't up to modern standards, please do try to check
that new code is following best practices. Did the support for setting
the clocking up in the device tree get merged already?
Please do also pay attention to the CC lists when posting patches, this
seems to have been sent to a fairly random selection of people and
lists.
+ switch (params_format(params)) {
params_width().
+ ret = snd_soc_dai_set_fmt(codec_dai, SND_SOC_DAIFMT_I2S |
+ SND_SOC_DAIFMT_NB_NF |
+ SND_SOC_DAIFMT_CBS_CFS);
Set this in the dai_link.
+ ret = snd_soc_dai_set_sysclk(codec_dai, 0,
+ FIN_PLL_RATE, SND_SOC_CLOCK_IN);
+ if (ret 0)
+ return ret;
+
+ ret = snd_soc_dai_set_sysclk(cpu_dai, SAMSUNG_I2S_CDCLK,
+ 0, SND_SOC_CLOCK_OUT);
+ if (ret 0)
+ return ret;
+
+ ret = snd_soc_dai_set_clkdiv(cpu_dai, SAMSUNG_I2S_DIV_BCLK, bfs);
+ if (ret 0)
+ return ret;
Set this stuff up on probe. I'm surprised that you need to set BCLK at
all...
+static int snow_init(struct snd_soc_pcm_runtime *rtd)
+{
+ struct snd_soc_codec *codec = rtd-codec;
+ struct snd_soc_dapm_context *dapm = codec-dapm;
+
+ snd_soc_dapm_sync(dapm);
+
+ return 0;
+}
This does nothing, remove it.
+ if (!pdev-dev.platform_data !pdev-dev.of_node) {
+ dev_err(pdev-dev, No platform data supplied\n);
+ return -EINVAL;
+ }
+
+ name = of_get_property(pdev-dev.of_node, card-name, NULL);
+ if (name)
+ card-name = name;
+
+ i2s_node = of_parse_phandle(pdev-dev.of_node,
+ samsung,i2s-controller, 0);
+ if (!i2s_node) {
+ dev_err(pdev-dev,
+ Property 'i2s-controller' missing or invalid\n);
+ return -EINVAL;
+ }
You're allowing platform data above but I see DT is mandatory here.
+ ret = snd_soc_register_card(card);
+ if (ret) {
+ dev_err(pdev-dev, snd_soc_register_card failed (%d)\n, ret);
+ return ret;
+ }
devm_snd_soc_register_card().
signature.asc
Description: Digital signature
Re: [PATCH 4/4] mcpm: exynos: populate suspend and powered_up callbacks
On 04/21/2014 01:49 PM, Chander Kashyap wrote:
In order to support cpuidle through mcpm, suspend and powered-up
callbacks are required in mcpm platform code.
Hence populate the same callbacks.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
Signed-off-by: Chander Kashyap k.chan...@samsung.com
---
arch/arm/mach-exynos/mcpm-exynos.c | 53
1 file changed, 53 insertions(+)
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
b/arch/arm/mach-exynos/mcpm-exynos.c
index 46d4968..16af0bd 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -318,10 +318,63 @@ static int exynos_power_down_finish(unsigned int cpu,
unsigned int cluster)
return 0; /* success: the CPU is halted */
}
+static void enable_coherency(void)
+{
+ unsigned long v, u;
+
+ asm volatile(
+ mrc p15, 0, %0, c1, c0, 1\n
+ orr %0, %0, %2\n
+ ldr %1, [%3]\n
+ and %1, %1, #0\n
+ orr %0, %0, %1\n
+ mcr p15, 0, %0, c1, c0, 1\n
+ : =r (v), =r (u)
+ : Ir (0x40), Ir (S5P_INFORM0)
+ : cc);
+}
Shouldn't this function to be used from hotplug.c also ?
+
+void exynos_powered_up(void)
+{
+ unsigned int mpidr, cpu, cluster;
+
+ mpidr = read_cpuid_mpidr();
+ cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+ cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+ arch_spin_lock(bl_lock);
+ if (cpu_use_count[cpu][cluster] == 0)
+ cpu_use_count[cpu][cluster] = 1;
+ arch_spin_unlock(bl_lock);
+}
+
+static void exynos_suspend(u64 residency)
+{
+ unsigned int mpidr, cpunr;
+
+ mpidr = read_cpuid_mpidr();
+ cpunr = enynos_pmu_cpunr(mpidr);
*enynos*_pmu_cpunr ?
+
+ __raw_writel(virt_to_phys(mcpm_entry_point), REG_ENTRY_ADDR);
+
+ exynos_power_down();
+
+ /*
+* Execution reaches here only if cpu did not power down.
+* Hence roll back the changes done in exynos_power_down function.
+ */
+ __raw_writel(EXYNOS_CORE_LOCAL_PWR_EN,
+ EXYNOS_ARM_CORE_CONFIGURATION(cpunr));
Why don't you use the functions defined in the
patch 5/5 arm: exynos: Add MCPM call-back functions
exynos_core_power_control() ?
+ set_cr(get_cr() | CR_C);
+ enable_coherency();
+}
+
static const struct mcpm_platform_ops exynos_power_ops = {
.power_up = exynos_power_up,
.power_down = exynos_power_down,
.power_down_finish = exynos_power_down_finish,
+ .suspend= exynos_suspend,
+ .powered_up = exynos_powered_up,
};
static void __init exynos_mcpm_usage_count_init(void)
--
http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog
--
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 v3 5/5] regulator: tps65090: Make FETs more reliable by adding retries
On Tue, Apr 22, 2014 at 08:47:09AM +0100, Lee Jones wrote: If there are cross-subsystem dependencies I prefer to use immutable branches to eliminate any change of merge conflicts in -next or the next merge window. I'm happy to either create on with Mark's Acks, or receive a pull-request from Mark with mine applied. Up to Mark. Well, Doug didn't send me the MFD patch so I can't do anything with it anyway. signature.asc Description: Digital signature
[PATCH] [media] s5p-mfc: Add IOMMU support
The patch adds IOMMU support for MFC driver.
Signed-off-by: Arun Kumar K arun...@samsung.com
---
This patch is tested on IOMMU support series [1] posted
by KyonHo Cho.
[1] https://lkml.org/lkml/2014/3/14/9
---
drivers/media/platform/s5p-mfc/s5p_mfc.c | 33 ++
1 file changed, 33 insertions(+)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 89356ae..1f248ba 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -32,11 +32,18 @@
#include s5p_mfc_opr.h
#include s5p_mfc_cmd.h
#include s5p_mfc_pm.h
+#ifdef CONFIG_EXYNOS_IOMMU
+#include asm/dma-iommu.h
+#endif
#define S5P_MFC_NAME s5p-mfc
#define S5P_MFC_DEC_NAME s5p-mfc-dec
#define S5P_MFC_ENC_NAME s5p-mfc-enc
+#ifdef CONFIG_EXYNOS_IOMMU
+static struct dma_iommu_mapping *mapping;
+#endif
+
int debug;
module_param(debug, int, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(debug, Debug level - higher value produces more verbose
messages);
@@ -1013,6 +1020,23 @@ static void *mfc_get_drv_data(struct platform_device
*pdev);
static int s5p_mfc_alloc_memdevs(struct s5p_mfc_dev *dev)
{
+#ifdef CONFIG_EXYNOS_IOMMU
+ struct device *mdev = dev-plat_dev-dev;
+
+ mapping = arm_iommu_create_mapping(platform_bus_type, 0x2000,
+ SZ_256M);
+ if (mapping == NULL) {
+ mfc_err(IOMMU mapping failed\n);
+ return -EFAULT;
+ }
+ mdev-dma_parms = devm_kzalloc(dev-plat_dev-dev,
+ sizeof(*mdev-dma_parms), GFP_KERNEL);
+ dma_set_max_seg_size(mdev, 0xu);
+ arm_iommu_attach_device(mdev, mapping);
+
+ dev-mem_dev_l = dev-mem_dev_r = mdev;
+ return 0;
+#else
unsigned int mem_info[2] = { };
dev-mem_dev_l = devm_kzalloc(dev-plat_dev-dev,
@@ -1049,6 +1073,7 @@ static int s5p_mfc_alloc_memdevs(struct s5p_mfc_dev *dev)
return -ENOMEM;
}
return 0;
+#endif
}
/* MFC probe function */
@@ -1228,6 +1253,10 @@ err_mem_init_ctx_1:
vb2_dma_contig_cleanup_ctx(dev-alloc_ctx[0]);
err_res:
s5p_mfc_final_pm(dev);
+#ifdef CONFIG_EXYNOS_IOMMU
+ if (mapping)
+ arm_iommu_release_mapping(mapping);
+#endif
pr_debug(%s-- with error\n, __func__);
return ret;
@@ -1256,6 +1285,10 @@ static int s5p_mfc_remove(struct platform_device *pdev)
put_device(dev-mem_dev_r);
}
+#ifdef CONFIG_EXYNOS_IOMMU
+ if (mapping)
+ arm_iommu_release_mapping(mapping);
+#endif
s5p_mfc_final_pm(dev);
return 0;
}
--
1.7.9.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 2/4] driver: cpuidle: cpuidle-big-little: init driver for Exynos5420
On 04/21/2014 01:49 PM, Chander Kashyap wrote: Add samsung,exynos5420 compatible string to initialize generic big-little cpuidle driver for Exynos5420. Signed-off-by: Chander Kashyap chander.kash...@linaro.org Signed-off-by: Chander Kashyap k.chan...@samsung.org --- drivers/cpuidle/cpuidle-big_little.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/cpuidle/cpuidle-big_little.c b/drivers/cpuidle/cpuidle-big_little.c index b45fc62..d0fac53 100644 --- a/drivers/cpuidle/cpuidle-big_little.c +++ b/drivers/cpuidle/cpuidle-big_little.c @@ -170,7 +170,8 @@ static int __init bl_idle_init(void) /* * Initialize the driver just for a compliant set of machines */ - if (!of_machine_is_compatible(arm,vexpress,v2p-ca15_a7)) + if (!of_machine_is_compatible(arm,vexpress,v2p-ca15_a7) + (!of_machine_is_compatible(samsung,exynos5420))) return -ENODEV; /* * For now the differentiation between little and big cores BTW, are the latencies the same than the TC2 ? -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- 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 v6 1/2] phy: Add new Exynos5 USB 3.0 PHY driver
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.
Thereby, removing old phy-samsung-usb3 driver and related code
used untill now which was based on usb/phy framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
Mistakenly sent a WIP patchset in v5 version of this patch, that gives
build errors. So fixed those.
Changes from v5:
- Removed any mention about sclk_usbphy30* in the driver.
.../devicetree/bindings/phy/samsung-phy.txt| 40 ++
drivers/phy/Kconfig| 11 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos5-usbdrd.c | 626
4 files changed, 678 insertions(+)
create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index b422e38..51efe4c 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -114,3 +114,43 @@ Example:
compatible = samsung,exynos-sataphy-i2c;
reg = 0x38;
};
+
+Samsung Exynos5 SoC series USB DRD PHY controller
+--
+
+Required properties:
+- compatible : Should be set to one of the following supported values:
+ - samsung,exynos5250-usbdrd-phy - for exynos5250 SoC,
+ - samsung,exynos5420-usbdrd-phy - for exynos5420 SoC.
+- reg : Register offset and length of USB DRD PHY register set;
+- clocks: Clock IDs array as required by the controller
+- clock-names: names of clocks correseponding to IDs in the clock property;
+ Required clocks:
+ - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
+ used for register access.
+ - ref: PHY's reference clock (usually crystal clock), used for
+ PHY operations, associated by phy name. It is used to
+ determine bit values for clock settings register.
+ For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
+- samsung,pmu-syscon: phandle for PMU system controller interface, used to
+ control pmu registers for power isolation.
+- samsung,pmu-offset: phy power control register offset to
pmu-system-controller
+ base.
+- #phy-cells : from the generic PHY bindings, must be 1;
+
+For samsung,exynos5250-usbdrd-phy and samsung,exynos5420-usbdrd-phy
+compatible PHYs, the second cell in the PHY specifier identifies the
+PHY id, which is interpreted as follows:
+ 0 - UTMI+ type phy,
+ 1 - PIPE3 type phy,
+
+Example:
+ usb3_phy: usbphy@1210 {
+ compatible = samsung,exynos5250-usbdrd-phy;
+ reg = 0x1210 0x100;
+ clocks = clock 286, clock 1;
+ clock-names = phy, ref;
+ samsung,pmu-syscon = pmu_system_controller;
+ samsung,pmu-offset = 0x704;
+ #phy-cells = 1;
+ };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 3bb05f1..8a5d2b4 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -166,4 +166,15 @@ config PHY_XGENE
help
This option enables support for APM X-Gene SoC multi-purpose PHY.
+config PHY_EXYNOS5_USBDRD
+ tristate Exynos5 SoC series USB DRD PHY driver
+ depends on ARCH_EXYNOS5 OF
+ depends on HAS_IOMEM
+ select GENERIC_PHY
+ select MFD_SYSCON
+ help
+ Enable USB DRD PHY support for Exynos 5 SoC series.
+ This driver provides PHY interface for USB 3.0 DRD controller
+ present on Exynos5 SoC series.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 2faf78e..31baa0c 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_PHY_EXYNOS4210_USB2) += phy-exynos4210-usb2.o
obj-$(CONFIG_PHY_EXYNOS4X12_USB2) += phy-exynos4x12-usb2.o
obj-$(CONFIG_PHY_EXYNOS5250_USB2) += phy-exynos5250-usb2.o
obj-$(CONFIG_PHY_XGENE)+= phy-xgene.o
+obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
new file mode 100644
index 000..ca1f6ab
--- /dev/null
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -0,0 +1,626 @@
+/*
+ * Samsung EXYNOS5 SoC series USB DRD PHY driver
+ *
+ * Phy provider for USB 3.0 DRD controller on Exynos5 SoC series
+ *
+ * Copyright (C) 2014 Samsung Electronics Co., Ltd.
+ * Author: Vivek Gautam gautam.vi...@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.
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include
[PATCH v6 2/2] phy: exynos5-usbdrd: Add facility for VBUS supply
Adding support to enable/disable VBUS controlled by a
regulator, to enable vbus supply on the port.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
Mistakenly sent a WIP patchset in v5 version of this patch, that gives
build errors. So fixed those.
Changes from v5:
- Removed any mention about sclk_usbphy30* in the driver.
drivers/phy/phy-exynos5-usbdrd.c | 34 +-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index ca1f6ab..ad94c98 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -23,6 +23,7 @@
#include linux/mutex.h
#include linux/mfd/syscon.h
#include linux/regmap.h
+#include linux/regulator/consumer.h
/* Exynos USB PHY registers */
#define EXYNOS5_FSEL_9MHZ6 0x0
@@ -171,6 +172,7 @@ struct exynos5_usbdrd_phy {
unsigned int extrefclk;
struct clk *ref_clk;
unsigned long ref_rate;
+ struct regulator *vbus;
};
#define to_usbdrd_phy(inst) \
@@ -441,6 +443,7 @@ static int exynos5_usbdrd_phy_exit(struct phy *phy)
static int exynos5_usbdrd_phy_power_on(struct phy *phy)
{
+ int ret;
struct phy_usb_instance *inst = phy_get_drvdata(phy);
struct exynos5_usbdrd_phy *phy_drd = to_usbdrd_phy(inst);
@@ -448,10 +451,24 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
clk_prepare_enable(phy_drd-ref_clk);
+ /* Enable VBUS supply */
+ if (phy_drd-vbus) {
+ ret = regulator_enable(phy_drd-vbus);
+ if (ret) {
+ dev_err(phy_drd-dev, Failed to enable VBUS supply\n);
+ goto fail_vbus;
+ }
+ }
+
/* Power-on PHY*/
inst-phy_cfg-phy_isol(inst, 0);
return 0;
+
+fail_vbus:
+ clk_disable_unprepare(phy_drd-ref_clk);
+
+ return ret;
}
static int exynos5_usbdrd_phy_power_off(struct phy *phy)
@@ -464,6 +481,10 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
/* Power-off the PHY */
inst-phy_cfg-phy_isol(inst, 1);
+ /* Disable VBUS supply */
+ if (phy_drd-vbus)
+ regulator_disable(phy_drd-vbus);
+
clk_disable_unprepare(phy_drd-ref_clk);
return 0;
@@ -534,7 +555,7 @@ static int exynos5_usbdrd_phy_probe(struct platform_device
*pdev)
const struct exynos5_usbdrd_phy_drvdata *drv_data;
struct regmap *reg_pmu;
u32 pmu_offset;
- int i;
+ int i, ret;
phy_drd = devm_kzalloc(dev, sizeof(*phy_drd), GFP_KERNEL);
if (!phy_drd)
@@ -577,6 +598,17 @@ static int exynos5_usbdrd_phy_probe(struct platform_device
*pdev)
return PTR_ERR(reg_pmu);
}
+ /* Get required GPIO for vbus */
+ phy_drd-vbus = devm_regulator_get(dev, vbus);
+ if (IS_ERR(phy_drd-vbus)) {
+ ret = PTR_ERR(phy_drd-vbus);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+
+ dev_warn(dev, Failed to get VBUS supply regulator\n);
+ phy_drd-vbus = NULL;
+ }
+
if (of_property_read_u32(node, samsung,pmu-offset, pmu_offset)) {
dev_err(dev, Missing pmu-offset for phy isolation\n);
return -EINVAL;
--
1.7.10.4
--
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 3/3] drm/exynos: use pending_components for components tracking
On 04/18/2014 02:46 PM, Russell King - ARM Linux wrote: On Fri, Apr 18, 2014 at 02:02:37PM +0200, Andrzej Hajda wrote: Separation of the interfaces exposed by the device from the device itself seems to me a good thing. I would even consider it as a biggest advantage of this solution :) The problem of re-initialization does not seems to be relevant here, it is classic problem of coding correctness nothing more, it can appear here and in many different places. It may be a problem of coding correctless, but it's also a maintainability problem too - it makes it _much_ more difficult to ensure that everything is correct. But forcibly re-initializing all component devices instead of fixing bugs in specific drivers seems to be 'absolutely absurd' as classic says. Anyway it seems we have different point of view on the problem, your say about devices with two stage initialization. I see it more as devices registering interfaces and superdevice using it. Right, so please make this exynos-specific, because from what I can see it has no reason to pretend to be generic. As I've already pointed out, it can't be used in the general case because it ties sub-components directly to their main driver, which is absolutely absurd. Please keep this absurdness in exynos and don't spread it around. Thanks. As I wrote already, this framework was proposed for drivers which are tied together anyway, and this is case of many drivers, not only exynos. Standalone drivers were not at my sight but I have also described in other mail how the framework can be 'improved' to support standalone drivers also. Regards Andrzej -- 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 7/9] drm/bridge: ptn3460: add drm_panel controls
So what about, rather than adding drm_panel support to each bridge
individually, we introduce a drm_panel_bridge (with a form of
chaining).. ie:
struct drm_panel_bridge {
struct drm_bridge base;
struct drm_panel *panel;
struct drm_bridge *bridge; /* optional */
};
static void drm_panel_bridge_enable(struct drm_bridge *bridge)
{
struct drm_panel_bridge *pb = to_panel_bridge(bridge);
if (pb-bridge)
pb-bridge-funcs-enable(pb-bridge);
pb-panel-funcs-enable(pb-panel);
}
... and so on.
If you don't need a real bridge, just create one of these w/
pb-bridge==NULL, otherwise create it as a wrapper for your real
bridge.
BR,
-R
On Mon, Apr 21, 2014 at 6:39 PM, Ajay Kumar ajaykumar...@samsung.com wrote:
attach ptn3460 connector to drm_panel and support drm_panel routines,
if a valid drm_panel object is passed to ptn3460_init.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
Changes since V1:
Address few coding style comments from Jingoo Han
drivers/gpu/drm/bridge/Kconfig |1 +
drivers/gpu/drm/bridge/ptn3460.c| 20 +++-
drivers/gpu/drm/exynos/exynos_dp_core.c | 16
include/drm/bridge/ptn3460.h|6 --
4 files changed, 36 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 884923f..3bc6845 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -2,4 +2,5 @@ config DRM_PTN3460
tristate PTN3460 DP/LVDS bridge
depends on DRM
select DRM_KMS_HELPER
+ select DRM_PANEL
---help---
diff --git a/drivers/gpu/drm/bridge/ptn3460.c
b/drivers/gpu/drm/bridge/ptn3460.c
index f1d2afc..3920202 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -19,6 +19,7 @@
#include linux/i2c.h
#include linux/gpio.h
#include linux/delay.h
+#include drm/drm_panel.h
#include drmP.h
#include drm_edid.h
@@ -38,6 +39,7 @@ struct ptn3460_bridge {
struct i2c_client *client;
struct drm_encoder *encoder;
struct drm_bridge *bridge;
+ struct drm_panel *panel;
struct edid *edid;
int gpio_pd_n;
int gpio_rst_n;
@@ -126,6 +128,8 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
gpio_set_value(ptn_bridge-gpio_rst_n, 1);
}
+ drm_panel_pre_enable(ptn_bridge-panel);
+
/*
* There's a bug in the PTN chip where it falsely asserts hotplug
before
* it is fully functional. We're forced to wait for the maximum start
up
@@ -142,6 +146,10 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
static void ptn3460_enable(struct drm_bridge *bridge)
{
+ struct ptn3460_bridge *ptn_bridge = bridge-driver_private;
+
+ if (ptn_bridge-enabled)
+ drm_panel_enable(ptn_bridge-panel);
}
static void ptn3460_disable(struct drm_bridge *bridge)
@@ -153,6 +161,9 @@ static void ptn3460_disable(struct drm_bridge *bridge)
ptn_bridge-enabled = false;
+ drm_panel_disable(ptn_bridge-panel);
+ drm_panel_post_disable(ptn_bridge-panel);
+
if (gpio_is_valid(ptn_bridge-gpio_rst_n))
gpio_set_value(ptn_bridge-gpio_rst_n, 1);
@@ -198,6 +209,7 @@ int ptn3460_get_modes(struct drm_connector *connector)
power_off = !ptn_bridge-enabled;
ptn3460_pre_enable(ptn_bridge-bridge);
+ ptn3460_enable(ptn_bridge-bridge);
edid = kmalloc(EDID_LENGTH, GFP_KERNEL);
if (!edid) {
@@ -265,7 +277,8 @@ struct drm_connector_funcs ptn3460_connector_funcs = {
};
int ptn3460_init(struct drm_device *dev, struct drm_encoder *encoder,
- struct i2c_client *client, struct device_node *node)
+ struct i2c_client *client, struct device_node *node,
+ struct drm_panel *panel)
{
int ret;
struct drm_bridge *bridge;
@@ -324,6 +337,11 @@ int ptn3460_init(struct drm_device *dev, struct
drm_encoder *encoder,
goto err;
}
+ if (panel) {
+ ptn_bridge-panel = panel;
+ drm_panel_attach(ptn_bridge-panel, ptn_bridge-connector);
+ }
+
bridge-driver_private = ptn_bridge;
encoder-bridge = bridge;
ptn_bridge-connector.polled = DRM_CONNECTOR_POLL_HPD;
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index dbc5ccc..4853f31 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -989,13 +989,14 @@ static bool find_bridge(const char *compat, struct
bridge_init *bridge)
/* returns the number of bridges attached */
static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
- struct drm_encoder *encoder)
+ struct drm_encoder *encoder, struct
Re: [PATCH RFC 3/3] drm/exynos: use pending_components for components tracking
On Tue, Apr 22, 2014 at 01:29:54PM +0200, Andrzej Hajda wrote: On 04/18/2014 02:46 PM, Russell King - ARM Linux wrote: On Fri, Apr 18, 2014 at 02:02:37PM +0200, Andrzej Hajda wrote: Separation of the interfaces exposed by the device from the device itself seems to me a good thing. I would even consider it as a biggest advantage of this solution :) The problem of re-initialization does not seems to be relevant here, it is classic problem of coding correctness nothing more, it can appear here and in many different places. It may be a problem of coding correctless, but it's also a maintainability problem too - it makes it _much_ more difficult to ensure that everything is correct. But forcibly re-initializing all component devices instead of fixing bugs in specific drivers seems to be 'absolutely absurd' as classic says. They're *unnecessary* bugs that wouldn't even exist if it weren't for the forced-splitup of the initialisation into two separate parts that your approach mandates. Yes, I know that you're desperate to play that down, but you can't get away from this fact: your approach _forces_ a split up of the initialisation into dependent two stages and that fact _alone_ adds additional complexity, and along with that additional complexity comes more opportunity for bugs. Also with that additional complexity comes the need to perform more tests to find those bugs, and given that most people just say okay, it boots and seems to work, that's good enough for me there is a high possibility that these kinds of bugs will take a long time to find. As I wrote already, this framework was proposed for drivers which are tied together anyway, and this is case of many drivers, not only exynos. Please name them. Standalone drivers were not at my sight but I have also described in other mail how the framework can be 'improved' to support standalone drivers also. At the moment, I don't see a justification for your simplified and restrictive solution, which if used will lock drivers into that simplisitic method, and which can't ever be extended without lots of ifdeffery to having other components (such as TDA998x) attached. My objections are entirely based on where imx-drm and armada DRM are going, neither of which could ever use your implementation. Before you say that it isn't meant to deal with stuff like the TDA998x, take a moment to think about this - the Dove video subsystem was designed to support OLPC. It was primerly designed to drive a LCD screen plus an on-board VGA DAC. Everything for that is on-SoC. With that, the hardware is well known, and your solution could be used. However, then SolidRun came along and dropped a TDA998x on the LCD output pins. Suddenly, things aren't that simple, and your solution falls apart, because it can't cope with a generic component that has no knowledge of the rest of its master. This kind of scenario can happen /any/ time, and any time it does happen, your simple solution falls apart. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- 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] [media] s5p-mfc: Add IOMMU support
Hi Arun,
Thank you for the patch.
On Tuesday 22 April 2014 16:32:48 Arun Kumar K wrote:
The patch adds IOMMU support for MFC driver.
I've been working on an IOMMU driver lately, which led me to think about how
drivers should be interfaced with IOMMUs. Runtime IOMMU handling is performed
by the DMA mapping API, but in many cases (including Exynos platforms) the
arm_iommu_create_mapping() and arm_iommu_attach_device() functions still need
to be called explicitly by drivers, which doesn't seem a very good idea to me.
Ideally IOMMU usage should be completely transparent for bus master drivers,
without requiring any driver modification to use the IOMMU.
What would you think about improving the Exynos IOMMU driver to create the
mapping and attach the device instead of having to modify all bus master
drivers ? See the ipmmu_add_device() function in
http://www.spinics.net/lists/linux-sh/msg30488.html for a possible
implementation.
Signed-off-by: Arun Kumar K arun...@samsung.com
---
This patch is tested on IOMMU support series [1] posted
by KyonHo Cho.
[1] https://lkml.org/lkml/2014/3/14/9
---
drivers/media/platform/s5p-mfc/s5p_mfc.c | 33 +++
1 file changed, 33 insertions(+)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c index 89356ae..1f248ba 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -32,11 +32,18 @@
#include s5p_mfc_opr.h
#include s5p_mfc_cmd.h
#include s5p_mfc_pm.h
+#ifdef CONFIG_EXYNOS_IOMMU
+#include asm/dma-iommu.h
+#endif
#define S5P_MFC_NAME s5p-mfc
#define S5P_MFC_DEC_NAME s5p-mfc-dec
#define S5P_MFC_ENC_NAME s5p-mfc-enc
+#ifdef CONFIG_EXYNOS_IOMMU
+static struct dma_iommu_mapping *mapping;
+#endif
+
int debug;
module_param(debug, int, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(debug, Debug level - higher value produces more verbose
messages); @@ -1013,6 +1020,23 @@ static void *mfc_get_drv_data(struct
platform_device *pdev);
static int s5p_mfc_alloc_memdevs(struct s5p_mfc_dev *dev)
{
+#ifdef CONFIG_EXYNOS_IOMMU
+ struct device *mdev = dev-plat_dev-dev;
+
+ mapping = arm_iommu_create_mapping(platform_bus_type, 0x2000,
+ SZ_256M);
+ if (mapping == NULL) {
+ mfc_err(IOMMU mapping failed\n);
+ return -EFAULT;
+ }
+ mdev-dma_parms = devm_kzalloc(dev-plat_dev-dev,
+ sizeof(*mdev-dma_parms), GFP_KERNEL);
+ dma_set_max_seg_size(mdev, 0xu);
+ arm_iommu_attach_device(mdev, mapping);
+
+ dev-mem_dev_l = dev-mem_dev_r = mdev;
+ return 0;
+#else
unsigned int mem_info[2] = { };
dev-mem_dev_l = devm_kzalloc(dev-plat_dev-dev,
@@ -1049,6 +1073,7 @@ static int s5p_mfc_alloc_memdevs(struct s5p_mfc_dev
*dev) return -ENOMEM;
}
return 0;
+#endif
}
/* MFC probe function */
@@ -1228,6 +1253,10 @@ err_mem_init_ctx_1:
vb2_dma_contig_cleanup_ctx(dev-alloc_ctx[0]);
err_res:
s5p_mfc_final_pm(dev);
+#ifdef CONFIG_EXYNOS_IOMMU
+ if (mapping)
+ arm_iommu_release_mapping(mapping);
+#endif
pr_debug(%s-- with error\n, __func__);
return ret;
@@ -1256,6 +1285,10 @@ static int s5p_mfc_remove(struct platform_device
*pdev) put_device(dev-mem_dev_r);
}
+#ifdef CONFIG_EXYNOS_IOMMU
+ if (mapping)
+ arm_iommu_release_mapping(mapping);
+#endif
s5p_mfc_final_pm(dev);
return 0;
}
--
Regards,
Laurent Pinchart
--
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: [RFC v2 PATCH 02/14] drm/exynos: dsi: delay setting clocks after reset
Hi YoungJun,
On 04/21/2014 02:28 PM, YoungJun Cho wrote:
Some phy control registers are not kept after software reset.
So this patch makes the clocks containing phy control to be set
after software reset.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 956e5f3..2cf1f0b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -946,10 +946,10 @@ static irqreturn_t exynos_dsi_irq(int irq, void *dev_id)
static int exynos_dsi_init(struct exynos_dsi *dsi)
{
- exynos_dsi_enable_clock(dsi);
exynos_dsi_reset(dsi);
enable_irq(dsi-irq);
exynos_dsi_wait_for_reset(dsi);
+ exynos_dsi_enable_clock(dsi);
exynos_dsi_init_link(dsi);
return 0;
I have commented it in the previous version of the patchset. I repeat it
again.
This is a regression, on exynos4210-trats I have 'timeout waiting for
reset' message after dpms off, on.
I will comment your previous answer here to make the discussion easier:
As I mentioned in description, it came from phy control registers.
Fortunately Exynos4 SoCs are safe, but the DSIM_PHYCTRL_REG,
DSIM_PHYTIMING_REG, DSIM_PHYTIMING1_REG and DSIM_PHYTIMING2_REG are
affected which are used in exynos_dsi_set_pll() for Exynos5 SoCs.
So this patch is required for Exynos5 SoCs.
In the moment this patch is applied exynos_dsi_set_pll do not touch phy
registers you have mentioned.
Your change would be more clear if it will be merged together with the
patch adding PHYCTRL settings.
Anyway, solution is simple - please set PHY registers after reset and
configure clocks before reset to avoid
reset timeouts, is there any reason to not do it this way?
Regards
Andrzej
--
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] [media] s5p-mfc: Add IOMMU support
Hi Laurent,
Thank you for the review.
On Tue, Apr 22, 2014 at 5:23 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi Arun,
Thank you for the patch.
On Tuesday 22 April 2014 16:32:48 Arun Kumar K wrote:
The patch adds IOMMU support for MFC driver.
I've been working on an IOMMU driver lately, which led me to think about how
drivers should be interfaced with IOMMUs. Runtime IOMMU handling is performed
by the DMA mapping API, but in many cases (including Exynos platforms) the
arm_iommu_create_mapping() and arm_iommu_attach_device() functions still need
to be called explicitly by drivers, which doesn't seem a very good idea to me.
Ideally IOMMU usage should be completely transparent for bus master drivers,
without requiring any driver modification to use the IOMMU.
What would you think about improving the Exynos IOMMU driver to create the
mapping and attach the device instead of having to modify all bus master
drivers ? See the ipmmu_add_device() function in
http://www.spinics.net/lists/linux-sh/msg30488.html for a possible
implementation.
Yes that would be a better solution. But as far as I know, exynos platforms has
few more complications where multiple IOMMUs are present for single IP.
The exynos iommu work is still under progress and KyonHo Cho will have
some inputs / comments on this. This seems to me a valid usecase which can
be considered for exynos iommu also.
Regards
Arun
Signed-off-by: Arun Kumar K arun...@samsung.com
---
This patch is tested on IOMMU support series [1] posted
by KyonHo Cho.
[1] https://lkml.org/lkml/2014/3/14/9
---
drivers/media/platform/s5p-mfc/s5p_mfc.c | 33 +++
1 file changed, 33 insertions(+)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c index 89356ae..1f248ba 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -32,11 +32,18 @@
#include s5p_mfc_opr.h
#include s5p_mfc_cmd.h
#include s5p_mfc_pm.h
+#ifdef CONFIG_EXYNOS_IOMMU
+#include asm/dma-iommu.h
+#endif
#define S5P_MFC_NAME s5p-mfc
#define S5P_MFC_DEC_NAME s5p-mfc-dec
#define S5P_MFC_ENC_NAME s5p-mfc-enc
+#ifdef CONFIG_EXYNOS_IOMMU
+static struct dma_iommu_mapping *mapping;
+#endif
+
int debug;
module_param(debug, int, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(debug, Debug level - higher value produces more verbose
messages); @@ -1013,6 +1020,23 @@ static void *mfc_get_drv_data(struct
platform_device *pdev);
static int s5p_mfc_alloc_memdevs(struct s5p_mfc_dev *dev)
{
+#ifdef CONFIG_EXYNOS_IOMMU
+ struct device *mdev = dev-plat_dev-dev;
+
+ mapping = arm_iommu_create_mapping(platform_bus_type, 0x2000,
+ SZ_256M);
+ if (mapping == NULL) {
+ mfc_err(IOMMU mapping failed\n);
+ return -EFAULT;
+ }
+ mdev-dma_parms = devm_kzalloc(dev-plat_dev-dev,
+ sizeof(*mdev-dma_parms), GFP_KERNEL);
+ dma_set_max_seg_size(mdev, 0xu);
+ arm_iommu_attach_device(mdev, mapping);
+
+ dev-mem_dev_l = dev-mem_dev_r = mdev;
+ return 0;
+#else
unsigned int mem_info[2] = { };
dev-mem_dev_l = devm_kzalloc(dev-plat_dev-dev,
@@ -1049,6 +1073,7 @@ static int s5p_mfc_alloc_memdevs(struct s5p_mfc_dev
*dev) return -ENOMEM;
}
return 0;
+#endif
}
/* MFC probe function */
@@ -1228,6 +1253,10 @@ err_mem_init_ctx_1:
vb2_dma_contig_cleanup_ctx(dev-alloc_ctx[0]);
err_res:
s5p_mfc_final_pm(dev);
+#ifdef CONFIG_EXYNOS_IOMMU
+ if (mapping)
+ arm_iommu_release_mapping(mapping);
+#endif
pr_debug(%s-- with error\n, __func__);
return ret;
@@ -1256,6 +1285,10 @@ static int s5p_mfc_remove(struct platform_device
*pdev) put_device(dev-mem_dev_r);
}
+#ifdef CONFIG_EXYNOS_IOMMU
+ if (mapping)
+ arm_iommu_release_mapping(mapping);
+#endif
s5p_mfc_final_pm(dev);
return 0;
}
--
Regards,
Laurent Pinchart
--
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 v5] arm: exynos: generalize power register address calculation
Currently status/configuration power register values are hard-coded for cpu1.
Make it generic so that it is useful for SoC's with more than two cpus.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
Signed-off-by: Chander Kashyap k.chan...@samsung.com
---
changes in v5:
1. Fix typo: enynos_pmu_cpunr - exynos_pmu_cpunr
changes in v4:
1: Dropped changes in platsmp.c and hotplug.c as those are taken care by
Tomasz Patches.
2. Converted ENYNOS_PMU_CPUNR macro to static inline function
changes in v3:
1. Move cpunr calculation to a macro
2. Changed printk format specifier from unsigned hex to unsigned decimal
Changes in v2:
1. Used existing macros for clusterid and cpuid calculation
arch/arm/mach-exynos/regs-pmu.h | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index 4f6a256..f39e78c 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -105,8 +105,13 @@
#define S5P_GPS_LOWPWR S5P_PMUREG(0x139C)
#define S5P_GPS_ALIVE_LOWPWR S5P_PMUREG(0x13A0)
-#define S5P_ARM_CORE1_CONFIGURATIONS5P_PMUREG(0x2080)
-#define S5P_ARM_CORE1_STATUS S5P_PMUREG(0x2084)
+#define S5P_ARM_CORE0_CONFIGURATIONS5P_PMUREG(0x2000)
+#define S5P_ARM_CORE0_STATUS S5P_PMUREG(0x2004)
+
+#define S5P_ARM_CORE_CONFIGURATION(_cpunr) \
+ (S5P_ARM_CORE0_CONFIGURATION + 0x80 * (_cpunr))
+#define S5P_ARM_CORE_STATUS(_cpunr) \
+ (S5P_ARM_CORE0_STATUS + 0x80 * (_cpunr))
#define S5P_PAD_RET_MAUDIO_OPTION S5P_PMUREG(0x3028)
#define S5P_PAD_RET_GPIO_OPTIONS5P_PMUREG(0x3108)
@@ -313,4 +318,13 @@
#define EXYNOS5_OPTION_USE_RETENTION (1 4)
+#include asm/cputype.h
+#define MAX_CPUS_IN_CLUSTER4
+
+static inline unsigned int exynos_pmu_cpunr(unsigned int mpidr)
+{
+ return ((MPIDR_AFFINITY_LEVEL(mpidr, 1) * MAX_CPUS_IN_CLUSTER)
++ MPIDR_AFFINITY_LEVEL(mpidr, 0));
+}
+
#endif /* __ASM_ARCH_REGS_PMU_H */
--
1.7.9.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 v11 12/27] ARM: dts: Add description of System MMU of Exynos SoCs
On Sun, 20 Apr 2014 15:25:59 +0530, Shaik Ameer Basha wrote:
Hi KyongHo Cho,
Please find the comments inline.
On Fri, Mar 14, 2014 at 10:36 AM, Cho KyongHo pullip@samsung.com wrote:
This patch adds dts entries for the System MMU devices found on
Exynos4 and Exynos5 SoC series and the System MMU binding
documentation.
CC: Rob Herring robherri...@gmail.com
CC: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Cho KyongHo pullip@samsung.com
---
.../bindings/iommu/samsung,exynos4210-sysmmu.txt | 86 +++
arch/arm/boot/dts/exynos4.dtsi | 107
arch/arm/boot/dts/exynos4210.dtsi | 23 +-
arch/arm/boot/dts/exynos4x12.dtsi | 77 +-
arch/arm/boot/dts/exynos5250.dtsi | 266
+++-
arch/arm/boot/dts/exynos5420.dtsi | 205 ++-
6 files changed, 758 insertions(+), 6 deletions(-)
create mode 100644
Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
diff --git
a/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
new file mode 100644
index 000..e4417bb
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
@@ -0,0 +1,86 @@
+Samsung Exynos IOMMU H/W, System MMU (System Memory Management Unit)
+
+Samsung's Exynos architecture contains System MMUs that enables scattered
+physical memory chunks visible as a contiguous region to DMA-capable
peripheral
+devices like MFC, FIMC, FIMD, GScaler, FIMC-IS and so forth.
+
[snip]
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 8f6300f..df336ea 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -80,6 +80,16 @@
reg = 0x10044040 0x20;
};
+ pd_isp: isp-power-domain@0x10044020 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x10044020 0x20;
+ };
+
+ pd_disp1: disp1-power-domain@0x100440A0 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x100440A0 0x20;
+ };
+
clock: clock-controller@1001 {
compatible = samsung,exynos5250-clock;
reg = 0x1001 0x3;
@@ -679,7 +689,7 @@
sclk_hdmiphy, mout_hdmi;
};
- mixer {
+ mixer: mixer {
compatible = samsung,exynos5250-mixer;
reg = 0x1445 0x1;
interrupts = 0 94 0;
@@ -700,7 +710,7 @@
phy-names = dp;
};
- fimd@1440 {
+ fimd: fimd@1440 {
clocks = clock 133, clock 339;
clock-names = sclk_fimd, fimd;
};
@@ -715,4 +725,256 @@
io-channel-ranges;
status = disabled;
};
+
+ sysmmu_g2d: sysmmu@10A6 {
+ compatible = samsung,sysmmu-v1;
+ reg = 0x10A6 0x1000;
+ interrupt-parent = combiner;
+ interrupts = 24 5;
+ clock-names = sysmmu;
+ clocks = clock 361;
+ };
+
+ sysmmu_mfc_r: sysmmu@1120 {
+ compatible = samsung,sysmmu-v2;
+ reg = 0x1120 0x1000;
+ interrupt-parent = combiner;
+ interrupts = 6 2;
+ clock-names = sysmmu, master;
+ clocks = clock 268, clock 266;
Add mmu-masters...
mmu-masters = mfc;
Ok.
+ samsung,power-domain = pd_mfc;
+ };
+
+ sysmmu_mfc_l: sysmmu@1121 {
+ compatible = samsung,sysmmu-v2;
+ reg = 0x1121 0x1000;
+ interrupt-parent = combiner;
+ interrupts = 8 5;
+ clock-names = sysmmu, master;
+ clocks = clock 267, clock 266;
Add mmu-masters...
mmu-masters = mfc;
OK.
+ samsung,power-domain = pd_mfc;
+ };
+
+ sysmmu_rotator: sysmmu@11D4 {
+ compatible = samsung,sysmmu-v1;
+ reg = 0x11D4 0x1000;
+ interrupt-parent = combiner;
+ interrupts = 4 0;
+ clock-names = sysmmu;
+ clocks = clock 272;
+ };
+
[snip]
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 45e2e65..a736f09 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -470,7 +470,7 @@
phy-names = dp;
};
- fimd@1440 {
+ fimd: fimd@1440 {
Re: [PATCH v2 1/2] v4l: Add resolution change event.
On 04/21/2014 10:59 PM, Laurent Pinchart wrote:
Hi Arun,
On Monday 21 April 2014 17:19:26 Arun Kumar K wrote:
On Mon, Apr 21, 2014 at 3:54 PM, Laurent Pinchart wrote:
On Monday 21 April 2014 14:56:01 Arun Kumar K wrote:
From: Pawel Osciak posc...@chromium.org
This event indicates that the decoder has reached a point in the stream,
at which the resolution changes. The userspace is expected to provide a
new
set of CAPTURE buffers for the new format before decoding can continue.
The event can also be used for more generic events involving resolution
or format changes at runtime for all kinds of video devices.
Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Arun Kumar K arun...@samsung.com
---
.../DocBook/media/v4l/vidioc-subscribe-event.xml | 16
include/uapi/linux/videodev2.h |6 ++
2 files changed, 22 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml index
5c70b61..0aec831 100644
--- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
@@ -155,6 +155,22 @@
/entry
/row
row
+ entryconstantV4L2_EVENT_SOURCE_CHANGE/constant/entry
+ entry5/entry
+ entry
+ paraThis event is triggered when a resolution or format
change +is detected during runtime by the video device. It
can be a +runtime resolution change triggered by a video
decoder or the +format change happening on an HDMI
connector. Application may +need to reinitialize buffers
before proceeding further./para +
+ paraThis event has a v4l2-event-source-change;
associated
+ with it. This has significance only for v4l2 subdevs where
the
+ structfieldpad_num/structfield field will be updated with
+ the pad number on which the event is triggered./para
+ /entry
+ /row
+ row
entryconstantV4L2_EVENT_PRIVATE_START/constant/entry
entry0x0800/entry
entryBase event number for driver-private events./entry
diff --git a/include/uapi/linux/videodev2.h
b/include/uapi/linux/videodev2.h index 6ae7bbe..12e0614 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1733,6 +1733,7 @@ struct v4l2_streamparm {
#define V4L2_EVENT_EOS 2
#define V4L2_EVENT_CTRL 3
#define V4L2_EVENT_FRAME_SYNC4
+#define V4L2_EVENT_SOURCE_CHANGE 5
#define V4L2_EVENT_PRIVATE_START 0x0800
/* Payload for V4L2_EVENT_VSYNC */
@@ -1764,12 +1765,17 @@ struct v4l2_event_frame_sync {
__u32 frame_sequence;
};
+struct v4l2_event_source_change {
+ __u32 pad_num;
I would call the field just pad,
Ok.
+};
+
struct v4l2_event {
__u32 type;
union {
struct v4l2_event_vsync vsync;
struct v4l2_event_ctrl ctrl;
struct v4l2_event_frame_syncframe_sync;
+ struct v4l2_event_source_change source_change;
__u8data[64];
This looks pretty good to me, but I'm a bit concerned about future
compatibility. We might need to report more information to userspace, and
in particular what has been changed at the source (resolution, format,
...). In order to do so, we'll need to add a flag field to
v4l2_event_source_change.
Ok a flag can be added with bitfields for reporting specific event type.
I don't think we need to add it now. Just making sure it can be added later
without breaking the userspace API would be enough for me.
I would add it, I think it makes sense. It would be similar to the 'changes'
field in struct v4l2_event_ctrl.
The next __u32 right after the source_change field must thus be zeroed. I
see two ways of doing so:
- zeroing the whole data array before setting event-specific data
- adding a reserved must-be-zeroed field to v4l2_event_source_change
I like the former better as it's more generic, but we then need to ensure
that all drivers zero the whole data field correctly. Adding a new
v4l2_event_init() function would help with that.
Is that a good idea to have an init() function just for zeroing the data
field? If this is agreed upon, I can add this, but it can be easily missed
out by drivers.
I'm not sure. On one hand it would be easier to catch missing calls if we use
a dedicated function, as the function could set an initialized flag in the
event structure that would be checked by v4l2_event_queue. On the other hand,
that might be overengineering, and we could just manually check that all
drivers memset the structure to 0 before initializing fields. In
Re: [PATCH v2 1/2] v4l: Add resolution change event.
On 04/21/2014 11:26 AM, Arun Kumar K wrote:
From: Pawel Osciak posc...@chromium.org
This event indicates that the decoder has reached a point in the stream,
at which the resolution changes. The userspace is expected to provide a new
set of CAPTURE buffers for the new format before decoding can continue.
The event can also be used for more generic events involving resolution
or format changes at runtime for all kinds of video devices.
Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Arun Kumar K arun...@samsung.com
---
.../DocBook/media/v4l/vidioc-subscribe-event.xml | 16
include/uapi/linux/videodev2.h |6 ++
2 files changed, 22 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
index 5c70b61..0aec831 100644
--- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
@@ -155,6 +155,22 @@
/entry
/row
row
+ entryconstantV4L2_EVENT_SOURCE_CHANGE/constant/entry
+ entry5/entry
+ entry
+ paraThis event is triggered when a resolution or format change
+is detected during runtime by the video device. It can be a
+runtime resolution change triggered by a video decoder or the
+format change happening on an HDMI connector. Application may
+need to reinitialize buffers before proceeding further./para
+
+ paraThis event has a v4l2-event-source-change; associated
+ with it. This has significance only for v4l2 subdevs where the
+ structfieldpad_num/structfield field will be updated with
+ the pad number on which the event is triggered./para
+ /entry
+ /row
+ row
entryconstantV4L2_EVENT_PRIVATE_START/constant/entry
entry0x0800/entry
entryBase event number for driver-private events./entry
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 6ae7bbe..12e0614 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1733,6 +1733,7 @@ struct v4l2_streamparm {
#define V4L2_EVENT_EOS 2
#define V4L2_EVENT_CTRL 3
#define V4L2_EVENT_FRAME_SYNC4
+#define V4L2_EVENT_SOURCE_CHANGE 5
#define V4L2_EVENT_PRIVATE_START 0x0800
/* Payload for V4L2_EVENT_VSYNC */
@@ -1764,12 +1765,17 @@ struct v4l2_event_frame_sync {
__u32 frame_sequence;
};
+struct v4l2_event_source_change {
+ __u32 pad_num;
+};
+
struct v4l2_event {
__u32 type;
union {
struct v4l2_event_vsync vsync;
struct v4l2_event_ctrl ctrl;
struct v4l2_event_frame_syncframe_sync;
+ struct v4l2_event_source_change source_change;
__u8data[64];
} u;
__u32 pending;
This needs to be done differently. The problem is that you really have multiple
events that you want to subscribe to: one for each pad (or input: see the way
VIDIOC_G/S_EDID maps pad to an input or output index when used with a video
node,
we have to support that for this event as well).
What you want to do is similar to what is done for control events: there you can
subscribe for a specific control and get notified when that control changes.
The way that works in the event code is that the 'id' field in the v4l2_event
struct contains that control ID, or, in this case, the pad/input/output index.
In the application you will subscribe to the SOURCE_CHANGE event for a specific
pad/input/output index.
In other words, the pad_num field should be dropped and the id field used
instead.
Assuming we will also add a 'changes' field (see my reply to the other post
on that topic), then you should also provide replace and merge ops (see
v4l2-ctrls.c). That way it is sufficient to use just one element when calling
v4l2_event_subscribe(): you will never loose information since if multiple
events arrive before the application can dequeue them, the 'changes' information
will be the ORed value of all those intermediate events.
It's all more work, but it is critical to ensure that the application never
misses events.
Regards,
Hans
--
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 v2] ARM: dts: disable MDMA1 node for Exynos5420
This change places MDMA1 in disabled node for Exynos5420.
If MDMA1 region is configured with secure mode, it makes
the boot failure with the following on smdk5420 board.
(Unhandled fault: imprecise external abort (0x1406) at 0x)
Thus, arndale-octa board don't need to do the same thing anymore.
Signed-off-by: Seungwon Jeon tgih@samsung.com
---
Note: This patch comes from [PATCH] ARM: dts: disable MDMA1 node for smdk5420
board
arch/arm/boot/dts/exynos5420-arndale-octa.dts | 12
arch/arm/boot/dts/exynos5420.dtsi |7 +++
2 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index 80a3bf4..896a2a6 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -364,16 +364,4 @@
gpio-key,wakeup;
};
};
-
- amba {
- mdma1: mdma@11C1 {
- /*
-* MDMA1 can support both secure and non-secure
-* AXI transactions. When this is enabled in the kernel
-* for boards that run in secure mode, we are getting
-* imprecise external aborts causing the kernel to oops.
-*/
- status = disabled;
- };
- };
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index c3a9a66..97cbcdd 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -336,6 +336,13 @@
#dma-cells = 1;
#dma-channels = 8;
#dma-requests = 1;
+ /*
+* MDMA1 can support both secure and non-secure
+* AXI transactions. When this is enabled in the kernel
+* for boards that run in secure mode, we are getting
+* imprecise external aborts causing the kernel to oops.
+*/
+ status = disabled;
};
};
--
1.7.0.4
--
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 v11 20/27] iommu/exynos: allow having multiple System MMUs for a master H/W
Hi KyongHo Cho,
On Fri, Mar 14, 2014 at 10:40 AM, Cho KyongHo pullip@samsung.com wrote:
Some master device descriptor like fimc-is which is an abstraction
of very complex H/W may have multiple System MMUs. For those devices,
the design of the link between System MMU and its master H/W is needed
to be reconsidered.
A link structure, sysmmu_list_data is introduced that provides a link
to master H/W and that has a pointer to the device descriptor of a
System MMU. Given a device descriptor of a master H/W, it is possible
to traverse all System MMUs that must be controlled along with the
master H/W.
Signed-off-by: Cho KyongHo pullip@samsung.com
---
drivers/iommu/exynos-iommu.c | 534
++
1 file changed, 333 insertions(+), 201 deletions(-)
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 84ba29a..7489343 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -128,6 +128,10 @@
#define __master_clk_disable(data) __clk_gate_ctrl(data, clk_master, dis)
[snip]
+static int __init __sysmmu_init_master(struct device *dev)
+{
+ int ret;
+ int i = 0;
+ struct device_node *node;
+
+ while ((node = of_parse_phandle(dev-of_node, mmu-masters, i++))) {
struct platform_device *master = of_find_device_by_node(node);
+ struct exynos_iommu_owner *owner;
+ struct sysmmu_list_data *list_data;
if (!master) {
dev_err(dev, %s: mmu-master '%s' not found\n,
__func__, node-name);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err;
}
- if (master-dev.archdata.iommu != NULL) {
- dev_err(dev, %s: '%s' is master of other MMU\n,
- __func__, node-name);
- return -EINVAL;
+ owner = master-dev.archdata.iommu;
+ if (!owner) {
+ owner = devm_kzalloc(dev, sizeof(*owner), GFP_KERNEL);
+ if (!owner) {
+ dev_err(dev,
+ %s: Failed to allocate owner structure\n,
+ __func__);
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ INIT_LIST_HEAD(owner-mmu_list);
+ INIT_LIST_HEAD(owner-client);
+ owner-dev = master-dev;
+ spin_lock_init(owner-lock);
+
+ master-dev.archdata.iommu = owner;
}
+ list_data = devm_kzalloc(dev, sizeof(*list_data), GFP_KERNEL);
+ if (!list_data) {
+ dev_err(dev,
+ %s: Failed to allocate sysmmu_list_data\n,
+ __func__);
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ INIT_LIST_HEAD(list_data-entry);
+ list_data-sysmmu = dev;
+
/*
-* archdata.iommu will be initialized with exynos_iommu_client
-* in sysmmu_hook_driver_register().
+* System MMUs are attached in the order of the presence
+* in device tree
*/
- master-dev.archdata.iommu = dev;
+ list_add_tail(list_data-entry, owner-mmu_list);
}
- data-sysmmu = dev;
- rwlock_init(data-lock);
+ return 0;
+err:
+ while ((node = of_parse_phandle(dev-of_node, mmu-masters, i++))) {
Don't we need to reinitialize variable 'i' here before using?
i = 0;
Regards,
Shaik Ameer Basha
+ struct platform_device *master = of_find_device_by_node(node);
+ struct exynos_iommu_owner *owner;
+ struct sysmmu_list_data *list_data;
- platform_set_drvdata(pdev, data);
+ if (!master)
+ continue;
- pm_runtime_enable(dev);
- data-runtime_active = !pm_runtime_enabled(dev);
+ owner = master-dev.archdata.iommu;
+ if (!owner)
+ continue;
- dev_dbg(dev, Probed and initialized\n);
- return 0;
+ for_each_sysmmu_list(owner-dev, list_data) {
+ if (list_data-sysmmu == dev) {
+ list_del(list_data-entry);
+ kfree(list_data);
+ break;
+ }
+ }
+ }
+
+ return ret;
}
[snip]
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to
Re: [PATCH V2 8/9] drm/bridge: Add PS8622 bridge driver
On Mon, Apr 21, 2014 at 6:39 PM, Ajay Kumar ajaykumar...@samsung.com wrote:
This patch adds a drm_bridge driver for the PS8622 DisplayPort to LVDS
bridge chip.
Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Sean Paul seanp...@chromium.org
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Hi Ajay,
I don't think that you should be claiming authorship of this driver, I
don't see any commits from you in the chromium tree ([1] [2]). The
driver was originally written by vpala...@chromium.org (who's
completely missing from SoB), it should probably be attributed to him.
Sean
[1]-
https://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel-next.git;a=history;f=drivers/auxdisplay/ps8622.c;hb=fac579ad884d064d2c3cda988117e7dd66fc30c4
[2]-
https://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel-next.git;a=history;f=drivers/gpu/drm/bridge/ps8622.c;hb=refs/heads/chromeos-3.8
---
Changes since V1:
Pushing V1 for this as V2 because this patch holds good in this
series.
drivers/gpu/drm/bridge/Kconfig |7 +
drivers/gpu/drm/bridge/Makefile |1 +
drivers/gpu/drm/bridge/ps8622.c | 566
+++
include/drm/bridge/ps8622.h | 42 +++
4 files changed, 616 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/ps8622.c
create mode 100644 include/drm/bridge/ps8622.h
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3bc6845..aba21fc 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -4,3 +4,10 @@ config DRM_PTN3460
select DRM_KMS_HELPER
select DRM_PANEL
---help---
+
+config DRM_PS8622
+ tristate Parade eDP/LVDS bridge
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_PANEL
+ ---help---
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index b4733e1..d1b5daa 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,3 +1,4 @@
ccflags-y := -Iinclude/drm
obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
+obj-$(CONFIG_DRM_PS8622) += ps8622.o
diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
new file mode 100644
index 000..1e6b3ca
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ps8622.c
@@ -0,0 +1,566 @@
+/*
+ * Parade PS8622 eDP/LVDS bridge driver
+ *
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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 linux/module.h
+#include linux/backlight.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/fb.h
+#include linux/gpio.h
+#include linux/i2c.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include linux/pm.h
+#include linux/regulator/consumer.h
+#include drm/drm_panel.h
+
+#include drmP.h
+#include drm_crtc.h
+#include drm_crtc_helper.h
+
+struct ps8622_bridge {
+ struct drm_connector connector;
+ struct drm_bridge *bridge;
+ struct drm_encoder *encoder;
+ struct drm_panel *panel;
+ struct i2c_client *client;
+ struct regulator *v12;
+ struct backlight_device *bl;
+ struct mutex enable_mutex;
+
+ int gpio_slp_n;
+ int gpio_rst_n;
+
+ u8 max_lane_count;
+ u8 lane_count;
+
+ bool enabled;
+
+ struct drm_display_mode mode;
+};
+
+struct ps8622_device_data {
+ u8 max_lane_count;
+};
+
+static const struct ps8622_device_data ps8622_data = {
+ .max_lane_count = 1,
+};
+
+static const struct ps8622_device_data ps8625_data = {
+ .max_lane_count = 2,
+};
+
+/* Brightness scale on the Parade chip */
+#define PS8622_MAX_BRIGHTNESS 0xff
+
+/* Timings taken from the version 1.7 datasheet for the PS8622/PS8625 */
+#define PS8622_POWER_RISE_T1_MIN_US 10
+#define PS8622_POWER_RISE_T1_MAX_US 1
+#define PS8622_RST_HIGH_T2_MIN_US 3000
+#define PS8622_RST_HIGH_T2_MAX_US 3
+#define PS8622_PWMO_END_T12_MS 200
+#define PS8622_POWER_FALL_T16_MAX_US 1
+#define PS8622_POWER_OFF_T17_MS 500
+
+#if ((PS8622_RST_HIGH_T2_MIN_US + PS8622_POWER_RISE_T1_MAX_US) \
+ (PS8622_RST_HIGH_T2_MAX_US + PS8622_POWER_RISE_T1_MIN_US))
+#error T2.min + T1.max must be less than T2.max + T1.min
+#endif
+
+static int ps8622_set(struct i2c_client *client, u8 page, u8 reg, u8 val)
+{
+ int ret;
+ struct i2c_adapter *adap = client-adapter;
+ struct i2c_msg msg;
+ u8 data[] = {reg,
Re: [PATCH v2] ARM: dts: disable MDMA1 node for Exynos5420
On Tue, Apr 22, 2014 at 02:05:26PM +0100, Seungwon Jeon wrote: This change places MDMA1 in disabled node for Exynos5420. If MDMA1 region is configured with secure mode, it makes the boot failure with the following on smdk5420 board. (Unhandled fault: imprecise external abort (0x1406) at 0x) Thus, arndale-octa board don't need to do the same thing anymore. Signed-off-by: Seungwon Jeon tgih@samsung.com I've had some problem applying it (wrong EOL?). Not sure if it's my email client. In any case, I've manually fixed the rejects and tested it in my Arndale Octa. It works for me so Tested-by: Javi Merino javi.mer...@arm.com -- 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] ASoC: SAMSUNG: Add sound card driver for Snow board
On 22 April 2014 16:14, Mark Brown broo...@kernel.org wrote:
On Tue, Apr 22, 2014 at 01:33:54PM +0530, Tushar Behera wrote:
Added machine driver to instantiate I2S based sound card on Snow
board. It has MAX98095 audio codec on board.
In general this isn't up to modern standards, please do try to check
that new code is following best practices. Did the support for setting
the clocking up in the device tree get merged already?
I didn't get this point. Would you please elaborate?
Please do also pay attention to the CC lists when posting patches, this
seems to have been sent to a fairly random selection of people and
lists.
Okay, I will update the CC list as per get_maintainer script during
next revision.
+ switch (params_format(params)) {
params_width().
+ ret = snd_soc_dai_set_fmt(codec_dai, SND_SOC_DAIFMT_I2S |
+ SND_SOC_DAIFMT_NB_NF |
+ SND_SOC_DAIFMT_CBS_CFS);
Set this in the dai_link.
Ok.
However, setting this in dai_link is not working if I2S is running is
master mode. The bug is with I2S driver as it is setting rclk_srcrate
as 0 during startup. I will fix that in another patch.
+ ret = snd_soc_dai_set_sysclk(codec_dai, 0,
+ FIN_PLL_RATE, SND_SOC_CLOCK_IN);
+ if (ret 0)
+ return ret;
+
+ ret = snd_soc_dai_set_sysclk(cpu_dai, SAMSUNG_I2S_CDCLK,
+ 0, SND_SOC_CLOCK_OUT);
+ if (ret 0)
+ return ret;
+
+ ret = snd_soc_dai_set_clkdiv(cpu_dai, SAMSUNG_I2S_DIV_BCLK, bfs);
+ if (ret 0)
+ return ret;
Set this stuff up on probe. I'm surprised that you need to set BCLK at
all...
Should I create a late_probe call for this (in line with tobermory.c)?
Setting BCLK was an oversight, that is not required. I will remove that.
+static int snow_init(struct snd_soc_pcm_runtime *rtd)
+{
+ struct snd_soc_codec *codec = rtd-codec;
+ struct snd_soc_dapm_context *dapm = codec-dapm;
+
+ snd_soc_dapm_sync(dapm);
+
+ return 0;
+}
This does nothing, remove it.
Sure.
+ if (!pdev-dev.platform_data !pdev-dev.of_node) {
+ dev_err(pdev-dev, No platform data supplied\n);
+ return -EINVAL;
+ }
+
+ name = of_get_property(pdev-dev.of_node, card-name, NULL);
+ if (name)
+ card-name = name;
+
+ i2s_node = of_parse_phandle(pdev-dev.of_node,
+ samsung,i2s-controller, 0);
+ if (!i2s_node) {
+ dev_err(pdev-dev,
+ Property 'i2s-controller' missing or invalid\n);
+ return -EINVAL;
+ }
You're allowing platform data above but I see DT is mandatory here.
I will keep this as DT only, will remove the above check for platform data.
+ ret = snd_soc_register_card(card);
+ if (ret) {
+ dev_err(pdev-dev, snd_soc_register_card failed (%d)\n,
ret);
+ return ret;
+ }
devm_snd_soc_register_card().
Ok.
Thanks for reviewing.
--
Tushar Behera
--
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 7/9] drm/bridge: ptn3460: add drm_panel controls
On Tue, Apr 22, 2014 at 07:34:03AM -0400, Rob Clark wrote:
So what about, rather than adding drm_panel support to each bridge
individually, we introduce a drm_panel_bridge (with a form of
chaining).. ie:
struct drm_panel_bridge {
struct drm_bridge base;
struct drm_panel *panel;
struct drm_bridge *bridge; /* optional */
};
static void drm_panel_bridge_enable(struct drm_bridge *bridge)
{
struct drm_panel_bridge *pb = to_panel_bridge(bridge);
if (pb-bridge)
pb-bridge-funcs-enable(pb-bridge);
pb-panel-funcs-enable(pb-panel);
}
... and so on.
If you don't need a real bridge, just create one of these w/
pb-bridge==NULL, otherwise create it as a wrapper for your real
bridge.
Yeah I think that's how I'd have implemented some generic abstraction for
drivers using the crtc helpers. This allows you to keep bridge drivers,
panel drivers and anything else you might have in your driver to feed the
pixel stream to those 2 guys separate. And it also allows you to set it
all up in different ways, e.g. using device tree metadata, or acpi or some
other table hardcoded in a video rom somewhere.
Imo we also should have something similar to chain up drm_bridge devices.
tbh I'm not terribly happy about how the current integration with the crtc
modeset helpers is done ...
-Daniel
BR,
-R
On Mon, Apr 21, 2014 at 6:39 PM, Ajay Kumar ajaykumar...@samsung.com wrote:
attach ptn3460 connector to drm_panel and support drm_panel routines,
if a valid drm_panel object is passed to ptn3460_init.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
Changes since V1:
Address few coding style comments from Jingoo Han
drivers/gpu/drm/bridge/Kconfig |1 +
drivers/gpu/drm/bridge/ptn3460.c| 20 +++-
drivers/gpu/drm/exynos/exynos_dp_core.c | 16
include/drm/bridge/ptn3460.h|6 --
4 files changed, 36 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 884923f..3bc6845 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -2,4 +2,5 @@ config DRM_PTN3460
tristate PTN3460 DP/LVDS bridge
depends on DRM
select DRM_KMS_HELPER
+ select DRM_PANEL
---help---
diff --git a/drivers/gpu/drm/bridge/ptn3460.c
b/drivers/gpu/drm/bridge/ptn3460.c
index f1d2afc..3920202 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -19,6 +19,7 @@
#include linux/i2c.h
#include linux/gpio.h
#include linux/delay.h
+#include drm/drm_panel.h
#include drmP.h
#include drm_edid.h
@@ -38,6 +39,7 @@ struct ptn3460_bridge {
struct i2c_client *client;
struct drm_encoder *encoder;
struct drm_bridge *bridge;
+ struct drm_panel *panel;
struct edid *edid;
int gpio_pd_n;
int gpio_rst_n;
@@ -126,6 +128,8 @@ static void ptn3460_pre_enable(struct drm_bridge
*bridge)
gpio_set_value(ptn_bridge-gpio_rst_n, 1);
}
+ drm_panel_pre_enable(ptn_bridge-panel);
+
/*
* There's a bug in the PTN chip where it falsely asserts hotplug
before
* it is fully functional. We're forced to wait for the maximum
start up
@@ -142,6 +146,10 @@ static void ptn3460_pre_enable(struct drm_bridge
*bridge)
static void ptn3460_enable(struct drm_bridge *bridge)
{
+ struct ptn3460_bridge *ptn_bridge = bridge-driver_private;
+
+ if (ptn_bridge-enabled)
+ drm_panel_enable(ptn_bridge-panel);
}
static void ptn3460_disable(struct drm_bridge *bridge)
@@ -153,6 +161,9 @@ static void ptn3460_disable(struct drm_bridge *bridge)
ptn_bridge-enabled = false;
+ drm_panel_disable(ptn_bridge-panel);
+ drm_panel_post_disable(ptn_bridge-panel);
+
if (gpio_is_valid(ptn_bridge-gpio_rst_n))
gpio_set_value(ptn_bridge-gpio_rst_n, 1);
@@ -198,6 +209,7 @@ int ptn3460_get_modes(struct drm_connector *connector)
power_off = !ptn_bridge-enabled;
ptn3460_pre_enable(ptn_bridge-bridge);
+ ptn3460_enable(ptn_bridge-bridge);
edid = kmalloc(EDID_LENGTH, GFP_KERNEL);
if (!edid) {
@@ -265,7 +277,8 @@ struct drm_connector_funcs ptn3460_connector_funcs = {
};
int ptn3460_init(struct drm_device *dev, struct drm_encoder *encoder,
- struct i2c_client *client, struct device_node *node)
+ struct i2c_client *client, struct device_node *node,
+ struct drm_panel *panel)
{
int ret;
struct drm_bridge *bridge;
@@ -324,6 +337,11 @@ int ptn3460_init(struct drm_device *dev, struct
drm_encoder *encoder,
goto err;
}
+ if (panel) {
+
Re: [PATCH V2 8/9] drm/bridge: Add PS8622 bridge driver
Hi Sean,
On Tue, Apr 22, 2014 at 7:01 PM, Sean Paul seanp...@google.com wrote:
On Mon, Apr 21, 2014 at 6:39 PM, Ajay Kumar ajaykumar...@samsung.com wrote:
This patch adds a drm_bridge driver for the PS8622 DisplayPort to LVDS
bridge chip.
Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Sean Paul seanp...@chromium.org
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Hi Ajay,
I don't think that you should be claiming authorship of this driver, I
don't see any commits from you in the chromium tree ([1] [2]). The
driver was originally written by vpala...@chromium.org (who's
completely missing from SoB), it should probably be attributed to him.
Sean
Oops. I am really sorry and I didn't really want to claim the authorship
for this patch. I missed it while doing git format-patch.
And, thanks for letting me know that Vincent was the actual author.
I will add his authorship.
Regards,
Ajay Kumar
[1]-
https://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel-next.git;a=history;f=drivers/auxdisplay/ps8622.c;hb=fac579ad884d064d2c3cda988117e7dd66fc30c4
[2]-
https://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel-next.git;a=history;f=drivers/gpu/drm/bridge/ps8622.c;hb=refs/heads/chromeos-3.8
---
Changes since V1:
Pushing V1 for this as V2 because this patch holds good in this
series.
drivers/gpu/drm/bridge/Kconfig |7 +
drivers/gpu/drm/bridge/Makefile |1 +
drivers/gpu/drm/bridge/ps8622.c | 566
+++
include/drm/bridge/ps8622.h | 42 +++
4 files changed, 616 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/ps8622.c
create mode 100644 include/drm/bridge/ps8622.h
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3bc6845..aba21fc 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -4,3 +4,10 @@ config DRM_PTN3460
select DRM_KMS_HELPER
select DRM_PANEL
---help---
+
+config DRM_PS8622
+ tristate Parade eDP/LVDS bridge
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_PANEL
+ ---help---
diff --git a/drivers/gpu/drm/bridge/Makefile
b/drivers/gpu/drm/bridge/Makefile
index b4733e1..d1b5daa 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,3 +1,4 @@
ccflags-y := -Iinclude/drm
obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
+obj-$(CONFIG_DRM_PS8622) += ps8622.o
diff --git a/drivers/gpu/drm/bridge/ps8622.c
b/drivers/gpu/drm/bridge/ps8622.c
new file mode 100644
index 000..1e6b3ca
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ps8622.c
@@ -0,0 +1,566 @@
+/*
+ * Parade PS8622 eDP/LVDS bridge driver
+ *
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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 linux/module.h
+#include linux/backlight.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/fb.h
+#include linux/gpio.h
+#include linux/i2c.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include linux/pm.h
+#include linux/regulator/consumer.h
+#include drm/drm_panel.h
+
+#include drmP.h
+#include drm_crtc.h
+#include drm_crtc_helper.h
+
+struct ps8622_bridge {
+ struct drm_connector connector;
+ struct drm_bridge *bridge;
+ struct drm_encoder *encoder;
+ struct drm_panel *panel;
+ struct i2c_client *client;
+ struct regulator *v12;
+ struct backlight_device *bl;
+ struct mutex enable_mutex;
+
+ int gpio_slp_n;
+ int gpio_rst_n;
+
+ u8 max_lane_count;
+ u8 lane_count;
+
+ bool enabled;
+
+ struct drm_display_mode mode;
+};
+
+struct ps8622_device_data {
+ u8 max_lane_count;
+};
+
+static const struct ps8622_device_data ps8622_data = {
+ .max_lane_count = 1,
+};
+
+static const struct ps8622_device_data ps8625_data = {
+ .max_lane_count = 2,
+};
+
+/* Brightness scale on the Parade chip */
+#define PS8622_MAX_BRIGHTNESS 0xff
+
+/* Timings taken from the version 1.7 datasheet for the PS8622/PS8625 */
+#define PS8622_POWER_RISE_T1_MIN_US 10
+#define PS8622_POWER_RISE_T1_MAX_US 1
+#define PS8622_RST_HIGH_T2_MIN_US 3000
+#define PS8622_RST_HIGH_T2_MAX_US 3
+#define PS8622_PWMO_END_T12_MS 200
+#define
Re: [PATCH] ARM: EXYNOS: cpu hotplug: use v7_exit_coherency_flush macro for cache disabling
On 04/22/2014 04:18 PM, Leela Krishna Amudala wrote:
Remove the duplicated code for cache disabling and use v7_exit_coherency_flush
macro to do the same job.
Hi Leela,
thanks for this patch! It would be nice if you can describe why those
macros can be replaced by the generic v7_exit_coherency_flush macro.
Signed-off-by: Leela Krishna Amudala leela.kris...@linaro.org
---
cpu hotplug is tested with 3.15-rc1 on Origen(which has cortex A9) and
Arndale octa(which has cortex A7 and A15) boards.
arch/arm/mach-exynos/hotplug.c | 56 ++--
1 file changed, 2 insertions(+), 54 deletions(-)
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 5eead53..9eb8d1b 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -24,56 +24,6 @@
#include common.h
#include regs-pmu.h
-static inline void cpu_enter_lowpower_a9(void)
-{
- unsigned int v;
-
- asm volatile(
- mcr p15, 0, %1, c7, c5, 0\n
- mcr p15, 0, %1, c7, c10, 4\n
- /*
-* Turn off coherency
-*/
- mrc p15, 0, %0, c1, c0, 1\n
- bic %0, %0, %3\n
- mcr p15, 0, %0, c1, c0, 1\n
- mrc p15, 0, %0, c1, c0, 0\n
- bic %0, %0, %2\n
- mcr p15, 0, %0, c1, c0, 0\n
- : =r (v)
- : r (0), Ir (CR_C), Ir (0x40)
- : cc);
-}
-
-static inline void cpu_enter_lowpower_a15(void)
-{
- unsigned int v;
-
- asm volatile(
- mrc p15, 0, %0, c1, c0, 0\n
- bic %0, %0, %1\n
- mcr p15, 0, %0, c1, c0, 0\n
- : =r (v)
- : Ir (CR_C)
- : cc);
-
- flush_cache_louis();
-
- asm volatile(
- /*
- * Turn off coherency
- */
- mrc p15, 0, %0, c1, c0, 1\n
- bic %0, %0, %1\n
- mcr p15, 0, %0, c1, c0, 1\n
- : =r (v)
- : Ir (0x40)
- : cc);
-
- isb();
- dsb();
-}
-
static inline void cpu_leave_lowpower(void)
{
unsigned int v;
@@ -141,10 +91,8 @@ void __ref exynos_cpu_die(unsigned int cpu)
* appropriate sequence for entering low power.
*/
asm(mrc p15, 0, %0, c0, c0, 0 : =r(primary_part) : : cc);
Can't you remove this asm line above as well as the primary_part variable ?
- if ((primary_part 0xfff0) == 0xc0f0)
- cpu_enter_lowpower_a15();
- else
- cpu_enter_lowpower_a9();
+
+ v7_exit_coherency_flush(louis);
platform_do_lowpower(cpu, spurious);
--
http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog
--
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 3/9] drm/panel: Add driver for exynos_dp based panels
Hi Jingoo, On Tue, Apr 22, 2014 at 12:52 PM, Jingoo Han jg1@samsung.com wrote: On Tuesday, April 22, 2014 7:39 AM, Ajay Kumar wrote: This patch adds a simple driver to handle all the LCD and LED powerup/down routines needed to support eDP/eDP-LVDS panels supported on exynos boards. The LCD and LED units are usually powered up via regulators, and almost on all boards, we will have a BL_EN pin to enable/ disable the backlight. Sometimes, we can have LCD_EN switches as well. The routines in this driver can be used to control panel power sequence on such boards. Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- Changes since V1: Added routine for post_disable, removed few unwanted headers. Refactored a lot of code. .../devicetree/bindings/panel/exynos-dp-panel.txt | 45 drivers/gpu/drm/panel/Kconfig |9 + drivers/gpu/drm/panel/Makefile |1 + drivers/gpu/drm/panel/panel-exynos-dp.c| 251 4 files changed, 306 insertions(+) create mode 100644 Documentation/devicetree/bindings/panel/exynos-dp-panel.txt create mode 100644 drivers/gpu/drm/panel/panel-exynos-dp.c diff --git a/Documentation/devicetree/bindings/panel/exynos-dp-panel.txt b/Documentation/devicetree/bindings/panel/exynos-dp-panel.txt new file mode 100644 index 000..3fbca54 --- /dev/null +++ b/Documentation/devicetree/bindings/panel/exynos-dp-panel.txt @@ -0,0 +1,45 @@ +exynos_DP_panel/DP_to_LVDS_panel Please fix it as below. +Exynos DP panel/DP to LVDS panel Ok. [] diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index 4ec874d..ea9d5ac 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -30,4 +30,13 @@ config DRM_PANEL_S6E8AA0 select DRM_MIPI_DSI select VIDEOMODE_HELPERS +config DRM_PANEL_EXYNOS_DP + tristate support for DP panels It looks very general. Please fix it as below. + tristate support for Exynos DP panels Ok. Best regards, Jingoo Han + depends on OF DRM_PANEL DRM_EXYNOS_DP + help + DRM panel driver for DP panels and LVDS connected via DP bridges + that need at most a regulator for LCD unit, a regulator for LED unit + and/or enable GPIOs for LCD or LED units. Delay values can also be + specified to support powerup and powerdown process. + [.] Thanks and Regards, Ajay Kumar -- 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 2/4] drm: Constify struct drm_fb_helper_funcs
From: Thierry Reding tred...@nvidia.com
There's no need for this to be modifiable. Make it const so that it can
be put into the .rodata section.
Signed-off-by: Thierry Reding tred...@nvidia.com
---
drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
drivers/gpu/drm/ast/ast_fb.c | 2 +-
drivers/gpu/drm/bochs/bochs_fbdev.c | 2 +-
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 2 +-
drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +-
drivers/gpu/drm/gma500/framebuffer.c | 2 +-
drivers/gpu/drm/i915/intel_fbdev.c| 2 +-
drivers/gpu/drm/mgag200/mgag200_fb.c | 2 +-
drivers/gpu/drm/msm/msm_fbdev.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +-
drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 +-
drivers/gpu/drm/qxl/qxl_fb.c | 2 +-
drivers/gpu/drm/radeon/radeon_fb.c| 2 +-
drivers/gpu/drm/tegra/fb.c| 2 +-
drivers/gpu/drm/udl/udl_fb.c | 2 +-
include/drm/drm_fb_helper.h | 2 +-
17 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c
b/drivers/gpu/drm/armada/armada_fbdev.c
index 948cb14c561e..21aa1261dba2 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -131,7 +131,7 @@ static int armada_fb_probe(struct drm_fb_helper *fbh,
return ret;
}
-static struct drm_fb_helper_funcs armada_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs armada_fb_helper_funcs = {
.gamma_set = armada_drm_crtc_gamma_set,
.gamma_get = armada_drm_crtc_gamma_get,
.fb_probe = armada_fb_probe,
diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index a28640f47c27..2113894e4ff8 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -287,7 +287,7 @@ static void ast_fb_gamma_get(struct drm_crtc *crtc, u16
*red, u16 *green,
*blue = ast_crtc-lut_b[regno] 8;
}
-static struct drm_fb_helper_funcs ast_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs ast_fb_helper_funcs = {
.gamma_set = ast_fb_gamma_set,
.gamma_get = ast_fb_gamma_get,
.fb_probe = astfb_create,
diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index 561b84474122..17e5c17f2730 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -179,7 +179,7 @@ void bochs_fb_gamma_get(struct drm_crtc *crtc, u16 *red,
u16 *green,
*blue = regno;
}
-static struct drm_fb_helper_funcs bochs_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs bochs_fb_helper_funcs = {
.gamma_set = bochs_fb_gamma_set,
.gamma_get = bochs_fb_gamma_get,
.fb_probe = bochsfb_create,
diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index 32bbba0a787b..2bd0291168e4 100644
--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -288,7 +288,7 @@ static int cirrus_fbdev_destroy(struct drm_device *dev,
return 0;
}
-static struct drm_fb_helper_funcs cirrus_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs cirrus_fb_helper_funcs = {
.gamma_set = cirrus_crtc_fb_gamma_set,
.gamma_get = cirrus_crtc_fb_gamma_get,
.fb_probe = cirrusfb_create,
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 61b5a47ad239..b74f9e58b69d 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -327,7 +327,7 @@ err_drm_gem_cma_free_object:
return ret;
}
-static struct drm_fb_helper_funcs drm_fb_cma_helper_funcs = {
+static const struct drm_fb_helper_funcs drm_fb_cma_helper_funcs = {
.fb_probe = drm_fbdev_cma_create,
};
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index addbf7536da4..7ccf04917f47 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -233,7 +233,7 @@ out:
return ret;
}
-static struct drm_fb_helper_funcs exynos_drm_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs exynos_drm_fb_helper_funcs = {
.fb_probe = exynos_drm_fbdev_create,
};
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index e7fcc148f333..76e4d777d01d 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -561,7 +561,7 @@ static int psbfb_probe(struct drm_fb_helper *helper,
return psbfb_create(psb_fbdev, sizes);
}
-static struct drm_fb_helper_funcs psb_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs psb_fb_helper_funcs = {
.gamma_set = psbfb_gamma_set,
.gamma_get = psbfb_gamma_get,
.fb_probe = psbfb_probe,
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
[PATCH 1/4] drm/fb-helper: Fix hpd vs. initial config races
From: Daniel Vetter daniel.vet...@ffwll.ch
Some drivers need to be able to have a perfect race-free fbcon setup.
Current drivers only enable hotplug processing after the call to
drm_fb_helper_initial_config which leaves a tiny but important race.
This race is especially noticable on embedded platforms where the
driver itself enables the voltage for the hdmi output, since only then
will monitors (after a bit of delay, as usual) respond by asserting
the hpd pin.
Most of the infrastructure is already there with the split-out
drm_fb_helper_init. And drm_fb_helper_initial_config already has all
the required locking to handle concurrent hpd events since
commit 53f1904bced78d7c00f5d874c662ec3ac85d0f9f
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Thu Mar 20 14:26:35 2014 +0100
drm/fb-helper: improve drm_fb_helper_initial_config locking
The only missing bit is making drm_fb_helper_hotplug_event save
against concurrent calls of drm_fb_helper_initial_config. The only
unprotected bit is the check for fb_helper-fb.
With that drivers can first initialize the fb helper, then enabel
hotplug processing and then set up the initial config all in a
completely race-free manner. Update kerneldoc and convert i915 as a
proof of concept.
Feature requested by Thierry since his tegra driver atm reliably boots
slowly enough to misses the hotplug event for an external hdmi screen,
but also reliably boots to quickly for the hpd pin to be asserted when
the fb helper calls into the hdmi -detect function.
Cc: Thierry Reding tred...@nvidia.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Thierry Reding tred...@nvidia.com
---
drivers/gpu/drm/drm_fb_helper.c | 11 +--
drivers/gpu/drm/i915/i915_dma.c | 3 ---
drivers/gpu/drm/i915/i915_drv.c | 2 --
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_irq.c | 4
5 files changed, 5 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index e95ed5805f07..80ce92ab91f9 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1587,8 +1587,10 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config);
* either the output polling work or a work item launched from the driver's
* hotplug interrupt).
*
- * Note that the driver must ensure that this is only called _after_ the fb has
- * been fully set up, i.e. after the call to drm_fb_helper_initial_config.
+ * Note that drivers may call this even before calling
+ * drm_fb_helper_initial_config but only aftert drm_fb_helper_init. This allows
+ * for a race-free fbcon setup and will make sure that the fbdev emulation will
+ * not miss any hotplug events.
*
* RETURNS:
* 0 on success and a non-zero error code otherwise.
@@ -1598,11 +1600,8 @@ int drm_fb_helper_hotplug_event(struct drm_fb_helper
*fb_helper)
struct drm_device *dev = fb_helper-dev;
u32 max_width, max_height;
- if (!fb_helper-fb)
- return 0;
-
mutex_lock(fb_helper-dev-mode_config.mutex);
- if (!drm_fb_helper_is_bound(fb_helper)) {
+ if (!fb_helper-fb || !drm_fb_helper_is_bound(fb_helper)) {
fb_helper-delayed_hotplug = true;
mutex_unlock(fb_helper-dev-mode_config.mutex);
return 0;
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index cc0c6eded51c..89ba88d37ae1 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1375,9 +1375,6 @@ static int i915_load_modeset_init(struct drm_device *dev)
*/
intel_fbdev_initial_config(dev);
- /* Only enable hotplug handling once the fbdev is fully set up. */
- dev_priv-enable_hotplug_processing = true;
-
drm_kms_helper_poll_init(dev);
return 0;
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 254b3236200b..dee36a5b7fae 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -448,7 +448,6 @@ static int i915_drm_freeze(struct drm_device *dev)
cancel_delayed_work_sync(dev_priv-rps.delayed_resume_work);
drm_irq_uninstall(dev);
- dev_priv-enable_hotplug_processing = false;
/*
* Disable CRTCs directly since we want to preserve sw state
* for _thaw.
@@ -589,7 +588,6 @@ static int __i915_drm_thaw(struct drm_device *dev, bool
restore_gtt_mappings)
* notifications.
* */
intel_hpd_init(dev);
- dev_priv-enable_hotplug_processing = true;
/* Config may have changed between suspend and resume */
intel_resume_hotplug(dev);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7d6acb401fd9..41094d6357b1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1321,7 +1321,6 @@
[PATCH 3/4] drm: Introduce drm_fb_helper_prepare()
From: Thierry Reding tred...@nvidia.com
To implement hotplug detection in a race-free manner, drivers must call
drm_kms_helper_poll_init() before hotplug events can be triggered. Such
events can be triggered right after any of the encoders or connectors
are initialized. At the same time, if the drm_fb_helper_hotplug_event()
helper is used by a driver, then the poll helper requires some parts of
the FB helper to be initialized to prevent a crash.
At the same time, drm_fb_helper_init() requires information that is not
necessarily available at such an early stage (number of CRTCs and
connectors), so it cannot be used yet.
Add a new helper, drm_fb_helper_prepare(), that initializes the bare
minimum needed to allow drm_kms_helper_poll_init() to execute and any
subsequent hotplug events to be processed properly.
Signed-off-by: Thierry Reding tred...@nvidia.com
---
drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
drivers/gpu/drm/ast/ast_fb.c | 4 ++-
drivers/gpu/drm/bochs/bochs_fbdev.c | 3 ++-
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 4 ++-
drivers/gpu/drm/drm_fb_cma_helper.c | 3 ++-
drivers/gpu/drm/drm_fb_helper.c | 43 ---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 3 ++-
drivers/gpu/drm/gma500/framebuffer.c | 3 ++-
drivers/gpu/drm/i915/intel_fbdev.c| 3 ++-
drivers/gpu/drm/mgag200/mgag200_fb.c | 3 ++-
drivers/gpu/drm/msm/msm_fbdev.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 3 ++-
drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 +-
drivers/gpu/drm/qxl/qxl_fb.c | 5 +++-
drivers/gpu/drm/radeon/radeon_fb.c| 4 ++-
drivers/gpu/drm/tegra/fb.c| 4 +--
drivers/gpu/drm/udl/udl_fb.c | 3 ++-
include/drm/drm_fb_helper.h | 2 ++
18 files changed, 68 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c
b/drivers/gpu/drm/armada/armada_fbdev.c
index 21aa1261dba2..9437e11d5df1 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -149,7 +149,7 @@ int armada_fbdev_init(struct drm_device *dev)
priv-fbdev = fbh;
- fbh-funcs = armada_fb_helper_funcs;
+ drm_fb_helper_prepare(dev, fbh, armada_fb_helper_funcs);
ret = drm_fb_helper_init(dev, fbh, 1, 1);
if (ret) {
diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index 2113894e4ff8..cba45c774552 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -328,8 +328,10 @@ int ast_fbdev_init(struct drm_device *dev)
return -ENOMEM;
ast-fbdev = afbdev;
- afbdev-helper.funcs = ast_fb_helper_funcs;
spin_lock_init(afbdev-dirty_lock);
+
+ drm_fb_helper_prepare(dev, afbdev-helper, ast_fb_helper_funcs);
+
ret = drm_fb_helper_init(dev, afbdev-helper,
1, 1);
if (ret) {
diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index 17e5c17f2730..19cf3e9413b6 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -189,7 +189,8 @@ int bochs_fbdev_init(struct bochs_device *bochs)
{
int ret;
- bochs-fb.helper.funcs = bochs_fb_helper_funcs;
+ drm_fb_helper_prepare(bochs-dev, bochs-fb.helper,
+ bochs_fb_helper_funcs);
ret = drm_fb_helper_init(bochs-dev, bochs-fb.helper,
1, 1);
diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index 2bd0291168e4..2a135f253e29 100644
--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -306,9 +306,11 @@ int cirrus_fbdev_init(struct cirrus_device *cdev)
return -ENOMEM;
cdev-mode_info.gfbdev = gfbdev;
- gfbdev-helper.funcs = cirrus_fb_helper_funcs;
spin_lock_init(gfbdev-dirty_lock);
+ drm_fb_helper_prepare(cdev-dev, gfbdev-helper,
+ cirrus_fb_helper_funcs);
+
ret = drm_fb_helper_init(cdev-dev, gfbdev-helper,
cdev-num_crtc, CIRRUSFB_CONN_LIMIT);
if (ret) {
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index b74f9e58b69d..acbbd230e081 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -354,9 +354,10 @@ struct drm_fbdev_cma *drm_fbdev_cma_init(struct drm_device
*dev,
return ERR_PTR(-ENOMEM);
}
- fbdev_cma-fb_helper.funcs = drm_fb_cma_helper_funcs;
helper = fbdev_cma-fb_helper;
+ drm_fb_helper_prepare(dev, helper, drm_fb_cma_helper_funcs);
+
ret = drm_fb_helper_init(dev, helper, num_crtc, max_conn_count);
if (ret 0) {
dev_err(dev-dev, Failed to initialize drm fb helper.\n);
diff --git
[PATCH 4/4] drm/tegra: Implement race-free hotplug detection
From: Thierry Reding tred...@nvidia.com
A race condition currently exists on Tegra, where it can happen that a
monitor attached via HDMI isn't detected during the initial FB helper
setup, but the hotplug event happens too early to be processed by the
poll helpers because they haven't been initialized yet. This happens
because on some boards the HDMI driver can control the regulator that
supplies the +5V pin on the HDMI connector. Therefore depending on the
timing between the initialization of the HDMI driver and the rest of
DRM, it's possible that the monitor returns the hotplug signal right
within the window where we would miss it.
Unfortunately, drm_kms_helper_poll_init() will wreak havoc when called
before at least some parts of the FB helpers have been set up.
This commit fixes this by splitting out the minimum of initialization
required to make drm_kms_helper_poll_init() work into a separate
function that can be called early. It is then safe to move all of the
poll helper initialization to an earlier point in time (before the
HDMI output driver has a chance to enable the +5V supply). That way if
the hotplug signal is returned before the initial FB helper setup, the
monitor will be forcefully detected at that point, and if the hotplug
signal is returned after that it will be properly handled by the poll
helpers.
Signed-off-by: Thierry Reding tred...@nvidia.com
---
drivers/gpu/drm/tegra/drm.c | 8 ++--
drivers/gpu/drm/tegra/drm.h | 1 +
drivers/gpu/drm/tegra/fb.c | 47 ++---
3 files changed, 39 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 6f5b6e2f552e..4d36debe3de6 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -41,6 +41,12 @@ static int tegra_drm_load(struct drm_device *drm, unsigned
long flags)
drm_mode_config_init(drm);
+ err = tegra_drm_fb_prepare(drm);
+ if (err 0)
+ return err;
+
+ drm_kms_helper_poll_init(drm);
+
err = host1x_device_init(device);
if (err 0)
return err;
@@ -60,8 +66,6 @@ static int tegra_drm_load(struct drm_device *drm, unsigned
long flags)
if (err 0)
return err;
- drm_kms_helper_poll_init(drm);
-
return 0;
}
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 126332c3ecbb..c2d9705de1f9 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -288,6 +288,7 @@ struct tegra_bo *tegra_fb_get_plane(struct drm_framebuffer
*framebuffer,
unsigned int index);
bool tegra_fb_is_bottom_up(struct drm_framebuffer *framebuffer);
bool tegra_fb_is_tiled(struct drm_framebuffer *framebuffer);
+int tegra_drm_fb_prepare(struct drm_device *drm);
extern int tegra_drm_fb_init(struct drm_device *drm);
extern void tegra_drm_fb_exit(struct drm_device *drm);
#ifdef CONFIG_DRM_TEGRA_FBDEV
diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
index 2e3758542c89..70d0e07d353c 100644
--- a/drivers/gpu/drm/tegra/fb.c
+++ b/drivers/gpu/drm/tegra/fb.c
@@ -271,13 +271,9 @@ static const struct drm_fb_helper_funcs
tegra_fb_helper_funcs = {
.fb_probe = tegra_fbdev_probe,
};
-static struct tegra_fbdev *tegra_fbdev_create(struct drm_device *drm,
- unsigned int preferred_bpp,
- unsigned int num_crtc,
- unsigned int max_connectors)
+static struct tegra_fbdev *tegra_fbdev_create(struct drm_device *drm)
{
struct tegra_fbdev *fbdev;
- int err;
fbdev = kzalloc(sizeof(*fbdev), GFP_KERNEL);
if (!fbdev) {
@@ -287,10 +283,21 @@ static struct tegra_fbdev *tegra_fbdev_create(struct
drm_device *drm,
drm_fb_helper_prepare(drm, fbdev-base, tegra_fb_helper_funcs);
+ return fbdev;
+}
+
+static int tegra_fbdev_init(struct tegra_fbdev *fbdev,
+ unsigned int preferred_bpp,
+ unsigned int num_crtc,
+ unsigned int max_connectors)
+{
+ struct drm_device *drm = fbdev-base.dev;
+ int err;
+
err = drm_fb_helper_init(drm, fbdev-base, num_crtc, max_connectors);
if (err 0) {
dev_err(drm-dev, failed to initialize DRM FB helper\n);
- goto free;
+ return err;
}
err = drm_fb_helper_single_add_all_connectors(fbdev-base);
@@ -299,21 +306,17 @@ static struct tegra_fbdev *tegra_fbdev_create(struct
drm_device *drm,
goto fini;
}
- drm_helper_disable_unused_functions(drm);
-
err = drm_fb_helper_initial_config(fbdev-base, preferred_bpp);
if (err 0) {
dev_err(drm-dev, failed to set initial configuration\n);
goto fini;
}
- return fbdev;
+
Re: [PATCH V2 3/9] drm/panel: Add driver for exynos_dp based panels
Hi Thierry, On Tue, Apr 22, 2014 at 1:56 PM, Thierry Reding thierry.red...@gmail.com wrote: On Tue, Apr 22, 2014 at 04:09:12AM +0530, Ajay Kumar wrote: This patch adds a simple driver to handle all the LCD and LED powerup/down routines needed to support eDP/eDP-LVDS panels supported on exynos boards. The LCD and LED units are usually powered up via regulators, and almost on all boards, we will have a BL_EN pin to enable/ disable the backlight. Sometimes, we can have LCD_EN switches as well. The routines in this driver can be used to control panel power sequence on such boards. Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- Changes since V1: Added routine for post_disable, removed few unwanted headers. Refactored a lot of code. .../devicetree/bindings/panel/exynos-dp-panel.txt | 45 drivers/gpu/drm/panel/Kconfig |9 + drivers/gpu/drm/panel/Makefile |1 + drivers/gpu/drm/panel/panel-exynos-dp.c| 251 4 files changed, 306 insertions(+) create mode 100644 Documentation/devicetree/bindings/panel/exynos-dp-panel.txt create mode 100644 drivers/gpu/drm/panel/panel-exynos-dp.c What this patch does is in no way Exynos specific. It is also not eDP specific. Right. This is not at all writing into any exynos specific register, but can't this be just a placeholder for all the panel controls which can serve boards which use exynos_dp? This conflates panel drivers with board drivers in a strange way. Panel drivers should be for *panels*, not for a given SoC or specific outputs on that SoC. Right. But for that matter, even the panel-simple driver is doing the same, which is just a placeholder for generic panel controls which serves multiple boards. I din't choose to reuse that because the boards which I have expect more control over the panel sequence as mentioned before. If you don't mind, I can fit in all these settings into panel-simple driver itself ;) But again, I should be able to register the panel driver much before exynos_dp gets probed, That's the actual catch! Thanks and regards, Ajay Kumar -- 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 4/9] drm/exynos: add exynos_dp_panel driver registration to drm driver
Hi Thierry, On Tue, Apr 22, 2014 at 2:03 PM, Thierry Reding thierry.red...@gmail.com wrote: On Tue, Apr 22, 2014 at 04:09:13AM +0530, Ajay Kumar wrote: Register exynos_dp_panel before the list of exynos crtcs and connectors are probed. This is needed because exynos_dp_panel should be registered to the drm_panel list via panel-exynos-dp probe, i.e much before exynos_dp_bind calls of_drm_find_panel(). Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- Changes since V1: Added platform_driver_unregister(exynos_dp_panel_driver) to exynos_drm_platform_remove as per Jingoo Han's correction drivers/gpu/drm/exynos/exynos_drm_drv.c | 15 +++ drivers/gpu/drm/exynos/exynos_drm_drv.h |1 + 2 files changed, 16 insertions(+) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index 1d653f8..2db7f67 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -530,12 +530,23 @@ static int exynos_drm_platform_probe(struct platform_device *pdev) goto err_unregister_ipp_drv; #endif +#ifdef CONFIG_DRM_PANEL_EXYNOS_DP + ret = platform_driver_register(exynos_dp_panel_driver); + if (ret 0) + goto err_unregister_dp_panel; +#endif No, this is not how you're supposed to use DRM panel drivers. The idea is that you write a standalone driver for a given panel. What you do here has a number of problems. For one it's a driver that's tightly coupled to Exynos SoCs. But if I have a different SoC that uses the same panel I want to be able to use the same driver, and not have to rewrite the driver for my SoC. Another problem is that you're assuming here that the driver is built in and it will break if you try to build either Exynos DRM or the panel driver as a module. This is perhaps nothing you care about right now, but eventually people will want to ship a single kernel that can run on a number of SoCs. But if we keep adding things like this, that kernel will keep growing in size until it no longer fits in any kind of memory. Thierry I completely agree with you in this! Yes, this is not acceptable, but I want to know an acceptable workaround for the situation below: I register the driver using module_init(). And, exynos_drm gets probed much before the panel driver probe happens. So, the panel driver hasn't probed yet, but exynos_dp via exynos_drm tries to call of_drm_find_panel which always returns NULL. Thanks and regards, Ajay Kumar -- 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 3/9] drm/panel: Add driver for exynos_dp based panels
On Tue, Apr 22, 2014 at 08:23:03PM +0530, Ajay kumar wrote: Hi Thierry, On Tue, Apr 22, 2014 at 1:56 PM, Thierry Reding thierry.red...@gmail.com wrote: On Tue, Apr 22, 2014 at 04:09:12AM +0530, Ajay Kumar wrote: This patch adds a simple driver to handle all the LCD and LED powerup/down routines needed to support eDP/eDP-LVDS panels supported on exynos boards. The LCD and LED units are usually powered up via regulators, and almost on all boards, we will have a BL_EN pin to enable/ disable the backlight. Sometimes, we can have LCD_EN switches as well. The routines in this driver can be used to control panel power sequence on such boards. Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- Changes since V1: Added routine for post_disable, removed few unwanted headers. Refactored a lot of code. .../devicetree/bindings/panel/exynos-dp-panel.txt | 45 drivers/gpu/drm/panel/Kconfig |9 + drivers/gpu/drm/panel/Makefile |1 + drivers/gpu/drm/panel/panel-exynos-dp.c| 251 4 files changed, 306 insertions(+) create mode 100644 Documentation/devicetree/bindings/panel/exynos-dp-panel.txt create mode 100644 drivers/gpu/drm/panel/panel-exynos-dp.c What this patch does is in no way Exynos specific. It is also not eDP specific. Right. This is not at all writing into any exynos specific register, but can't this be just a placeholder for all the panel controls which can serve boards which use exynos_dp? No, it shouldn't. Like I said, if I have a panel that happens to be used on an Exynos board but I use it on a different board, then I don't want to have to know that the panel might be supported by Exynos so that I know which driver to use. So ideally there should be one driver per panel. panel-simple was introduced because of the five panels that I had access to at the time, five panels could be supported using the same code. This conflates panel drivers with board drivers in a strange way. Panel drivers should be for *panels*, not for a given SoC or specific outputs on that SoC. Right. But for that matter, even the panel-simple driver is doing the same, which is just a placeholder for generic panel controls which serves multiple boards. panel-simple is meant for panels that require only the parameters that are specified for those. Anything that needs more is by definition no longer simple. And the difference here is that panel-simple is a true wildcard, but it isn't specific to one SoC. And the name doesn't imply that either. Also each panel is still identified by the specific compatible value, which makes it easier to find out which driver supports the panel. Thierry pgppBTsmbXHL5.pgp Description: PGP signature
Re: [PATCH V2 4/9] drm/exynos: add exynos_dp_panel driver registration to drm driver
On Tue, Apr 22, 2014 at 08:33:23PM +0530, Ajay kumar wrote: Hi Thierry, On Tue, Apr 22, 2014 at 2:03 PM, Thierry Reding thierry.red...@gmail.com wrote: On Tue, Apr 22, 2014 at 04:09:13AM +0530, Ajay Kumar wrote: Register exynos_dp_panel before the list of exynos crtcs and connectors are probed. This is needed because exynos_dp_panel should be registered to the drm_panel list via panel-exynos-dp probe, i.e much before exynos_dp_bind calls of_drm_find_panel(). Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- Changes since V1: Added platform_driver_unregister(exynos_dp_panel_driver) to exynos_drm_platform_remove as per Jingoo Han's correction drivers/gpu/drm/exynos/exynos_drm_drv.c | 15 +++ drivers/gpu/drm/exynos/exynos_drm_drv.h |1 + 2 files changed, 16 insertions(+) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index 1d653f8..2db7f67 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -530,12 +530,23 @@ static int exynos_drm_platform_probe(struct platform_device *pdev) goto err_unregister_ipp_drv; #endif +#ifdef CONFIG_DRM_PANEL_EXYNOS_DP + ret = platform_driver_register(exynos_dp_panel_driver); + if (ret 0) + goto err_unregister_dp_panel; +#endif No, this is not how you're supposed to use DRM panel drivers. The idea is that you write a standalone driver for a given panel. What you do here has a number of problems. For one it's a driver that's tightly coupled to Exynos SoCs. But if I have a different SoC that uses the same panel I want to be able to use the same driver, and not have to rewrite the driver for my SoC. Another problem is that you're assuming here that the driver is built in and it will break if you try to build either Exynos DRM or the panel driver as a module. This is perhaps nothing you care about right now, but eventually people will want to ship a single kernel that can run on a number of SoCs. But if we keep adding things like this, that kernel will keep growing in size until it no longer fits in any kind of memory. Thierry I completely agree with you in this! Yes, this is not acceptable, but I want to know an acceptable workaround for the situation below: I register the driver using module_init(). And, exynos_drm gets probed much before the panel driver probe happens. So, the panel driver hasn't probed yet, but exynos_dp via exynos_drm tries to call of_drm_find_panel which always returns NULL. That's a situation that your driver needs to be able to deal with. The driver registration order doesn't matter one bit. It may happen to work most of the time, but as soon as one of the resources that your panel driver needs isn't there when the panel is probed, then it won't be registered and of_drm_find_panel() will still return NULL. Usually the right thing to do in that case would be to return (and propagate) -EPROBE_DEFER so that your driver's probe is deferred and retried when other drivers have been probed. That way it should eventually get a non-NULL panel. Thierry pgpK6GSHHWlWN.pgp Description: PGP signature
Re: [PATCH v3 5/5] regulator: tps65090: Make FETs more reliable by adding retries
Hi, On Tue, Apr 22, 2014 at 8:07 AM, Lee Jones lee.jo...@linaro.org wrote: If there are cross-subsystem dependencies I prefer to use immutable branches to eliminate any change of merge conflicts in -next or the next merge window. I'm happy to either create on with Mark's Acks, or receive a pull-request from Mark with mine applied. Up to Mark. Well, Doug didn't send me the MFD patch so I can't do anything with it anyway. Ah! Doug, what exactly are the dependencies within the set? I will repost the patch shortly with Mark on the CC list. Status of the patches in this series: - Patch #1 (mfd no irq) has no dependencies, though patch #2 won't work without it. https://patchwork.kernel.org/patch/4004441/ Acked by you. Not landed anywhere that I'm aware of. -- - Patch #2 (charger polling) can be applied without patch #1 but won't actually make charger polling work without it. https://patchwork.kernel.org/patch/4004461/ Not acked or applied anywhere. --- - Patch #3 (caching) can be applied before retries patch but not after. https://patchwork.kernel.org/patch/4033361/ This is the patch we need. I just resent with Mark on the CC list (including your ack). --- - Patch #4 (overcurrent wait time) can be applied before retries patch but not after (just due to merge conflicts, no other reason). https://patchwork.kernel.org/patch/4004471/ I believe Mark has already applied. --- - Patch #5 (retries) absolutely requires patch #3 (caching). https://patchwork.kernel.org/patch/4004521/ -- 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 2/4] drm: Constify struct drm_fb_helper_funcs
On Tue, Apr 22, 2014 at 04:42:19PM +0200, Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
There's no need for this to be modifiable. Make it const so that it can
be put into the .rodata section.
Signed-off-by: Thierry Reding tred...@nvidia.com
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
drivers/gpu/drm/ast/ast_fb.c | 2 +-
drivers/gpu/drm/bochs/bochs_fbdev.c | 2 +-
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 2 +-
drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +-
drivers/gpu/drm/gma500/framebuffer.c | 2 +-
drivers/gpu/drm/i915/intel_fbdev.c| 2 +-
drivers/gpu/drm/mgag200/mgag200_fb.c | 2 +-
drivers/gpu/drm/msm/msm_fbdev.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +-
drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 +-
drivers/gpu/drm/qxl/qxl_fb.c | 2 +-
drivers/gpu/drm/radeon/radeon_fb.c| 2 +-
drivers/gpu/drm/tegra/fb.c| 2 +-
drivers/gpu/drm/udl/udl_fb.c | 2 +-
include/drm/drm_fb_helper.h | 2 +-
17 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c
b/drivers/gpu/drm/armada/armada_fbdev.c
index 948cb14c561e..21aa1261dba2 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -131,7 +131,7 @@ static int armada_fb_probe(struct drm_fb_helper *fbh,
return ret;
}
-static struct drm_fb_helper_funcs armada_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs armada_fb_helper_funcs = {
.gamma_set = armada_drm_crtc_gamma_set,
.gamma_get = armada_drm_crtc_gamma_get,
.fb_probe = armada_fb_probe,
diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index a28640f47c27..2113894e4ff8 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -287,7 +287,7 @@ static void ast_fb_gamma_get(struct drm_crtc *crtc, u16
*red, u16 *green,
*blue = ast_crtc-lut_b[regno] 8;
}
-static struct drm_fb_helper_funcs ast_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs ast_fb_helper_funcs = {
.gamma_set = ast_fb_gamma_set,
.gamma_get = ast_fb_gamma_get,
.fb_probe = astfb_create,
diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index 561b84474122..17e5c17f2730 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -179,7 +179,7 @@ void bochs_fb_gamma_get(struct drm_crtc *crtc, u16 *red,
u16 *green,
*blue = regno;
}
-static struct drm_fb_helper_funcs bochs_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs bochs_fb_helper_funcs = {
.gamma_set = bochs_fb_gamma_set,
.gamma_get = bochs_fb_gamma_get,
.fb_probe = bochsfb_create,
diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index 32bbba0a787b..2bd0291168e4 100644
--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -288,7 +288,7 @@ static int cirrus_fbdev_destroy(struct drm_device *dev,
return 0;
}
-static struct drm_fb_helper_funcs cirrus_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs cirrus_fb_helper_funcs = {
.gamma_set = cirrus_crtc_fb_gamma_set,
.gamma_get = cirrus_crtc_fb_gamma_get,
.fb_probe = cirrusfb_create,
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 61b5a47ad239..b74f9e58b69d 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -327,7 +327,7 @@ err_drm_gem_cma_free_object:
return ret;
}
-static struct drm_fb_helper_funcs drm_fb_cma_helper_funcs = {
+static const struct drm_fb_helper_funcs drm_fb_cma_helper_funcs = {
.fb_probe = drm_fbdev_cma_create,
};
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index addbf7536da4..7ccf04917f47 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -233,7 +233,7 @@ out:
return ret;
}
-static struct drm_fb_helper_funcs exynos_drm_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs exynos_drm_fb_helper_funcs = {
.fb_probe = exynos_drm_fbdev_create,
};
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index e7fcc148f333..76e4d777d01d 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -561,7 +561,7 @@ static int psbfb_probe(struct drm_fb_helper *helper,
return psbfb_create(psb_fbdev, sizes);
}
-static struct drm_fb_helper_funcs psb_fb_helper_funcs = {
+static const struct
[RESEND PATCH v3 3/5] mfd: tps65090: Stop caching most registers
Nearly all of the registers in tps65090 combine control bits and
status bits. Turn off caching of all registers except the select few
that can be cached.
In order to avoid adding more duplicate #defines, we also move some
register offset definitions to the mfd driver (and resolve
inconsistent names).
Signed-off-by: Doug Anderson diand...@chromium.org
Acked-by: Lee Jones lee.jo...@linaro.org
---
Changes in v3: None
Changes in v2:
- Leave cache on for the registers that can be cached.
- Move register offsets to mfd header file.
drivers/mfd/tps65090.c | 27 ++-
drivers/power/tps65090-charger.c | 11 ---
include/linux/mfd/tps65090.h | 14 ++
3 files changed, 28 insertions(+), 24 deletions(-)
diff --git a/drivers/mfd/tps65090.c b/drivers/mfd/tps65090.c
index c3cddb4..1c3e6e2 100644
--- a/drivers/mfd/tps65090.c
+++ b/drivers/mfd/tps65090.c
@@ -32,14 +32,6 @@
#define NUM_INT_REG 2
#define TOTAL_NUM_REG 0x18
-/* interrupt status registers */
-#define TPS65090_INT_STS 0x0
-#define TPS65090_INT_STS2 0x1
-
-/* interrupt mask registers */
-#define TPS65090_INT_MSK 0x2
-#define TPS65090_INT_MSK2 0x3
-
#define TPS65090_INT1_MASK_VAC_STATUS_CHANGE 1
#define TPS65090_INT1_MASK_VSYS_STATUS_CHANGE 2
#define TPS65090_INT1_MASK_BAT_STATUS_CHANGE 3
@@ -144,17 +136,26 @@ static struct regmap_irq_chip tps65090_irq_chip = {
.irqs = tps65090_irqs,
.num_irqs = ARRAY_SIZE(tps65090_irqs),
.num_regs = NUM_INT_REG,
- .status_base = TPS65090_INT_STS,
- .mask_base = TPS65090_INT_MSK,
+ .status_base = TPS65090_REG_INTR_STS,
+ .mask_base = TPS65090_REG_INTR_MASK,
.mask_invert = true,
};
static bool is_volatile_reg(struct device *dev, unsigned int reg)
{
- if ((reg == TPS65090_INT_STS) || (reg == TPS65090_INT_STS2))
- return true;
- else
+ /* Nearly all registers have status bits mixed in, except a few */
+ switch (reg) {
+ case TPS65090_REG_INTR_MASK:
+ case TPS65090_REG_INTR_MASK2:
+ case TPS65090_REG_CG_CTRL0:
+ case TPS65090_REG_CG_CTRL1:
+ case TPS65090_REG_CG_CTRL2:
+ case TPS65090_REG_CG_CTRL3:
+ case TPS65090_REG_CG_CTRL4:
+ case TPS65090_REG_CG_CTRL5:
return false;
+ }
+ return true;
}
static const struct regmap_config tps65090_regmap_config = {
diff --git a/drivers/power/tps65090-charger.c b/drivers/power/tps65090-charger.c
index cc26c12..31a3ba4 100644
--- a/drivers/power/tps65090-charger.c
+++ b/drivers/power/tps65090-charger.c
@@ -30,17 +30,6 @@
#include linux/mfd/tps65090.h
-#define TPS65090_REG_INTR_STS 0x00
-#define TPS65090_REG_INTR_MASK 0x02
-#define TPS65090_REG_CG_CTRL0 0x04
-#define TPS65090_REG_CG_CTRL1 0x05
-#define TPS65090_REG_CG_CTRL2 0x06
-#define TPS65090_REG_CG_CTRL3 0x07
-#define TPS65090_REG_CG_CTRL4 0x08
-#define TPS65090_REG_CG_CTRL5 0x09
-#define TPS65090_REG_CG_STATUS10x0a
-#define TPS65090_REG_CG_STATUS20x0b
-
#define TPS65090_CHARGER_ENABLEBIT(0)
#define TPS65090_VACG BIT(1)
#define TPS65090_NOITERM BIT(5)
diff --git a/include/linux/mfd/tps65090.h b/include/linux/mfd/tps65090.h
index 3f43069..45f0f9d 100644
--- a/include/linux/mfd/tps65090.h
+++ b/include/linux/mfd/tps65090.h
@@ -64,6 +64,20 @@ enum {
TPS65090_REGULATOR_MAX,
};
+/* Register addresses */
+#define TPS65090_REG_INTR_STS 0x00
+#define TPS65090_REG_INTR_STS2 0x01
+#define TPS65090_REG_INTR_MASK 0x02
+#define TPS65090_REG_INTR_MASK20x03
+#define TPS65090_REG_CG_CTRL0 0x04
+#define TPS65090_REG_CG_CTRL1 0x05
+#define TPS65090_REG_CG_CTRL2 0x06
+#define TPS65090_REG_CG_CTRL3 0x07
+#define TPS65090_REG_CG_CTRL4 0x08
+#define TPS65090_REG_CG_CTRL5 0x09
+#define TPS65090_REG_CG_STATUS10x0a
+#define TPS65090_REG_CG_STATUS20x0b
+
struct tps65090 {
struct device *dev;
struct regmap *rmap;
--
1.9.1.423.g4596e3a
--
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 3/4] drm: Introduce drm_fb_helper_prepare()
On Tue, Apr 22, 2014 at 04:42:20PM +0200, Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
To implement hotplug detection in a race-free manner, drivers must call
drm_kms_helper_poll_init() before hotplug events can be triggered. Such
events can be triggered right after any of the encoders or connectors
are initialized. At the same time, if the drm_fb_helper_hotplug_event()
helper is used by a driver, then the poll helper requires some parts of
the FB helper to be initialized to prevent a crash.
At the same time, drm_fb_helper_init() requires information that is not
necessarily available at such an early stage (number of CRTCs and
connectors), so it cannot be used yet.
Add a new helper, drm_fb_helper_prepare(), that initializes the bare
minimum needed to allow drm_kms_helper_poll_init() to execute and any
subsequent hotplug events to be processed properly.
Signed-off-by: Thierry Reding tred...@nvidia.com
Some bikeshed on the kerneldoc below, with that addressed this is
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
drivers/gpu/drm/ast/ast_fb.c | 4 ++-
drivers/gpu/drm/bochs/bochs_fbdev.c | 3 ++-
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 4 ++-
drivers/gpu/drm/drm_fb_cma_helper.c | 3 ++-
drivers/gpu/drm/drm_fb_helper.c | 43
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 3 ++-
drivers/gpu/drm/gma500/framebuffer.c | 3 ++-
drivers/gpu/drm/i915/intel_fbdev.c| 3 ++-
drivers/gpu/drm/mgag200/mgag200_fb.c | 3 ++-
drivers/gpu/drm/msm/msm_fbdev.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 3 ++-
drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 +-
drivers/gpu/drm/qxl/qxl_fb.c | 5 +++-
drivers/gpu/drm/radeon/radeon_fb.c| 4 ++-
drivers/gpu/drm/tegra/fb.c| 4 +--
drivers/gpu/drm/udl/udl_fb.c | 3 ++-
include/drm/drm_fb_helper.h | 2 ++
18 files changed, 68 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c
b/drivers/gpu/drm/armada/armada_fbdev.c
index 21aa1261dba2..9437e11d5df1 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -149,7 +149,7 @@ int armada_fbdev_init(struct drm_device *dev)
priv-fbdev = fbh;
- fbh-funcs = armada_fb_helper_funcs;
+ drm_fb_helper_prepare(dev, fbh, armada_fb_helper_funcs);
ret = drm_fb_helper_init(dev, fbh, 1, 1);
if (ret) {
diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index 2113894e4ff8..cba45c774552 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -328,8 +328,10 @@ int ast_fbdev_init(struct drm_device *dev)
return -ENOMEM;
ast-fbdev = afbdev;
- afbdev-helper.funcs = ast_fb_helper_funcs;
spin_lock_init(afbdev-dirty_lock);
+
+ drm_fb_helper_prepare(dev, afbdev-helper, ast_fb_helper_funcs);
+
ret = drm_fb_helper_init(dev, afbdev-helper,
1, 1);
if (ret) {
diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index 17e5c17f2730..19cf3e9413b6 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -189,7 +189,8 @@ int bochs_fbdev_init(struct bochs_device *bochs)
{
int ret;
- bochs-fb.helper.funcs = bochs_fb_helper_funcs;
+ drm_fb_helper_prepare(bochs-dev, bochs-fb.helper,
+ bochs_fb_helper_funcs);
ret = drm_fb_helper_init(bochs-dev, bochs-fb.helper,
1, 1);
diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index 2bd0291168e4..2a135f253e29 100644
--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -306,9 +306,11 @@ int cirrus_fbdev_init(struct cirrus_device *cdev)
return -ENOMEM;
cdev-mode_info.gfbdev = gfbdev;
- gfbdev-helper.funcs = cirrus_fb_helper_funcs;
spin_lock_init(gfbdev-dirty_lock);
+ drm_fb_helper_prepare(cdev-dev, gfbdev-helper,
+ cirrus_fb_helper_funcs);
+
ret = drm_fb_helper_init(cdev-dev, gfbdev-helper,
cdev-num_crtc, CIRRUSFB_CONN_LIMIT);
if (ret) {
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index b74f9e58b69d..acbbd230e081 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -354,9 +354,10 @@ struct drm_fbdev_cma *drm_fbdev_cma_init(struct
drm_device *dev,
return ERR_PTR(-ENOMEM);
}
- fbdev_cma-fb_helper.funcs = drm_fb_cma_helper_funcs;
helper = fbdev_cma-fb_helper;
+ drm_fb_helper_prepare(dev,
Re: ARM: dts: Remove mau_pd node for Exynos5420
Tushar, On Mon, Apr 21, 2014 at 10:39 PM, Tushar Behera tushar.beh...@linaro.org wrote: MAU powerdomain provides clocks for Audio sub-system block. This block comprises of the I2S audio controller, audio DMA blocks and Audio sub-system clock registers. Right now, there is no way to hook up power-domains with clock providers. During late boot when this power-domain gets disabled, we get following external abort. Signed-off-by: Tushar Behera tushar.beh...@linaro.org --- arch/arm/boot/dts/exynos5420.dtsi |5 - 1 file changed, 5 deletions(-) Tested-by: Doug Anderson diand...@chromium.org -- 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 v2 3/7] mfd: cros_ec: spi: Make the cros_ec_spi timeout more reliable
The cros_ec_spi transfer had two problems with its timeout code:
1. It looked at the timeout even in the case that it found valid data.
2. If the cros_ec_spi code got switched out for a while, it's possible
it could get a timeout after a single loop. Let's be paranoid and
make sure we do one last transfer after the timeout expires.
Signed-off-by: Doug Anderson diand...@chromium.org
Reviewed-by: Simon Glass s...@chromium.org
Tested-by: Andrew Bresticker abres...@chromium.org
Tested-by: Stephen Warren swar...@nvidia.com
---
Changes in v2: None
drivers/mfd/cros_ec_spi.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index a2a605d..4f863c3 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -113,7 +113,9 @@ static int cros_ec_spi_receive_response(struct
cros_ec_device *ec_dev,
/* Receive data until we see the header byte */
deadline = jiffies + msecs_to_jiffies(EC_MSG_DEADLINE_MS);
- do {
+ while (true) {
+ unsigned long start_jiffies = jiffies;
+
memset(trans, 0, sizeof(trans));
trans.cs_change = 1;
trans.rx_buf = ptr = ec_dev-din;
@@ -134,12 +136,19 @@ static int cros_ec_spi_receive_response(struct
cros_ec_device *ec_dev,
break;
}
}
+ if (ptr != end)
+ break;
- if (time_after(jiffies, deadline)) {
+ /*
+* Use the time at the start of the loop as a timeout. This
+* gives us one last shot at getting the transfer and is useful
+* in case we got context switched out for a while.
+*/
+ if (time_after(start_jiffies, deadline)) {
dev_warn(ec_dev-dev, EC failed to respond in time\n);
return -ETIMEDOUT;
}
- } while (ptr == end);
+ }
/*
* ptr now points to the header byte. Copy any valid data to the
--
1.9.1.423.g4596e3a
--
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 v2 0/7] Add cros_ec changes for newer boards
This series adds the most critical cros_ec changes for newer boards using cros_ec. Specifically: * Fixes timing/locking issues with the previously upstreamed (but never used upstream) cros_ec_spi driver. * Updates the cros_ec header file to the latest version which allows us to use newer EC features like i2c tunneling. * Adds an i2c tunnel driver to allow communication to the EC's i2c devices. This _doesn't_ get the EC driver fully up to speed with what's in the current Chromium OS trees. There are a whole slew of cleanup patches there, an addition of an LPC transport mode, and exports of functions to userspace. Once these patches land and we have functionality we can continue to pick more cleanup patches. Changes in v2: - Update tunnel binding as per swarren - Removed i2c20 alias for i2c tunnel Bill Richardson (1): mfd: cros_ec: Sync to the latest cros_ec_commands.h from EC sources David Hendricks (1): mfd: cros_ec: spi: calculate delay between transfers correctly Doug Anderson (5): mfd: cros_ec: spi: Add mutex to cros_ec_spi mfd: cros_ec: spi: Make the cros_ec_spi timeout more reliable mfd: cros_ec: spi: Increase cros_ec_spi deadline from 5ms to 100ms i2c: ChromeOS EC tunnel driver ARM: tegra: Add the EC i2c tunnel to tegra124-venice2 .../devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt | 39 + arch/arm/boot/dts/tegra124-venice2.dts | 26 + drivers/i2c/busses/Kconfig |9 + drivers/i2c/busses/Makefile|1 + drivers/i2c/busses/i2c-cros-ec-tunnel.c| 304 ++ drivers/mfd/cros_ec.c |7 +- drivers/mfd/cros_ec_spi.c | 67 +- include/linux/mfd/cros_ec.h|4 +- include/linux/mfd/cros_ec_commands.h | 1128 ++-- 9 files changed, 1493 insertions(+), 92 deletions(-) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt create mode 100644 drivers/i2c/busses/i2c-cros-ec-tunnel.c -- 1.9.1.423.g4596e3a -- 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 v2 1/7] mfd: cros_ec: spi: calculate delay between transfers correctly
From: David Hendricks dhend...@chromium.org To avoid spamming the EC we calculate the time between the previous transfer and the current transfer and force a delay if the time delta is too small. However, a small miscalculation causes the delay period to be far too short. Most noticably this impacts commands with a long turnaround time such as EC firmware reads and writes. Signed-off-by: David Hendricks dhend...@chromium.org Signed-off-by: Doug Anderson diand...@chromium.org Reviewed-by: Simon Glass s...@chromium.org Tested-by: Andrew Bresticker abres...@chromium.org Tested-by: Stephen Warren swar...@nvidia.com --- Changes in v2: None drivers/mfd/cros_ec_spi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c index 84af8d7..c185eb6 100644 --- a/drivers/mfd/cros_ec_spi.c +++ b/drivers/mfd/cros_ec_spi.c @@ -219,7 +219,7 @@ static int cros_ec_command_spi_xfer(struct cros_ec_device *ec_dev, ktime_get_ts(ts); delay = timespec_to_ns(ts) - ec_spi-last_transfer_ns; if (delay EC_SPI_RECOVERY_TIME_NS) - ndelay(delay); + ndelay(EC_SPI_RECOVERY_TIME_NS - delay); } /* Transmit phase - send our message */ -- 1.9.1.423.g4596e3a -- 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 v2 5/7] mfd: cros_ec: Sync to the latest cros_ec_commands.h from EC sources
From: Bill Richardson wfric...@chromium.org
This just updates include/linux/mfd/cros_ec_commands.h to match the
latest EC version (which is the One True Source for such things). See
https://chromium.googlesource.com/chromiumos/platform/ec
[dianders: took today's ToT version from the Chromium OS EC; deleted
references to cros_ec_dev and cros_ec_lpc since those aren't upstream
yet]
Signed-off-by: Bill Richardson wfric...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
Reviewed-by: Simon Glass s...@chromium.org
Tested-by: Andrew Bresticker abres...@chromium.org
Tested-by: Stephen Warren swar...@nvidia.com
---
Changes in v2: None
drivers/mfd/cros_ec.c|2 +-
include/linux/mfd/cros_ec.h |4 +-
include/linux/mfd/cros_ec_commands.h | 1128 +++---
3 files changed, 1059 insertions(+), 75 deletions(-)
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 783fe2e..c58ab96 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -30,7 +30,7 @@ int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
uint8_t *out;
int csum, i;
- BUG_ON(msg-out_len EC_HOST_PARAM_SIZE);
+ BUG_ON(msg-out_len EC_PROTO2_MAX_PARAM_SIZE);
out = ec_dev-dout;
out[0] = EC_CMD_VERSION0 + msg-version;
out[1] = msg-cmd;
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index 032af7f..887ef4f 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -29,8 +29,8 @@ enum {
EC_MSG_RX_PROTO_BYTES = 3,
/* Max length of messages */
- EC_MSG_BYTES= EC_HOST_PARAM_SIZE + EC_MSG_TX_PROTO_BYTES,
-
+ EC_MSG_BYTES= EC_PROTO2_MAX_PARAM_SIZE +
+ EC_MSG_TX_PROTO_BYTES,
};
/**
diff --git a/include/linux/mfd/cros_ec_commands.h
b/include/linux/mfd/cros_ec_commands.h
index 86fd069..7853a64 100644
--- a/include/linux/mfd/cros_ec_commands.h
+++ b/include/linux/mfd/cros_ec_commands.h
@@ -24,25 +24,12 @@
#define __CROS_EC_COMMANDS_H
/*
- * Protocol overview
+ * Current version of this protocol
*
- * request: CMD [ P0 P1 P2 ... Pn S ]
- * response: ERR [ P0 P1 P2 ... Pn S ]
- *
- * where the bytes are defined as follow :
- * - CMD is the command code. (defined by EC_CMD_ constants)
- * - ERR is the error code. (defined by EC_RES_ constants)
- * - Px is the optional payload.
- *it is not sent if the error code is not success.
- *(defined by ec_params_ and ec_response_ structures)
- * - S is the checksum which is the sum of all payload bytes.
- *
- * On LPC, CMD and ERR are sent/received at EC_LPC_ADDR_KERNEL|USER_CMD
- * and the payloads are sent/received at EC_LPC_ADDR_KERNEL|USER_PARAM.
- * On I2C, all bytes are sent serially in the same message.
+ * TODO(crosbug.com/p/11223): This is effectively useless; protocol is
+ * determined in other ways. Remove this once the kernel code no longer
+ * depends on it.
*/
-
-/* Current version of this protocol */
#define EC_PROTO_VERSION 0x0002
/* Command version mask */
@@ -57,13 +44,19 @@
#define EC_LPC_ADDR_HOST_CMD 0x204
/* I/O addresses for host command args and params */
-#define EC_LPC_ADDR_HOST_ARGS 0x800
-#define EC_LPC_ADDR_HOST_PARAM 0x804
-#define EC_HOST_PARAM_SIZE 0x0fc /* Size of param area in bytes */
-
-/* I/O addresses for host command params, old interface */
-#define EC_LPC_ADDR_OLD_PARAM 0x880
-#define EC_OLD_PARAM_SIZE 0x080 /* Size of param area in bytes */
+/* Protocol version 2 */
+#define EC_LPC_ADDR_HOST_ARGS0x800 /* And 0x801, 0x802, 0x803 */
+#define EC_LPC_ADDR_HOST_PARAM 0x804 /* For version 2 params; size is
+* EC_PROTO2_MAX_PARAM_SIZE */
+/* Protocol version 3 */
+#define EC_LPC_ADDR_HOST_PACKET 0x800 /* Offset of version 3 packet */
+#define EC_LPC_HOST_PACKET_SIZE 0x100 /* Max size of version 3 packet */
+
+/* The actual block is 0x800-0x8ff, but some BIOSes think it's 0x880-0x8ff
+ * and they tell the kernel that so we have to think of it as two parts. */
+#define EC_HOST_CMD_REGION00x800
+#define EC_HOST_CMD_REGION10x880
+#define EC_HOST_CMD_REGION_SIZE 0x80
/* EC command register bit functions */
#define EC_LPC_CMDR_DATA (1 0) /* Data ready for host to read */
@@ -79,18 +72,22 @@
#define EC_MEMMAP_TEXT_MAX 8 /* Size of a string in the memory map */
/* The offset address of each type of data in mapped memory. */
-#define EC_MEMMAP_TEMP_SENSOR 0x00 /* Temp sensors */
-#define EC_MEMMAP_FAN 0x10 /* Fan speeds */
-#define EC_MEMMAP_TEMP_SENSOR_B0x18 /* Temp sensors (second set) */
-#define EC_MEMMAP_ID 0x20 /* 'E' 'C' */
+#define EC_MEMMAP_TEMP_SENSOR 0x00 /* Temp sensors 0x00 - 0x0f */
+#define EC_MEMMAP_FAN 0x10 /* Fan speeds 0x10 - 0x17 */
+#define EC_MEMMAP_TEMP_SENSOR_B0x18 /* More temp
[PATCH v2 6/7] i2c: ChromeOS EC tunnel driver
On ARM Chromebooks we have a few devices that are accessed by both the
AP (the main Application Processor) and the EC (the Embedded
Controller). These are:
* The battery (sbs-battery).
* The power management unit tps65090.
On the original Samsung ARM Chromebook these devices were on an I2C
bus that was shared between the AP and the EC and arbitrated using
some extranal GPIOs (see i2c-arb-gpio-challenge).
The original arbitration scheme worked well enough but had some
downsides:
* It was nonstandard (not using standard I2C multimaster)
* It only worked if the EC-AP communication was I2C
* It was relatively hard to debug problems (hard to tell if i2c issues
were caused by the EC, the AP, or some device on the bus).
On the HP Chromebook 11 the design was changed to:
* The AP/EC comms were still i2c, but the battery/tps65090 were no
longer on the bus used for AP/EC communication. The battery was
exposed to the AP through a limited i2c tunnel and tps65090 was
exposed to the AP through a custom Linux driver.
On the Samsung ARM Chromebook 2 the scheme is changed yet again, now:
* The AP/EC comms are now using SPI for faster speeds.
* The EC's i2c bus is exposed to the AP through a full i2c tunnel.
The upstream tegra124-venice2 uses the same scheme as the Samsung
ARM Chromebook 2, though it has a different set of components on the
other side of the bus.
This driver supports the scheme used by the Samsung ARM Chromebook 2.
Future patches to this driver could add support for the battery tunnel
on the HP Chromebook 11 (and perhaps could even be used to access
tps65090 on the HP Chromebook 11 instead of using a special driver,
but I haven't researched that enough).
Signed-off-by: Vincent Palatin vpala...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
Tested-by: Andrew Bresticker abres...@chromium.org
Tested-by: Stephen Warren swar...@nvidia.com
---
Changes in v2:
- Update tunnel binding as per swarren
.../devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt | 39 +++
drivers/i2c/busses/Kconfig | 9 +
drivers/i2c/busses/Makefile| 1 +
drivers/i2c/busses/i2c-cros-ec-tunnel.c| 304 +
drivers/mfd/cros_ec.c | 5 +
5 files changed, 358 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
create mode 100644 drivers/i2c/busses/i2c-cros-ec-tunnel.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
b/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
new file mode 100644
index 000..898f030
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
@@ -0,0 +1,39 @@
+I2C bus that tunnels through the ChromeOS EC (cros-ec)
+==
+On some ChromeOS board designs we've got a connection to the EC (embedded
+controller) but no direct connection to some devices on the other side of
+the EC (like a battery and PMIC). To get access to those devices we need
+to tunnel our i2c commands through the EC.
+
+The node for this device should be under a cros-ec node like google,cros-ec-spi
+or google,cros-ec-i2c.
+
+
+Required properties:
+- compatible: google,cros-ec-i2c-tunnel
+- google,remote-bus: The EC bus we'd like to talk to.
+
+Optional child nodes:
+- One node per I2C device connected to the tunnelled I2C bus.
+
+
+Example:
+ cros-ec@0 {
+ compatible = google,cros-ec-spi;
+
+ ...
+
+ i2c-tunnel {
+ compatible = google,cros-ec-i2c-tunnel;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ google,remote-bus = 0;
+
+ battery: sbs-battery@b {
+ compatible = sbs,sbs-battery;
+ reg = 0xb;
+ sbs,poll-retry-count = 1;
+ };
+ };
+ }
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index c94db1c..9a0a6cc 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -993,6 +993,15 @@ config I2C_SIBYTE
help
Supports the SiByte SOC on-chip I2C interfaces (2 channels).
+config I2C_CROS_EC_TUNNEL
+ tristate ChromeOS EC tunnel I2C bus
+ depends on MFD_CROS_EC
+ help
+ If you say yes here you get an I2C bus that will tunnel i2c commands
+ through to the other side of the ChromeOS EC to the i2c bus
+ connected there. This will work whatever the interface used to
+ talk to the EC (SPI, I2C or LPC).
+
config SCx200_I2C
tristate NatSemi SCx200 I2C using GPIO pins (DEPRECATED)
depends on SCx200_GPIO
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 18d18ff..e110ca9 100644
---
[PATCH v2 2/7] mfd: cros_ec: spi: Add mutex to cros_ec_spi
The main transfer function for cros_ec_spi can be called by more than
one client at a time. Make sure that those clients don't stomp on
each other by locking the bus for the duration of the transfer
function.
Signed-off-by: Doug Anderson diand...@chromium.org
Reviewed-by: Simon Glass s...@chromium.org
Tested-by: Andrew Bresticker abres...@chromium.org
Tested-by: Stephen Warren swar...@nvidia.com
---
Changes in v2: None
drivers/mfd/cros_ec_spi.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index c185eb6..a2a605d 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -65,11 +65,13 @@
* if no record
* @end_of_msg_delay: used to set the delay_usecs on the spi_transfer that
* is sent when we want to turn off CS at the end of a transaction.
+ * @lock: mutex to ensure only one user of cros_ec_command_spi_xfer at a time
*/
struct cros_ec_spi {
struct spi_device *spi;
s64 last_transfer_ns;
unsigned int end_of_msg_delay;
+ struct mutex lock;
};
static void debug_packet(struct device *dev, const char *name, u8 *ptr,
@@ -208,6 +210,13 @@ static int cros_ec_command_spi_xfer(struct cros_ec_device
*ec_dev,
int ret = 0, final_ret;
struct timespec ts;
+ /*
+* We have the shared ec_dev buffer plus we do lots of separate spi_sync
+* calls, so we need to make sure only one person is using this at a
+* time.
+*/
+ mutex_lock(ec_spi-lock);
+
len = cros_ec_prepare_tx(ec_dev, ec_msg);
dev_dbg(ec_dev-dev, prepared, len=%d\n, len);
@@ -260,7 +269,7 @@ static int cros_ec_command_spi_xfer(struct cros_ec_device
*ec_dev,
ret = final_ret;
if (ret 0) {
dev_err(ec_dev-dev, spi transfer failed: %d\n, ret);
- return ret;
+ goto exit;
}
/* check response error code */
@@ -269,14 +278,16 @@ static int cros_ec_command_spi_xfer(struct cros_ec_device
*ec_dev,
dev_warn(ec_dev-dev, command 0x%02x returned an error %d\n,
ec_msg-cmd, ptr[0]);
debug_packet(ec_dev-dev, in_err, ptr, len);
- return -EINVAL;
+ ret = -EINVAL;
+ goto exit;
}
len = ptr[1];
sum = ptr[0] + ptr[1];
if (len ec_msg-in_len) {
dev_err(ec_dev-dev, packet too long (%d bytes, expected %d),
len, ec_msg-in_len);
- return -ENOSPC;
+ ret = -ENOSPC;
+ goto exit;
}
/* copy response packet payload and compute checksum */
@@ -293,10 +304,14 @@ static int cros_ec_command_spi_xfer(struct cros_ec_device
*ec_dev,
dev_err(ec_dev-dev,
bad packet checksum, expected %02x, got %02x\n,
sum, ptr[len + 2]);
- return -EBADMSG;
+ ret = -EBADMSG;
+ goto exit;
}
- return 0;
+ ret = 0;
+exit:
+ mutex_unlock(ec_spi-lock);
+ return ret;
}
static void cros_ec_spi_dt_probe(struct cros_ec_spi *ec_spi, struct device
*dev)
@@ -327,6 +342,7 @@ static int cros_ec_spi_probe(struct spi_device *spi)
if (ec_spi == NULL)
return -ENOMEM;
ec_spi-spi = spi;
+ mutex_init(ec_spi-lock);
ec_dev = devm_kzalloc(dev, sizeof(*ec_dev), GFP_KERNEL);
if (!ec_dev)
return -ENOMEM;
--
1.9.1.423.g4596e3a
--
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 v2 7/7] ARM: tegra: Add the EC i2c tunnel to tegra124-venice2
This adds the EC i2c tunnel (and devices under it) to the
tegra124-venice2 device tree.
Signed-off-by: Doug Anderson diand...@chromium.org
Tested-by: Andrew Bresticker abres...@chromium.org
Tested-by: Stephen Warren swar...@nvidia.com
---
Changes in v2:
- Removed i2c20 alias for i2c tunnel
arch/arm/boot/dts/tegra124-venice2.dts | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/tegra124-venice2.dts
b/arch/arm/boot/dts/tegra124-venice2.dts
index c17283c..89cf776 100644
--- a/arch/arm/boot/dts/tegra124-venice2.dts
+++ b/arch/arm/boot/dts/tegra124-venice2.dts
@@ -813,6 +813,32 @@
google,cros-ec-spi-msg-delay = 2000;
+ i2c-tunnel {
+ compatible = google,cros-ec-i2c-tunnel;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ google,remote-bus = 0;
+
+ charger: bq24735@9 {
+ compatible = ti,bq24735;
+ reg = 0x9;
+ interrupt-parent = gpio;
+ interrupts = TEGRA_GPIO(J, 0)
+ GPIO_ACTIVE_HIGH;
+ ti,ac-detect-gpios = gpio
+ TEGRA_GPIO(J, 0)
+ GPIO_ACTIVE_HIGH;
+ };
+
+ battery: sbs-battery@b {
+ compatible = sbs,sbs-battery;
+ reg = 0xb;
+ sbs,i2c-retry-count = 2;
+ sbs,poll-retry-count = 1;
+ };
+ };
+
cros-ec-keyb {
compatible = google,cros-ec-keyb;
keypad,num-rows = 8;
--
1.9.1.423.g4596e3a
--
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 9/9] drm/exynos: Add ps8622 lvds bridge discovery to DP driver
Hi Thierry,
On Tue, Apr 22, 2014 at 2:57 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Tue, Apr 22, 2014 at 04:09:18AM +0530, Ajay Kumar wrote:
This patch adds ps8622 lvds bridge discovery code to the dp driver.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
Changes since V1:
Pushing V1 for this as V2 because this patch holds good in this series.
drivers/gpu/drm/exynos/exynos_dp_core.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 4853f31..0006412 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -30,6 +30,7 @@
#include drm/drm_crtc_helper.h
#include drm/drm_panel.h
#include drm/bridge/ptn3460.h
+#include drm/bridge/ps8622.h
#include exynos_drm_drv.h
#include exynos_dp_core.h
@@ -999,7 +1000,15 @@ static int exynos_drm_attach_lcd_bridge(struct
drm_device *dev,
panel);
if (!ret)
return 1;
+ } else if (find_bridge(parade,ps8625, bridge)) {
So this is where the inspiration for the of_find_compatible_node() in
the earlier patch came from.
I shall use phandle for that as suggested by you for previous patches.
+ ret = ps8622_init(dev, encoder, bridge.client, bridge.node,
+ panel);
Long-term I don't think this is going to scale very well. In my opinion
it would be much more useful to have the bridge driver initialize what
it can and then have the DRM driver call a generic initialization
function to bind it to the DRM device or encoder. Otherwise we have to
keep knowledge about the type of bridge in each driver that uses it,
whereas the goal (I think) would be to create a proper abstraction so
that the DRM driver doesn't have to know that kind of detail.
Well, having a generic initialization function makes more sense when
we have multiple platforms supporting the 2 available bridge chips.
Then we can let the bridge chip initialize first, and then call a drm_bridge
search and bind function to search the bridge_list to find the bridge which has
already got registered.
But, this again poses a challenge that the bridge chip driver should
be probed before
the corresponding drm_encoder is trying to bind the bridge with
drm_device/encoder.
So, I think the current way of explicitly calling bridgeXXX_init is
fine, at least
till multiple platforms start keeping track of all possible bridges
they support,
inside their respective drivers.
Thanks and regards,
Ajay Kumar
--
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] usb: ohci-exynos: Add facility to use phy provided by the generic phy framework
On Thu, 10 Apr 2014, Vivek Gautam wrote:
Add support to consume phy provided by Generic phy framework.
Keeping the support for older usb-phy intact right now, in order
to prevent any functionality break in absence of relevant
device tree side change for ohci-exynos.
Once we move to new phy in the device nodes for ohci, we can
remove the support for older phys.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
Cc: Alan Stern st...@rowland.harvard.edu
+static int exynos_ohci_phyg_on(struct phy *phy, bool on)
+{
+ int ret = 0;
+
+ if (phy) {
+ if (on)
+ ret = phy_power_on(phy);
+ else
+ ret = phy_power_off(phy);
+ }
+
+ return ret;
+}
This would be cleaner if you had separate routines for
exynos_ohci_phyg_of and exynos_ohci_phyg_off. For example:
static int exynos_ohci_phyg_on(struct phy *phy)
{
return phy ? phy_power_on(phy) : 0;
}
@@ -88,16 +104,49 @@ static int exynos_ohci_probe(struct platform_device
*pdev)
samsung,exynos5440-ohci))
goto skip_phy;
- phy = devm_usb_get_phy(pdev-dev, USB_PHY_TYPE_USB2);
- if (IS_ERR(phy)) {
- usb_put_hcd(hcd);
- dev_warn(pdev-dev, no platform data or transceiver
defined\n);
- return -EPROBE_DEFER;
+ exynos_ohci-phy = devm_usb_get_phy(pdev-dev, USB_PHY_TYPE_USB2);
+ if (IS_ERR(exynos_ohci-phy)) {
+ err = PTR_ERR(exynos_ohci-phy);
+ if (err == -ENXIO || err == -ENODEV) {
+ exynos_ohci-phy = NULL;
+ } else if (err == -EPROBE_DEFER) {
+ usb_put_hcd(hcd);
+ return err;
+ } else {
+ dev_err(pdev-dev, no usb2 phy configured\n);
+ usb_put_hcd(hcd);
+ return err;
+ }
Instead of all the calls to usb_put_hcd() here and below, just goto
fail_clk. Or add a new fail_phy label at the same spot and goto it.
Otherwise this looks basically okay.
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] usb: ohci-exynos: Add facility to use phy provided by the generic phy framework
On Tue, 22 Apr 2014, Vivek Gautam wrote: On Thu, Apr 10, 2014 at 6:54 PM, Vivek Gautam gautam.vi...@samsung.com wrote: Add support to consume phy provided by Generic phy framework. Keeping the support for older usb-phy intact right now, in order to prevent any functionality break in absence of relevant device tree side change for ohci-exynos. Once we move to new phy in the device nodes for ohci, we can remove the support for older phys. Any comments on this please. I think whatever the approach we follow, that can be common to both ehci-exynos[1], and ohci-exynos, since both are needed to move to the new generic phy framework, keeping support for older usb-phy so as to have smooth transition, in order to avoid any regression. I lost my copies of the ehci-exynos patch, but probably the same comments apply as for the ohci-exynos patch. 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] ARM: EXYNOS: cpu hotplug: use v7_exit_coherency_flush macro for cache disabling
On Tue, 22 Apr 2014, Leela Krishna Amudala wrote:
Remove the duplicated code for cache disabling and use
v7_exit_coherency_flush
macro to do the same job.
Signed-off-by: Leela Krishna Amudala leela.kris...@linaro.org
Acked-by: Nicolas Pitre n...@linaro.org
---
cpu hotplug is tested with 3.15-rc1 on Origen(which has cortex A9) and
Arndale octa(which has cortex A7 and A15) boards.
arch/arm/mach-exynos/hotplug.c | 56
++--
1 file changed, 2 insertions(+), 54 deletions(-)
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 5eead53..9eb8d1b 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -24,56 +24,6 @@
#include common.h
#include regs-pmu.h
-static inline void cpu_enter_lowpower_a9(void)
-{
- unsigned int v;
-
- asm volatile(
-mcr p15, 0, %1, c7, c5, 0\n
-mcr p15, 0, %1, c7, c10, 4\n
- /*
- * Turn off coherency
- */
-mrc p15, 0, %0, c1, c0, 1\n
-bic %0, %0, %3\n
-mcr p15, 0, %0, c1, c0, 1\n
-mrc p15, 0, %0, c1, c0, 0\n
-bic %0, %0, %2\n
-mcr p15, 0, %0, c1, c0, 0\n
- : =r (v)
- : r (0), Ir (CR_C), Ir (0x40)
- : cc);
-}
-
-static inline void cpu_enter_lowpower_a15(void)
-{
- unsigned int v;
-
- asm volatile(
-mrc p15, 0, %0, c1, c0, 0\n
-bic %0, %0, %1\n
-mcr p15, 0, %0, c1, c0, 0\n
- : =r (v)
- : Ir (CR_C)
- : cc);
-
- flush_cache_louis();
-
- asm volatile(
- /*
- * Turn off coherency
- */
-mrc p15, 0, %0, c1, c0, 1\n
-bic %0, %0, %1\n
-mcr p15, 0, %0, c1, c0, 1\n
- : =r (v)
- : Ir (0x40)
- : cc);
-
- isb();
- dsb();
-}
-
static inline void cpu_leave_lowpower(void)
{
unsigned int v;
@@ -141,10 +91,8 @@ void __ref exynos_cpu_die(unsigned int cpu)
* appropriate sequence for entering low power.
*/
asm(mrc p15, 0, %0, c0, c0, 0 : =r(primary_part) : : cc);
- if ((primary_part 0xfff0) == 0xc0f0)
- cpu_enter_lowpower_a15();
- else
- cpu_enter_lowpower_a9();
+
+ v7_exit_coherency_flush(louis);
platform_do_lowpower(cpu, spurious);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
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] ASoC: SAMSUNG: Add sound card driver for Snow board
On Tue, Apr 22, 2014 at 07:17:54PM +0530, Tushar Behera wrote: On 22 April 2014 16:14, Mark Brown broo...@kernel.org wrote: In general this isn't up to modern standards, please do try to check that new code is following best practices. Did the support for setting the clocking up in the device tree get merged already? I didn't get this point. Would you please elaborate? The out of tree driver for these boards has a bunch of code in it which reprograms the clock tree that parents the I2S block so that the I2S block has inputs at suitable rates to allow it to generate useful outputs. Please do also pay attention to the CC lists when posting patches, this seems to have been sent to a fairly random selection of people and lists. Okay, I will update the CC list as per get_maintainer script during next revision. Please think about the results when doing that - get_maintainers is very useful but it does generate false positives and miss people. + ret = snd_soc_dai_set_clkdiv(cpu_dai, SAMSUNG_I2S_DIV_BCLK, bfs); + if (ret 0) + return ret; Set this stuff up on probe. I'm surprised that you need to set BCLK at all... Should I create a late_probe call for this (in line with tobermory.c)? Yes. signature.asc Description: Digital signature
Re: [RESEND PATCH v3 3/5] mfd: tps65090: Stop caching most registers
On Tue, Apr 22, 2014 at 08:24:56AM -0700, Doug Anderson wrote: Nearly all of the registers in tps65090 combine control bits and status bits. Turn off caching of all registers except the select few that can be cached. Lee, I don't mind if I apply this and send a pull request to you or I pull a tag from you with this in - what's easiest for you? signature.asc Description: Digital signature
Re: [PATCH 5/6] ARM: EXYNOS: Enable multi-platform build support
On Tuesday 22 April 2014, Olof Johansson wrote: I don't think there's a point in keeping this around. A single-platform config is just enabling a single platform in the config, it's not a specific option. I don't think any of the other platforms use anything like this today. The only one doing that is shmobile, but only because they have some SoCs that are multiplatform capable and some that are not. This isn't the case for Exynos, so it should no longer be needed. When I originally created this patch 18 months ago, there were a number of drivers that broke when multiplatform got enabled. Now the cpufreq driver is the only one left, but it seems that it will make it for 3.16, and I wouldn't wait for it if it doesn't. Let's just do multiplatform-only. 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] net: sxgbe: rearrange dma descriptor
From: Byungho An bh74...@samsung.com Date: Fri, 18 Apr 2014 20:59:36 +0900 This patch moves cksum_ctl to tx_rd_des23 from cksum_pktlen for correct checksum offloading and modifies size for Tx/Rx descriptor. Signed-off-by: Byungho An bh74...@samsung.com Applied, thanks. -- 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] net: sxgbe: Added phy_found error path
From: Byungho An bh74...@samsung.com Date: Fri, 18 Apr 2014 20:59:39 +0900 This patch adds phy_found error path when there is no phy device and changes bus_name. Signed-off-by: Byungho An bh74...@samsung.com Applied, thanks. -- 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 v8 1/3] ARM: EXYNOS: initial board support for exynos5260 SoC
Tomasz Figa wrote: On 16.04.2014 10:08, Sachin Kamat wrote: Hi Tomasz, On 16 April 2014 13:27, Tomasz Figa tomasz.f...@gmail.com wrote: Hi Rahul, On 16.04.2014 05:58, Rahul Sharma wrote: From: Pankaj Dubey pankaj.du...@samsung.com This patch add basic arch side support for exynos5260 SoC. Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com Signed-off-by: Rahul Sharma rahul.sha...@samsung.com Reviewed-by: Tomasz Figa t.f...@samsung.com --- arch/arm/mach-exynos/Kconfig |5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach- exynos/Kconfig index fc8bf18..bf4ed87 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -84,6 +84,11 @@ config SOC_EXYNOS5250 help Enable EXYNOS5250 SoC support +config SOC_EXYNOS5260 + bool SAMSUNG EXYNOS5260 + default y + depends on ARCH_EXYNOS5 + config SOC_EXYNOS5420 bool SAMSUNG EXYNOS5420 default y Is this patch necessary now? After Sachin's consolidation series there are no per SoC entries anymore. Kukjin still wanted individual SoCs to be selectable. Please refer [1]. [1] http://www.spinics.net/lists/devicetree/msg27040.html I don't think any valid reason was presented there. Features in code should not be selected using #ifdef CONFIG_ anymore, so I don't really see any reason to not proceed with this consolidation. Olof, Arnd? Hi, Yeah, in this case, nothing happened with adding SOC_EXYNOS5260. So I don't have any idea why this is required. - 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 v8 2/3] ARM: dts: add dts files for exynos5260 SoC
Rahul Sharma wrote:
The patch adds the dts files for exynos5260.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
Looks good to me. I will queue this 5260 SoC dtsi and 3rd xyref5260 board dt
for 3.6 and I hope I can send this series with other multi-platform for
exynos in this time ;-)
Thanks,
Kukjin
---
arch/arm/boot/dts/exynos5260-pinctrl.dtsi | 574
+
arch/arm/boot/dts/exynos5260.dtsi | 304 +++
2 files changed, 878 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5260-pinctrl.dtsi
create mode 100644 arch/arm/boot/dts/exynos5260.dtsi
diff --git a/arch/arm/boot/dts/exynos5260-pinctrl.dtsi
b/arch/arm/boot/dts/exynos5260-pinctrl.dtsi
new file mode 100644
index 000..f6ee55e
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5260-pinctrl.dtsi
@@ -0,0 +1,574 @@
+/*
+ * Samsung's Exynos5260 SoC pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung's Exynos5260 SoC pin-mux and pin-config options are listed as
device
+ * tree nodes are listed in this file.
+ *
+ * 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.
+*/
+
+#define PIN_PULL_NONE0
+#define PIN_PULL_DOWN1
+#define PIN_PULL_UP 3
+
+pinctrl_0 {
+ gpa0: gpa0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpa1: gpa1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpa2: gpa2 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpb0: gpb0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpb1: gpb1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpb2: gpb2 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpb3: gpb3 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpb4: gpb4 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpb5: gpb5 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpd0: gpd0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpd1: gpd1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpd2: gpd2 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpe0: gpe0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpe1: gpe1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpf0: gpf0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpf1: gpf1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpk0: gpk0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpx0: gpx0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpx1: gpx1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpx2: gpx2 {
+ gpio-controller;
+
RE: [PATCH v2] ARM: dts: disable MDMA1 node for Exynos5420
Javi Merino wrote: On Tue, Apr 22, 2014 at 02:05:26PM +0100, Seungwon Jeon wrote: This change places MDMA1 in disabled node for Exynos5420. If MDMA1 region is configured with secure mode, it makes the boot failure with the following on smdk5420 board. (Unhandled fault: imprecise external abort (0x1406) at 0x) Thus, arndale-octa board don't need to do the same thing anymore. Signed-off-by: Seungwon Jeon tgih@samsung.com I've had some problem applying it (wrong EOL?). Not sure if it's my Probably, it is due to Seungwon's e-mail client ;-) email client. In any case, I've manually fixed the rejects and tested it in my Arndale Octa. It works for me so Tested-by: Javi Merino javi.mer...@arm.com Anyway, thanks for your test. I will apply but I'm not sure this is critical bug or not for smdk5420... 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
[PATCH] mmc: dw_mmc: Don't print data errors
Data errors are completely expected during tuning. Printing them out is confusing people looking at the kernel logs. They see things like: [3.613296] dwmmc_exynos 1220.dwmmc0: data error, status 0x0088 ...and they think something is wrong with their hardware. Remove the printouts. We'll leave it up to a higher level to report about errors. Signed-off-by: Doug Anderson diand...@chromium.org --- drivers/mmc/host/dw_mmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c index cced599..4c8d423 100644 --- a/drivers/mmc/host/dw_mmc.c +++ b/drivers/mmc/host/dw_mmc.c @@ -1248,7 +1248,7 @@ static int dw_mci_data_complete(struct dw_mci *host, struct mmc_data *data) data-error = -EIO; } - dev_err(host-dev, data error, status 0x%08x\n, status); + dev_dbg(host-dev, data error, status 0x%08x\n, status); /* * After an error, there may be data lingering -- 1.9.1.423.g4596e3a -- 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: [RFC v2 PATCH 02/14] drm/exynos: dsi: delay setting clocks after reset
Hi Andrzej
Thank you for comments.
On 04/22/2014 09:15 PM, Andrzej Hajda wrote:
Hi YoungJun,
On 04/21/2014 02:28 PM, YoungJun Cho wrote:
Some phy control registers are not kept after software reset.
So this patch makes the clocks containing phy control to be set
after software reset.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 956e5f3..2cf1f0b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -946,10 +946,10 @@ static irqreturn_t exynos_dsi_irq(int irq, void *dev_id)
static int exynos_dsi_init(struct exynos_dsi *dsi)
{
- exynos_dsi_enable_clock(dsi);
exynos_dsi_reset(dsi);
enable_irq(dsi-irq);
exynos_dsi_wait_for_reset(dsi);
+ exynos_dsi_enable_clock(dsi);
exynos_dsi_init_link(dsi);
return 0;
I have commented it in the previous version of the patchset. I repeat it
again.
This is a regression, on exynos4210-trats I have 'timeout waiting for
reset' message after dpms off, on.
I'm really sorry for that. I misunderstood last time.
I think the original codes were correct, because the reset timeout would
be occurred without clock activation.
I'll check and fix again.
(By the way, why am I ok?)
I will comment your previous answer here to make the discussion easier:
As I mentioned in description, it came from phy control registers.
Fortunately Exynos4 SoCs are safe, but the DSIM_PHYCTRL_REG,
DSIM_PHYTIMING_REG, DSIM_PHYTIMING1_REG and DSIM_PHYTIMING2_REG are
affected which are used in exynos_dsi_set_pll() for Exynos5 SoCs.
So this patch is required for Exynos5 SoCs.
In the moment this patch is applied exynos_dsi_set_pll do not touch phy
registers you have mentioned.
Your change would be more clear if it will be merged together with the
patch adding PHYCTRL settings.
Anyway, solution is simple - please set PHY registers after reset and
configure clocks before reset to avoid
reset timeouts, is there any reason to not do it this way?
The only reason is that the PHY control is related with PLL control and
that was in exynos_dsi_enable_clock() call path.
So I just wanted to keep current sequence.
If there is no way to use previous one, I'll consider your approach.
Thank you.
Best regards YJ
Regards
Andrzej
--
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 v11 20/27] iommu/exynos: allow having multiple System MMUs for a master H/W
On Tue, 22 Apr 2014 18:53:51 +0530, Shaik Ameer Basha wrote:
Hi KyongHo Cho,
On Fri, Mar 14, 2014 at 10:40 AM, Cho KyongHo pullip@samsung.com wrote:
Some master device descriptor like fimc-is which is an abstraction
of very complex H/W may have multiple System MMUs. For those devices,
the design of the link between System MMU and its master H/W is needed
to be reconsidered.
A link structure, sysmmu_list_data is introduced that provides a link
to master H/W and that has a pointer to the device descriptor of a
System MMU. Given a device descriptor of a master H/W, it is possible
to traverse all System MMUs that must be controlled along with the
master H/W.
Signed-off-by: Cho KyongHo pullip@samsung.com
---
drivers/iommu/exynos-iommu.c | 534
++
1 file changed, 333 insertions(+), 201 deletions(-)
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 84ba29a..7489343 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -128,6 +128,10 @@
#define __master_clk_disable(data) __clk_gate_ctrl(data, clk_master,
dis)
[snip]
+static int __init __sysmmu_init_master(struct device *dev)
+{
+ int ret;
+ int i = 0;
+ struct device_node *node;
+
+ while ((node = of_parse_phandle(dev-of_node, mmu-masters, i++)))
{
struct platform_device *master =
of_find_device_by_node(node);
+ struct exynos_iommu_owner *owner;
+ struct sysmmu_list_data *list_data;
if (!master) {
dev_err(dev, %s: mmu-master '%s' not found\n,
__func__, node-name);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err;
}
- if (master-dev.archdata.iommu != NULL) {
- dev_err(dev, %s: '%s' is master of other MMU\n,
- __func__, node-name);
- return -EINVAL;
+ owner = master-dev.archdata.iommu;
+ if (!owner) {
+ owner = devm_kzalloc(dev, sizeof(*owner),
GFP_KERNEL);
+ if (!owner) {
+ dev_err(dev,
+ %s: Failed to allocate owner structure\n,
+ __func__);
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ INIT_LIST_HEAD(owner-mmu_list);
+ INIT_LIST_HEAD(owner-client);
+ owner-dev = master-dev;
+ spin_lock_init(owner-lock);
+
+ master-dev.archdata.iommu = owner;
}
+ list_data = devm_kzalloc(dev, sizeof(*list_data),
GFP_KERNEL);
+ if (!list_data) {
+ dev_err(dev,
+ %s: Failed to allocate sysmmu_list_data\n,
+ __func__);
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ INIT_LIST_HEAD(list_data-entry);
+ list_data-sysmmu = dev;
+
/*
-* archdata.iommu will be initialized with
exynos_iommu_client
-* in sysmmu_hook_driver_register().
+* System MMUs are attached in the order of the presence
+* in device tree
*/
- master-dev.archdata.iommu = dev;
+ list_add_tail(list_data-entry, owner-mmu_list);
}
- data-sysmmu = dev;
- rwlock_init(data-lock);
+ return 0;
+err:
+ while ((node = of_parse_phandle(dev-of_node, mmu-masters, i++)))
{
Don't we need to reinitialize variable 'i' here before using?
i = 0;
Oh. You are right.
Thanks.
+ struct platform_device *master =
of_find_device_by_node(node);
+ struct exynos_iommu_owner *owner;
+ struct sysmmu_list_data *list_data;
- platform_set_drvdata(pdev, data);
+ if (!master)
+ continue;
- pm_runtime_enable(dev);
- data-runtime_active = !pm_runtime_enabled(dev);
+ owner = master-dev.archdata.iommu;
+ if (!owner)
+ continue;
- dev_dbg(dev, Probed and initialized\n);
- return 0;
+ for_each_sysmmu_list(owner-dev, list_data) {
+ if (list_data-sysmmu == dev) {
+ list_del(list_data-entry);
+ kfree(list_data);
+
Re: [RFC v2 PATCH v2 06/14] drm/exynos: support MIPI DSI command mode
Hi Thierry
Thank you for the comments.
On 04/22/2014 04:34 PM, Thierry Reding wrote:
On Mon, Apr 21, 2014 at 09:28:33PM +0900, YoungJun Cho wrote:
[...]
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 7209df1..244d197 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -49,6 +49,7 @@ struct mipi_dsi_msg {
* @detach: detach DSI device from DSI host
* @transfer: send and/or receive DSI packet, return number of received bytes,
* or error
+ * @te_handler: call CRTC TE handler callback from DSI host
Perhaps you can explain some more what this means or why it would be
necessary.
I'll enhance the explanation.
For your information, the panel generates Tearing Effect signal
to synchronize between the MCU and Frame Memory Writing when displays
video images.
The display controller requires this signal to trigger video images,
and there is no way to receive this signal directly.
So the panel receive this signal as an IRQ and calls te_handler() chain
for the display controller to trigger video image at that time.
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index c2ab77a..0ad64ed 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -46,6 +46,13 @@ struct drm_panel {
struct list_head list;
};
+struct drm_panel_cpu_timings {
+ unsigned int cs_setup;
+ unsigned int wr_setup;
+ unsigned int wr_act;
+ unsigned int wr_hold;
+};
Similarily here. What's this?
I'll enhance the explanation also.
In panel DT bindings, I already explained them.
Thank you.
Best regards YJ
Thierry
--
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: [RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings
Hi Andrzej
Thank you for comment.
On 04/22/2014 11:02 PM, Andrzej Hajda wrote:
On 04/21/2014 02:28 PM, YoungJun Cho wrote:
This patch adds DT bindings for s6e3fa0 panel.
The bindings describes panel resources, display timings and cpu timings.
Changelog v2:
- Adds unit address (commented by Sachin Kamat)
Changelog v3:
- Removes optional delay, size properties (commented by Laurent Pinchart)
- Adds OLED detection, TE gpio properties
Changelog v4:
- Moves CPU timings relevant properties from FIMD DT
(commeted by Laurent Pinchart, Andrzej Hajda)
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/panel/samsung,s6e3fa0.txt | 63
1 file changed, 63 insertions(+)
create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
new file mode 100644
index 000..9eeb38b
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
@@ -0,0 +1,63 @@
+Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
+
+Required properties:
+ - compatible: samsung,s6e3fa0
+ - reg: the virtual channel number of a DSI peripheral
+ - vdd3-supply: core voltage supply
+ - vci-supply: voltage supply for analog circuits
+ - reset-gpio: a GPIO spec for the reset pin
+ - det-gpio: a GPIO spec for the OLED detection pin
+ - te-gpio: a GPIO spec for the TE pin
Just FYI, according to DT documentation [1] gpio spec should be in form
[name]-gpios, however there is plenty bindings with -gpio suffix, so I
am not sure if it is really enforced. On the other side it is enforced
by descriptor based gpio framework[2]. Integer-based gpio framework
used in your driver is obsolete according to [2].
Yes, you're right. That is my mistake.
They should be attached 's'.
At first I used integer-based gpio framework and replaced to descriptor
based one, but did not updated DT bindings.
I'll update again.
Thank you.
Best regards YJ
[1]: Documentation/devicetree/bindings/gpio/gpio.txt
[2]: Documentation/gpio/gpio.txt
Regards
Andrzej
+ - display-timings: timings for the connected panel as described by [1]
+ - cpu-timings: CPU interface timings for the connected panel, and it contains
+following optional properties.
+ - cs-setup: clock cycles for the active period of address signal
+enable until chip select is enable in CPU interface
+ - wr-setup: clock cycles for the active period of CS signal enable
+until write signal is enable in CPU interface
+ - wr-act: clock cycles for the active period of CS enable in CPU
+interface
+ - wr-hold: clock cycles for the active period of CS disable until
+write signal is disable in CPU interface
+
+Optional properties:
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in [2]. This
+node should describe panel's video bus.
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+ panel@0 {
+ compatible = samsung,s6e3fa0;
+ reg = 0;
+ vdd3-supply = vcclcd_reg;
+ vci-supply = vlcd_reg;
+ reset-gpio = gpy7 4 0;
+ det-gpio = gpg0 6 0;
+ te-gpio = gpd1 7 0;
+
+ display-timings {
+ timing0: timing-0 {
+ clock-frequency = 0;
+ hactive = 1080;
+ vactive = 1920;
+ hfront-porch = 2;
+ hback-porch = 2;
+ hsync-len = 1;
+ vfront-porch = 1;
+ vback-porch = 4;
+ vsync-len = 1;
+ };
+ };
+
+ cpu-timings {
+ cs-setup = 0;
+ wr-setup = 0;
+ wr-act = 1;
+ wr-hold = 0;
+ };
+ };
--
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] ASoC: SAMSUNG: Add sound card driver for Snow board
On 23 April 2014 00:03, Mark Brown broo...@kernel.org wrote: On Tue, Apr 22, 2014 at 07:17:54PM +0530, Tushar Behera wrote: On 22 April 2014 16:14, Mark Brown broo...@kernel.org wrote: In general this isn't up to modern standards, please do try to check that new code is following best practices. Did the support for setting the clocking up in the device tree get merged already? I didn't get this point. Would you please elaborate? The out of tree driver for these boards has a bunch of code in it which reprograms the clock tree that parents the I2S block so that the I2S block has inputs at suitable rates to allow it to generate useful outputs. Currently the clocks are configured through clk-exynos-audss.c. The reparenting of I2S bus clock is not done anymore, but is left to use the default value set in bootloader. With default setup (XXTI as the parent), I have tested wave files with various sample rates on Snow. The missing part right now is setting XCLKOUT (mclk for the audio codec) properly. In internal tree, I have directly programmed the XCLKOUT register (we don't have a clock for it as this register is not part of clock domain). I am now working on preparing a clock provider for XCLKOUT. Please do also pay attention to the CC lists when posting patches, this seems to have been sent to a fairly random selection of people and lists. Okay, I will update the CC list as per get_maintainer script during next revision. Please think about the results when doing that - get_maintainers is very useful but it does generate false positives and miss people. I will do my best to add relevant people in the discussion. + ret = snd_soc_dai_set_clkdiv(cpu_dai, SAMSUNG_I2S_DIV_BCLK, bfs); + if (ret 0) + return ret; Set this stuff up on probe. I'm surprised that you need to set BCLK at all... Should I create a late_probe call for this (in line with tobermory.c)? Yes. Ok. Thanks. -- Tushar Behera -- 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: [RFC v2 PATCH 02/14] drm/exynos: dsi: delay setting clocks after reset
Hi again Andrzej,
On 04/23/2014 10:01 AM, YoungJun Cho wrote:
Hi Andrzej
Thank you for comments.
On 04/22/2014 09:15 PM, Andrzej Hajda wrote:
Hi YoungJun,
On 04/21/2014 02:28 PM, YoungJun Cho wrote:
Some phy control registers are not kept after software reset.
So this patch makes the clocks containing phy control to be set
after software reset.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 956e5f3..2cf1f0b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -946,10 +946,10 @@ static irqreturn_t exynos_dsi_irq(int irq, void
*dev_id)
static int exynos_dsi_init(struct exynos_dsi *dsi)
{
-exynos_dsi_enable_clock(dsi);
exynos_dsi_reset(dsi);
enable_irq(dsi-irq);
exynos_dsi_wait_for_reset(dsi);
+exynos_dsi_enable_clock(dsi);
exynos_dsi_init_link(dsi);
return 0;
I have commented it in the previous version of the patchset. I repeat it
again.
This is a regression, on exynos4210-trats I have 'timeout waiting for
reset' message after dpms off, on.
I'm really sorry for that. I misunderstood last time.
I think the original codes were correct, because the reset timeout would
be occurred without clock activation.
This is not true.
I'll check and fix again.
(By the way, why am I ok?)
I have not verified with exynos4210-trats board yet(I have to get it),
but reset timeout is occured in exynos_dsi_wait_for_reset()
with dsi-completed and that is completed by exynos_dsi_irq().
And the regulators and clocks are enabled by exynos_dsi_poweron(),
NOT by exynos_dsi_enable_clock().
So I think the reset timeout is not related with this patch.
Anyway I need more investigation.
Thank you.
Best regards YJ
I will comment your previous answer here to make the discussion easier:
As I mentioned in description, it came from phy control registers.
Fortunately Exynos4 SoCs are safe, but the DSIM_PHYCTRL_REG,
DSIM_PHYTIMING_REG, DSIM_PHYTIMING1_REG and DSIM_PHYTIMING2_REG are
affected which are used in exynos_dsi_set_pll() for Exynos5 SoCs.
So this patch is required for Exynos5 SoCs.
In the moment this patch is applied exynos_dsi_set_pll do not touch phy
registers you have mentioned.
Your change would be more clear if it will be merged together with the
patch adding PHYCTRL settings.
Anyway, solution is simple - please set PHY registers after reset and
configure clocks before reset to avoid
reset timeouts, is there any reason to not do it this way?
The only reason is that the PHY control is related with PLL control and
that was in exynos_dsi_enable_clock() call path.
So I just wanted to keep current sequence.
If there is no way to use previous one, I'll consider your approach.
Thank you.
Best regards YJ
Regards
Andrzej
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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] mmc: dw_mmc: exynos: Turn SDIO interrupts on
Hi Yuvaraj, On Mon, Mar 24, 2014 at 10:12 AM, Yuvaraj Kumar yuvaraj...@gmail.com wrote: On Mon, Mar 24, 2014 at 9:59 AM, Jaehoon Chung jh80.ch...@samsung.com wrote: Hi, Yuvaraj. NACK. we can use mmc_of_parese(). Thanks Jaehoon for the pointer.I will use mmc_of_parse(). Are you planning to re-spin this patch? Now Jaehoon's changes for using mmc_of_parse() is landed in mmc-next. Thanks!! I have sent the patch that use mmc_of_parse(). https://patchwork.kernel.org/patch/3750681/ Best Regards, Jaehoon Chung On 03/24/2014 01:23 PM, Yuvaraj Kumar C D wrote: The mmc part in exynos supports SDIO interrupts and they work fine, so turn the capability on. With this I see download speeds increase about 10x. This V1 of this patch is posted to LKML at https://patchwork.kernel.org/patch/2429661/) by Doug Anderson. Signed-off-by: Doug Anderson diand...@chromium.org Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com --- drivers/mmc/host/dw_mmc.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c index 0c56faa..240949d 100644 --- a/drivers/mmc/host/dw_mmc.c +++ b/drivers/mmc/host/dw_mmc.c @@ -2417,6 +2417,9 @@ static struct dw_mci_board *dw_mci_parse_dt(struct dw_mci *host) if (of_get_property(np, cd-inverted, NULL)) pdata-caps2 |= MMC_CAP2_CD_ACTIVE_HIGH; + if (of_find_property(np, cap-sdio-irq, NULL)) + pdata-caps |= MMC_CAP_SDIO_IRQ; + return pdata; } -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Regards, Alim -- 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: EXYNOS: cpu hotplug: use v7_exit_coherency_flush macro for cache disabling
Hi Daniel,
Thanks for reviewing the patch.
On Tue, Apr 22, 2014 at 8:06 PM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
On 04/22/2014 04:18 PM, Leela Krishna Amudala wrote:
Remove the duplicated code for cache disabling and use
v7_exit_coherency_flush
macro to do the same job.
Hi Leela,
thanks for this patch! It would be nice if you can describe why those macros
can be replaced by the generic v7_exit_coherency_flush macro.
Okay, will give the description in commit message
Signed-off-by: Leela Krishna Amudala leela.kris...@linaro.org
---
cpu hotplug is tested with 3.15-rc1 on Origen(which has cortex A9) and
Arndale octa(which has cortex A7 and A15) boards.
arch/arm/mach-exynos/hotplug.c | 56
++--
1 file changed, 2 insertions(+), 54 deletions(-)
diff --git a/arch/arm/mach-exynos/hotplug.c
b/arch/arm/mach-exynos/hotplug.c
index 5eead53..9eb8d1b 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -24,56 +24,6 @@
#include common.h
#include regs-pmu.h
-static inline void cpu_enter_lowpower_a9(void)
-{
- unsigned int v;
-
- asm volatile(
- mcr p15, 0, %1, c7, c5, 0\n
- mcr p15, 0, %1, c7, c10, 4\n
- /*
-* Turn off coherency
-*/
- mrc p15, 0, %0, c1, c0, 1\n
- bic %0, %0, %3\n
- mcr p15, 0, %0, c1, c0, 1\n
- mrc p15, 0, %0, c1, c0, 0\n
- bic %0, %0, %2\n
- mcr p15, 0, %0, c1, c0, 0\n
- : =r (v)
- : r (0), Ir (CR_C), Ir (0x40)
- : cc);
-}
-
-static inline void cpu_enter_lowpower_a15(void)
-{
- unsigned int v;
-
- asm volatile(
- mrc p15, 0, %0, c1, c0, 0\n
- bic %0, %0, %1\n
- mcr p15, 0, %0, c1, c0, 0\n
- : =r (v)
- : Ir (CR_C)
- : cc);
-
- flush_cache_louis();
-
- asm volatile(
- /*
- * Turn off coherency
- */
- mrc p15, 0, %0, c1, c0, 1\n
- bic %0, %0, %1\n
- mcr p15, 0, %0, c1, c0, 1\n
- : =r (v)
- : Ir (0x40)
- : cc);
-
- isb();
- dsb();
-}
-
static inline void cpu_leave_lowpower(void)
{
unsigned int v;
@@ -141,10 +91,8 @@ void __ref exynos_cpu_die(unsigned int cpu)
* appropriate sequence for entering low power.
*/
asm(mrc p15, 0, %0, c0, c0, 0 : =r(primary_part) : : cc);
Can't you remove this asm line above as well as the primary_part variable ?
Didn't notice it, will remove this.
- if ((primary_part 0xfff0) == 0xc0f0)
- cpu_enter_lowpower_a15();
- else
- cpu_enter_lowpower_a9();
+
+ v7_exit_coherency_flush(louis);
platform_do_lowpower(cpu, spurious);
--
http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog
--
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 V2] ARM: EXYNOS: cpu hotplug: use v7_exit_coherency_flush macro for cache disabling
A common macro v7_exit_coherency_flush available which does the below tasks in
the seqeunce.
-clearing C bit
-clearing L1 cache
-exit SMP
-instruction and data synchronization
So removing the local functions which does the same thing and use the macro
instead.
Signed-off-by: Leela Krishna Amudala leela.kris...@linaro.org
Acked-by: Nicolas Pitre n...@linaro.org
---
Changes since V1:
- removed unwanted primary_part variable in exynos_cpu_die()
- given more description in commit message
suggested by Daniel Lezcano daniel.lezc...@linaro.org
arch/arm/mach-exynos/hotplug.c | 63 +---
1 file changed, 1 insertion(+), 62 deletions(-)
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 5eead53..9ca692d 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -24,56 +24,6 @@
#include common.h
#include regs-pmu.h
-static inline void cpu_enter_lowpower_a9(void)
-{
- unsigned int v;
-
- asm volatile(
- mcr p15, 0, %1, c7, c5, 0\n
- mcr p15, 0, %1, c7, c10, 4\n
- /*
-* Turn off coherency
-*/
- mrc p15, 0, %0, c1, c0, 1\n
- bic %0, %0, %3\n
- mcr p15, 0, %0, c1, c0, 1\n
- mrc p15, 0, %0, c1, c0, 0\n
- bic %0, %0, %2\n
- mcr p15, 0, %0, c1, c0, 0\n
- : =r (v)
- : r (0), Ir (CR_C), Ir (0x40)
- : cc);
-}
-
-static inline void cpu_enter_lowpower_a15(void)
-{
- unsigned int v;
-
- asm volatile(
- mrc p15, 0, %0, c1, c0, 0\n
- bic %0, %0, %1\n
- mcr p15, 0, %0, c1, c0, 0\n
- : =r (v)
- : Ir (CR_C)
- : cc);
-
- flush_cache_louis();
-
- asm volatile(
- /*
- * Turn off coherency
- */
- mrc p15, 0, %0, c1, c0, 1\n
- bic %0, %0, %1\n
- mcr p15, 0, %0, c1, c0, 1\n
- : =r (v)
- : Ir (0x40)
- : cc);
-
- isb();
- dsb();
-}
-
static inline void cpu_leave_lowpower(void)
{
unsigned int v;
@@ -132,19 +82,8 @@ static inline void platform_do_lowpower(unsigned int cpu,
int *spurious)
void __ref exynos_cpu_die(unsigned int cpu)
{
int spurious = 0;
- int primary_part = 0;
- /*
-* we're ready for shutdown now, so do it.
-* Exynos4 is A9 based while Exynos5 is A15; check the CPU part
-* number by reading the Main ID register and then perform the
-* appropriate sequence for entering low power.
-*/
- asm(mrc p15, 0, %0, c0, c0, 0 : =r(primary_part) : : cc);
- if ((primary_part 0xfff0) == 0xc0f0)
- cpu_enter_lowpower_a15();
- else
- cpu_enter_lowpower_a9();
+ v7_exit_coherency_flush(louis);
platform_do_lowpower(cpu, spurious);
--
1.7.9.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
