Re: [PATCH 3/7] video: exynos_mipi_dsim: Use the generic PHY driver
On Fri, OCT 25, 2013 06:57, Sylwester Nawrocki wrote: On 10/24/2013 05:57 PM, Kishon Vijay Abraham I wrote: On Thursday 24 October 2013 09:12 PM, Sachin Kamat wrote: On 24 October 2013 20:00, Olof Johanssono...@lixom.net wrote: On Wed, Oct 16, 2013 at 9:28 AM, Kishon Vijay Abraham Ikis...@ti.com wrote: diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c index 32e5406..00b3a52 100644 --- a/drivers/video/exynos/exynos_mipi_dsi.c +++ b/drivers/video/exynos/exynos_mipi_dsi.c @@ -156,8 +157,7 @@ static int exynos_mipi_dsi_blank_mode(struct mipi_dsim_device *dsim, int power) exynos_mipi_regulator_enable(dsim); /* enable MIPI-DSI PHY. */ - if (dsim-pd-phy_enable) - dsim-pd-phy_enable(pdev, true); + phy_power_on(dsim-phy); clk_enable(dsim-clock); This introduces the below with exynos_defconfig: ../../drivers/video/exynos/exynos_mipi_dsi.c: In function 'exynos_mipi_dsi_blank_mode': ../../drivers/video/exynos/exynos_mipi_dsi.c:144:26: warning: unused variable 'pdev' [-Wunused-variable] struct platform_device *pdev = to_platform_device(dsim-dev); Sorry about missing that, I only noticed this warning recently and didn't get around to submit a patch. I have already submitted a patch to fix this [1] Thanks a lot guys for fixing this. [1] http://marc.info/?l=linux-fbdevm=138233359617936w=2 Sorry, missed that :-( This MIPI DSIM driver is affectively a dead code in the mainline now, once Exynos become a dt-only platform. I guess it can be deleted for 3.14, once S5P gets converted to the device tree. The new driver using CDF is basically a complete rewrite. Or device tree support should be added to that driver, but I believe it doesn't make sense without CDF. MIPI DSIM driver is not a dead code. There is a steady trickle of patches. It's kind of late, but, I will update it as DT based drivers as soon as possible. And Why do you think that DT support of existing MIPI DSIM is something less than great? -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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] Documentation/watchdog: Update node name in samsung-wdt example
Update the name as per DT naming convention.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
.../devicetree/bindings/watchdog/samsung-wdt.txt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
b/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
index 4c798e3..0642fb8 100644
--- a/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
@@ -17,7 +17,7 @@ Optional properties:
Example:
-watchdog {
+watchdog@101D {
compatible = samsung,s3c2410-wdt;
reg = 0x101D 0x100, 0x10040408 0x4, 0x1004040c 0x4;
interrupts = 0 42 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] Documentation/watchdog: Update node name in samsung-wdt example
On Mon, Oct 28, 2013 at 06:24:17AM +, Sachin Kamat wrote:
Update the name as per DT naming convention.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Acked-by: Mark Rutland mark.rutl...@arm.com
---
.../devicetree/bindings/watchdog/samsung-wdt.txt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
b/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
index 4c798e3..0642fb8 100644
--- a/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
@@ -17,7 +17,7 @@ Optional properties:
Example:
-watchdog {
+watchdog@101D {
compatible = samsung,s3c2410-wdt;
reg = 0x101D 0x100, 0x10040408 0x4, 0x1004040c 0x4;
interrupts = 0 42 0;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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/7] video: exynos_mipi_dsim: Use the generic PHY driver
Hi Donghwa, On Monday 28 of October 2013 15:12:08 Donghwa Lee wrote: On Fri, OCT 25, 2013 06:57, Sylwester Nawrocki wrote: On 10/24/2013 05:57 PM, Kishon Vijay Abraham I wrote: On Thursday 24 October 2013 09:12 PM, Sachin Kamat wrote: On 24 October 2013 20:00, Olof Johanssono...@lixom.net wrote: On Wed, Oct 16, 2013 at 9:28 AM, Kishon Vijay Abraham Ikis...@ti.com wrote: diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c index 32e5406..00b3a52 100644 --- a/drivers/video/exynos/exynos_mipi_dsi.c +++ b/drivers/video/exynos/exynos_mipi_dsi.c @@ -156,8 +157,7 @@ static int exynos_mipi_dsi_blank_mode(struct mipi_dsim_device *dsim, int power) exynos_mipi_regulator_enable(dsim); /* enable MIPI-DSI PHY. */ - if (dsim-pd-phy_enable) - dsim-pd-phy_enable(pdev, true); + phy_power_on(dsim-phy); clk_enable(dsim-clock); This introduces the below with exynos_defconfig: ../../drivers/video/exynos/exynos_mipi_dsi.c: In function 'exynos_mipi_dsi_blank_mode': ../../drivers/video/exynos/exynos_mipi_dsi.c:144:26: warning: unused variable 'pdev' [-Wunused-variable] struct platform_device *pdev = to_platform_device(dsim-dev); Sorry about missing that, I only noticed this warning recently and didn't get around to submit a patch. I have already submitted a patch to fix this [1] Thanks a lot guys for fixing this. [1] http://marc.info/?l=linux-fbdevm=138233359617936w=2 Sorry, missed that :-( This MIPI DSIM driver is affectively a dead code in the mainline now, once Exynos become a dt-only platform. I guess it can be deleted for 3.14, once S5P gets converted to the device tree. The new driver using CDF is basically a complete rewrite. Or device tree support should be added to that driver, but I believe it doesn't make sense without CDF. MIPI DSIM driver is not a dead code. There is a steady trickle of patches. It's kind of late, but, I will update it as DT based drivers as soon as possible. And Why do you think that DT support of existing MIPI DSIM is something less than great? First of all, the exynos_mipi_dsim driver has currently no users in mainline kernel, so it is essentially dead code. In addition, on a platform that is the primary candidate for using it, which is Exynos, there is no way to use it, due to no DT support. As for the driver itself, it is not really a great example of good code. It contains a hacks, like calling msleep() without any clear reason and also many coding style issues. I'd prefer to replace it with the new exynos-dsi driver rewritten completely in SRPOL, when CDF is finished. Best regards, Tomasz -- 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] Documentation/watchdog: Update node name in samsung-wdt example
On 10/27/2013 11:24 PM, Sachin Kamat wrote: Update the name as per DT naming convention. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Reviewed-by: Guenter Roeck li...@roeck-us.net -- 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] Documentation/watchdog: Update node name in samsung-wdt example
On 10/27/2013 11:24 PM, Sachin Kamat wrote:
Update the name as per DT naming convention.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
.../devicetree/bindings/watchdog/samsung-wdt.txt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
b/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
index 4c798e3..0642fb8 100644
--- a/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
@@ -17,7 +17,7 @@ Optional properties:
Example:
-watchdog {
+watchdog@101D {
compatible = samsung,s3c2410-wdt;
reg = 0x101D 0x100, 0x10040408 0x4, 0x1004040c 0x4;
interrupts = 0 42 0;
Sachin,
It appears that this patch depends on some other patch which is not upstream
yet.
It is not in -next either. Can you point to that other patch ?
Thanks,
Guenter
--
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 0/7] drm/exynos: move hdmiphy related code to hdmiphy driver
Hi Rahul, I have merged the re-factoring patch set from Sean Paul to exynos-drm-next except eDP related patch set that these need more reviews. Can you re-base at top of exynos-drm-next? Thanks, Inki Dae 2013/10/22 Rahul Sharma rahul.sha...@samsung.com: Currently, exynos hdmiphy operations and configs are kept inside the hdmi driver. Hdmiphy related code is very tightly coupled with hdmi IP driver. With these patches, hdmiphy related stuff is moved to hdmiphy i2c driver for exynos4 and exynos5250 socs. hdmi driver, being the phy controller, calls exynos hdmiphy interfaces. This series also removes hdmiphy dummy clock for hdmiphy and replace it with Phy PMU Control from the hdmiphy driver. At the end, support for exynos5420 hdmiphy is added to the hdmiphy platform driver. Drm related paches are based on exynos-drm-next branch at git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git Arch related paches are based on for-next branch at http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git Rahul Sharma (7): drm/exynos: move hdmiphy code to hdmiphy i2c driver drm/exynos: remove dummy hdmiphy clock drm/exynos: add hdmiphy platform driver for exynos5420 drm/exynos: add hdmiphy pmu bit control in hdmiphy drivers exynos/drm: fix ddc i2c device probe failure ARM: dts: update hdmiphy dt node for exynos5250 ARM: dts: update hdmiphy dt node for exynos5420 .../devicetree/bindings/video/exynos_hdmi.txt |2 + .../devicetree/bindings/video/exynos_hdmiphy.txt |8 +- arch/arm/boot/dts/exynos5250-smdk5250.dts |9 +- arch/arm/boot/dts/exynos5420.dtsi | 14 +- drivers/gpu/drm/exynos/Makefile|3 +- drivers/gpu/drm/exynos/exynos_ddc.c|5 + drivers/gpu/drm/exynos/exynos_hdmi.c | 407 +--- drivers/gpu/drm/exynos/exynos_hdmiphy.c| 65 --- drivers/gpu/drm/exynos/exynos_hdmiphy.h| 46 ++ drivers/gpu/drm/exynos/exynos_hdmiphy_i2c.c| 484 drivers/gpu/drm/exynos/exynos_hdmiphy_platform.c | 418 + drivers/gpu/drm/exynos/exynos_hdmiphy_priv.h | 36 ++ drivers/gpu/drm/exynos/regs-hdmiphy.h | 37 ++ 13 files changed, 1174 insertions(+), 360 deletions(-) delete mode 100644 drivers/gpu/drm/exynos/exynos_hdmiphy.c create mode 100644 drivers/gpu/drm/exynos/exynos_hdmiphy.h create mode 100644 drivers/gpu/drm/exynos/exynos_hdmiphy_i2c.c create mode 100644 drivers/gpu/drm/exynos/exynos_hdmiphy_platform.c create mode 100644 drivers/gpu/drm/exynos/exynos_hdmiphy_priv.h create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h -- 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 -- 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 00/12] Add DRM Exynos HDMI on SoCs from Exynos4 family
Hi Tomasz, I have merged the re-factoring patch set from Sean Paul. Can you re-base your patch set at top of exynos-drm-next? Thanks, Inki Dae 2013/10/21 Tomasz Stanislawski t.stanisl...@samsung.com: This patchset adds support for HDMI at SoCs from Exynos4 family. The patches are rebased on kishon/next. Additionally, The patchset contains small fixes to PHY and CLK frameworks. I preferred to keep all the patches together for the first version of the RFC. The interesting part might be 'propagation of clk_set_parent()'. This feature allows to remove the usage of artificial clocks in drivers. Such a situation happens for Exynos HDMI and 'mout_hdmi' where the clock is not even mentioned in some versions of SoC's documentation. Since enabling and setting rate can be propagated I think that clk_set_parent() should also be propagated. This would simplify driver's code and make it less dependant on SoC's version. Another interesting feature refers to simple PHY driver. This driver register a PHY interface that operates by setting a special bit in platform register. This situation is very common in Exynos SoCs. The current version supports only one phy per node. The code might be modified to support multiple phys from single simple-phy provider to avoid creation of multiple nodes in DT. All comments are welcome. Regards, Tomasz Stanislawski Tomasz Stanislawski (12): clk: propagate parent change up one level clk: exynos4: export sclk_hdmiphy clock clk: exynos4: enable clk_set_parent() propagation for sclk_hdmi and sclk_mixer clocks phy: Add simple-phy driver phy: use of_phy_simple_xlate for NULL xlate function Revert drm/exynos: add mout_hdmi clock in hdmi driver to change parent drm: exynos: hdmi: use hdmiphy as PHY drm: exynos: hdmi: simplify extracting hpd-gpio from DT drm: exynos: add compatibles for HDMI and Mixer chips and exynos4210 SoC arm: dts: exynos4: add i2c controller for HDMIPHY arm: dts: exynos4: add HDMI devices arm: dts: universal_c210: add HDMI devices .../devicetree/bindings/clock/exynos4-clock.txt|1 + arch/arm/boot/dts/exynos4.dtsi | 43 +++ arch/arm/boot/dts/exynos4210-universal_c210.dts| 53 arch/arm/boot/dts/exynos4210.dtsi |4 + drivers/clk/clk.c |6 + drivers/clk/samsung/clk-exynos4.c | 10 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 41 +++ drivers/gpu/drm/exynos/exynos_mixer.c |3 + drivers/phy/Kconfig|5 + drivers/phy/Makefile |1 + drivers/phy/phy-core.c |2 +- drivers/phy/phy-simple.c | 128 include/linux/clk-provider.h |1 + 13 files changed, 269 insertions(+), 29 deletions(-) create mode 100644 drivers/phy/phy-simple.c -- 1.7.9.5 ___ 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 1/5] phy: Add new Exynos USB PHY driver
Hi Kumar Gala,
From: Kumar Gala [mailto:ga...@codeaurora.org]
Sent: Friday, October 25, 2013 11:36 PM
On Oct 25, 2013, at 9:15 AM, Kamil Debski wrote:
Add a new driver for the Exynos USB PHY. The new driver uses the
generic PHY framework. The driver includes support for the Exynos
4x10
and 4x12 SoC families.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/phy/samsung-usbphy.txt | 51 +++
drivers/phy/Kconfig| 21 ++
drivers/phy/Makefile |3 +
drivers/phy/phy-exynos-usb.c | 245
++
drivers/phy/phy-exynos-usb.h | 94 ++
drivers/phy/phy-exynos4210-usb.c | 295
+
drivers/phy/phy-exynos4212-usb.c | 343
7 files changed, 1052 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/samsung-usbphy.txt
create mode 100644 drivers/phy/phy-exynos-usb.c create mode 100644
drivers/phy/phy-exynos-usb.h create mode 100644
drivers/phy/phy-exynos4210-usb.c create mode 100644
drivers/phy/phy-exynos4212-usb.c
diff --git a/Documentation/devicetree/bindings/phy/samsung-usbphy.txt
b/Documentation/devicetree/bindings/phy/samsung-usbphy.txt
new file mode 100644
index 000..f112b37
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/samsung-usbphy.txt
@@ -0,0 +1,51 @@
+Samsung S5P/EXYNOS SoC series USB PHY
+-
+
+Required properties:
+- compatible : should be one of the listed compatibles:
+ - samsung,exynos4210-usbphy
+ - samsung,exynos4212-usbphy
+- reg : a list of registers used by phy driver
+ - first and obligatory is the location of phy modules registers
+ - second and also required is the location of isolation registers
+ (isolation registers control the physical connection between
the in
+ SoC modules and outside of the SoC, this also can be called
enable
+ control in the documentation of the SoC)
+ - third is the location of the mode switch register, this only
applies
+ to SoCs that have such a feature; mode switching enables to
have
+ both host and device used the same SoC pins and is commonly
used
+ when OTG is supported
+- #phy-cells : from the generic phy bindings, must be 1;
Please add if clock clock-names are required properties.
Ok, thanks for pointing this out.
+
+The second cell in the PHY specifier identifies the PHY its meaning
+is SoC dependent. For the currently supported SoCs (Exynos 4210 and
+Exynos 4212) it is as follows:
Can we say instead of 'its meaning is SoC dependent...' something like
'its meaning is compatible dependent?
Ok, this sounds better in deed.
+ 0 - USB device,
+ 1 - USB host,
+ 2 - HSIC0,
+ 3 - HSIC1,
+
+Example:
+
+For Exynos 4412 (compatible with Exynos 4212):
+
+exynos_usbphy: exynos-usbphy@125B {
+ compatible = samsung,exynos4212-usbphy;
+ reg = 0x125B 0x100 0x10020704 0x0c 0x1001021c 0x4;
+ ranges;
+ #address-cells = 1;
+ #size-cells = 1;
Why do you have ranges, and #address-cells #size-cells here?
As, I mentioned in my reply to Kishon. I worked on two branches
and I forgot to remove this in the one used to generate patches.
+ clocks = clock 305, clock 2, clock 2, clock 2,
+ clock 2;
+ clock-names = phy, device, host, hsic0, hsic1;
+ status = okay;
+ #phy-cells = 1;
+};
+
+Then the PHY can be used in other nodes such as:
+
+ehci@1258 {
+ status = okay;
+ phys = exynos_usbphy 2;
+ phy-names = hsic0;
+};
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 4/5] usb: ehci-s5p: Change to use phy provided by the generic phy framework
Hi Vivek,
From: Vivek Gautam [mailto:gautamvivek1...@gmail.com]
Sent: Saturday, October 26, 2013 11:41 AM
Hi Kamil,
On Fri, Oct 25, 2013 at 7:45 PM, Kamil Debski k.deb...@samsung.com
wrote:
Change the phy provider used from the old usb phy specific to a new
one using the generic phy framework.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/host/ehci-s5p.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-
s5p.c
index 7cc26e6..76606ff 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -19,6 +19,7 @@
#include linux/module.h
#include linux/of.h
#include linux/of_gpio.h
+#include linux/phy/phy.h
#include linux/platform_device.h
#include linux/platform_data/usb-ehci-s5p.h
#include linux/usb/phy.h
@@ -45,7 +46,7 @@ static struct hc_driver __read_mostly
s5p_ehci_hc_driver;
struct s5p_ehci_hcd {
struct clk *clk;
- struct usb_phy *phy;
+ struct phy *phy;
struct usb_otg *otg;
struct s5p_ehci_platdata *pdata; }; @@ -77,10 +78,11 @@
static int s5p_ehci_probe(struct platform_device *pdev) {
struct s5p_ehci_platdata *pdata = pdev-dev.platform_data;
struct s5p_ehci_hcd *s5p_ehci;
+ struct phy *phy;
just a nit here:
Lets keep the pointer to 'phy' and 'phy_name' together ?
and move this above phy_name ?
Thanks for pointing this out.
struct usb_hcd *hcd;
struct ehci_hcd *ehci;
struct resource *res;
- struct usb_phy *phy;
+ const char *phy_name;
int irq;
int err;
@@ -103,14 +105,14 @@ static int s5p_ehci_probe(struct
platform_device *pdev)
return -ENOMEM;
}
s5p_ehci = to_s5p_ehci(hcd);
-
+ phy_name = of_get_property(pdev-dev.of_node, phy-names,
NULL);
+ phy = devm_phy_get(pdev-dev, phy_name);
Below check for exynos5440 was supposed to skip any request phy.
So shouldn't we place above two assignments to the original place where
devm_usb_get_phy() was called ?
May be i am not getting you intention of changing the place.
Hm... You are right - if we want to leave this check and skip phy request
for
5450 then I should leave the order as it was. And if we want to use the new
phy driver for 5450 then the check to skip phy requesting should be simply
removed.
if (of_device_is_compatible(pdev-dev.of_node,
samsung,exynos5440-ehci)) {
s5p_ehci-pdata = empty_platdata;
goto skip_phy;
}
- phy = devm_usb_get_phy(pdev-dev, USB_PHY_TYPE_USB2);
if (IS_ERR(phy)) {
/* Fallback to pdata */
if (!pdata) {
@@ -122,7 +124,6 @@ static int s5p_ehci_probe(struct platform_device
*pdev)
}
} else {
s5p_ehci-phy = phy;
- s5p_ehci-otg = phy-otg;
}
skip_phy:
@@ -166,7 +167,7 @@ skip_phy:
s5p_ehci-otg-set_host(s5p_ehci-otg, hcd-self);
Lets remove this line and similar calls to 'set_host()' in the driver,
since we don't have s5p_ehci-otg anymore after the same is removed
above.
Anyways this was helping the old phy-samsung-usb2 driver, and not
needed now.
Ok, I will.
if (s5p_ehci-phy)
- usb_phy_init(s5p_ehci-phy);
+ phy_power_on(s5p_ehci-phy);
else if (s5p_ehci-pdata-phy_init)
s5p_ehci-pdata-phy_init(pdev, USB_PHY_TYPE_HOST);
@@ -188,7 +189,7 @@ skip_phy:
fail_add_hcd:
if (s5p_ehci-phy)
- usb_phy_shutdown(s5p_ehci-phy);
+ phy_power_off(s5p_ehci-phy);
else if (s5p_ehci-pdata-phy_exit)
s5p_ehci-pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
fail_io:
@@ -209,7 +210,7 @@ static int s5p_ehci_remove(struct platform_device
*pdev)
s5p_ehci-otg-set_host(s5p_ehci-otg, hcd-self);
ditto
if (s5p_ehci-phy)
- usb_phy_shutdown(s5p_ehci-phy);
+ phy_power_off(s5p_ehci-phy);
else if (s5p_ehci-pdata-phy_exit)
s5p_ehci-pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
@@ -244,7 +245,7 @@ static int s5p_ehci_suspend(struct device *dev)
s5p_ehci-otg-set_host(s5p_ehci-otg, hcd-self);
ditto
if (s5p_ehci-phy)
- usb_phy_shutdown(s5p_ehci-phy);
+ phy_power_off(s5p_ehci-phy);
else if (s5p_ehci-pdata-phy_exit)
s5p_ehci-pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
@@ -265,7 +266,7 @@ static int s5p_ehci_resume(struct device *dev)
s5p_ehci-otg-set_host(s5p_ehci-otg, hcd-self);
ditto
if
RE: [PATCH 4/5] usb: ehci-s5p: Change to use phy provided by the generic phy framework
Hi Jingoo, From: Jingoo Han [mailto:jg1@samsung.com] Sent: Saturday, October 26, 2013 3:27 AM On Friday, October 25, 2013 11:15 PM, Kamil Debski wrote: Change the phy provider used from the old usb phy specific to a new one using the generic phy framework. Signed-off-by: Kamil Debski k.deb...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/usb/host/ehci-s5p.c | 21 +++-- 1 file changed, 11 insertions(+), 10 deletions(-) Hi Kamil Debski, It looks good. :-) Thank you. However, could you re-basing against Greg's 'usb-next' branch? Now, the file name of 'ehci-s5p.c' is renamed to 'ehci-exynos.c'. Also, 'Generic PHY Framework' was already merged to Greg's 'usb-next' branch. Thanks for pointing out this. Thank you. Best regards, Jingoo Han 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 1/5] phy: Add new Exynos USB PHY driver
Hi Kishon,
Thank you for your review! I will answer your comments below.
From: Kishon Vijay Abraham I [mailto:kis...@ti.com]
Sent: Friday, October 25, 2013 5:40 PM
Hi,
On Friday 25 October 2013 07:45 PM, Kamil Debski wrote:
Add a new driver for the Exynos USB PHY. The new driver uses the
generic PHY framework. The driver includes support for the Exynos
4x10
and 4x12 SoC families.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/phy/samsung-usbphy.txt | 51 +++
drivers/phy/Kconfig| 21 ++
drivers/phy/Makefile |3 +
drivers/phy/phy-exynos-usb.c | 245
++
drivers/phy/phy-exynos-usb.h | 94 ++
drivers/phy/phy-exynos4210-usb.c | 295
+
drivers/phy/phy-exynos4212-usb.c | 343
7 files changed, 1052 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/samsung-usbphy.txt
create mode 100644 drivers/phy/phy-exynos-usb.c create mode 100644
drivers/phy/phy-exynos-usb.h create mode 100644
drivers/phy/phy-exynos4210-usb.c create mode 100644
drivers/phy/phy-exynos4212-usb.c
diff --git a/Documentation/devicetree/bindings/phy/samsung-usbphy.txt
b/Documentation/devicetree/bindings/phy/samsung-usbphy.txt
new file mode 100644
index 000..f112b37
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/samsung-usbphy.txt
@@ -0,0 +1,51 @@
+Samsung S5P/EXYNOS SoC series USB PHY
+-
+
+Required properties:
+- compatible : should be one of the listed compatibles:
+ - samsung,exynos4210-usbphy
+ - samsung,exynos4212-usbphy
+- reg : a list of registers used by phy driver
+ - first and obligatory is the location of phy modules registers
+ - second and also required is the location of isolation registers
+ (isolation registers control the physical connection between
the in
+ SoC modules and outside of the SoC, this also can be called
enable
+ control in the documentation of the SoC)
+ - third is the location of the mode switch register, this only
applies
+ to SoCs that have such a feature; mode switching enables to
have
+ both host and device used the same SoC pins and is commonly
used
+ when OTG is supported
+- #phy-cells : from the generic phy bindings, must be 1;
+
+The second cell in the PHY specifier identifies the PHY its meaning
+is SoC dependent. For the currently supported SoCs (Exynos 4210 and
+Exynos 4212) it is as follows:
+ 0 - USB device,
+ 1 - USB host,
+ 2 - HSIC0,
+ 3 - HSIC1,
HSIC is supposedly to be transceiver less no? You have to program
something in the digital side?
You have a single IP that have all these functionalities?
There is a single USB PHY controller for all the above functionalities
(i.e. host, device, hsic 0 and 1).
+
+Example:
+
+For Exynos 4412 (compatible with Exynos 4212):
+
+exynos_usbphy: exynos-usbphy@125B {
+ compatible = samsung,exynos4212-usbphy;
+ reg = 0x125B 0x100 0x10020704 0x0c 0x1001021c 0x4;
+ ranges;
+ #address-cells = 1;
+ #size-cells = 1;
The above 3 properties aren't documented? Are they needed here?
My bad. I was working on two branches and corrected it in only one
of them.
+ clocks = clock 305, clock 2, clock 2, clock 2,
+ clock 2;
+ clock-names = phy, device, host, hsic0, hsic1;
+ status = okay;
+ #phy-cells = 1;
+};
+
+Then the PHY can be used in other nodes such as:
+
+ehci@1258 {
+ status = okay;
+ phys = exynos_usbphy 2;
+ phy-names = hsic0;
+};
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index
349bef2..2f7ac0a 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -15,4 +15,25 @@ config GENERIC_PHY
phy users can obtain reference to the PHY. All the users of
this
framework should select this config.
+config PHY_EXYNOS_USB
+ tristate Samsung USB PHY driver (using the Generic PHY
Framework)
Mentioning *Generic PHY Framework* is not necessary.
*select GENERIC_PHY* here
This was added to distinguish this driver from the ols USB PHY driver.
I agree that in the final version it should be removed. I understand that
the correct way to do this is by removing the old driver when the new gets
merged. Yes?
+ help
+ Enable this to support Samsung USB phy helper driver for
Samsung SoCs.
+ This driver provides common interface to interact, for Samsung
+ USB 2.0 PHY driver.
If it's going to be used only for usb2, name it PHY_EXYNOS_USB2.
I agree.
+
+config PHY_EXYNOS4210_USB
+ bool Support for Exynos 4210
+ depends on
RE: [RFC PATCH 2/5] phy: Add WIP Exynos 5250 support to the Exynos USB PHY driver
Hi Kishon,
From: Kishon Vijay Abraham I [mailto:kis...@ti.com]
Sent: Friday, October 25, 2013 5:44 PM
Hi,
On Friday 25 October 2013 07:45 PM, Kamil Debski wrote:
Add support for Exynos 5250. This is work-in-progress commit. Not for
merging.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/phy/Kconfig |7 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos-usb.c | 10 +
drivers/phy/phy-exynos-usb.h |1 +
drivers/phy/phy-exynos5250-usb.c | 411
++
5 files changed, 430 insertions(+)
create mode 100644 drivers/phy/phy-exynos5250-usb.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index
2f7ac0a..0f598d0 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -36,4 +36,11 @@ config PHY_EXYNOS4212_USB
help
Enable USB PHY support for Exynos 4212
+config PHY_EXYNOS5250_USB
+ bool Support for Exynos 5250
+ depends on PHY_EXYNOS_USB
This should be a separate driver. Not necessary to use PHY_EXYNOS_USB.
+ depends on SOC_EXYNOS5250
+ help
+ Enable USB PHY support for Exynos 5250
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index
ca3dc82..0dff0dd 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_GENERIC_PHY) += phy-core.o
obj-$(CONFIG_PHY_EXYNOS_USB) += phy-exynos-usb.o
obj-$(CONFIG_PHY_EXYNOS4210_USB) += phy-exynos4210-usb.o
obj-$(CONFIG_PHY_EXYNOS4212_USB) += phy-exynos4212-usb.o
+obj-$(CONFIG_PHY_EXYNOS5250_USB) += phy-exynos5250-usb.o
diff --git a/drivers/phy/phy-exynos-usb.c
b/drivers/phy/phy-exynos-usb.c index d4a26df..172b774 100644
--- a/drivers/phy/phy-exynos-usb.c
+++ b/drivers/phy/phy-exynos-usb.c
@@ -212,6 +212,10 @@ extern const struct uphy_config
exynos4210_uphy_config; extern const struct uphy_config
exynos4212_uphy_config; #endif
+#ifdef CONFIG_PHY_EXYNOS5250_USB
+extern const struct uphy_config exynos5250_uphy_config; #endif
+
static const struct of_device_id exynos_uphy_of_match[] = { #ifdef
CONFIG_PHY_EXYNOS4210_USB
{
@@ -225,6 +229,12 @@ static const struct of_device_id
exynos_uphy_of_match[] = {
.data = exynos4212_uphy_config,
},
#endif
+#ifdef CONFIG_PHY_EXYNOS5250_USB
+ {
+ .compatible = samsung,exynos5250-usbphy,
+ .data = exynos5250_uphy_config,
+ },
+#endif
{ },
};
diff --git a/drivers/phy/phy-exynos-usb.h
b/drivers/phy/phy-exynos-usb.h index f45cb3c..a9febfa 100644
--- a/drivers/phy/phy-exynos-usb.h
+++ b/drivers/phy/phy-exynos-usb.h
@@ -42,6 +42,7 @@ enum samsung_cpu_type {
TYPE_S3C64XX,
TYPE_EXYNOS4210,
TYPE_EXYNOS4212,
+ TYPE_EXYNOS5250,
No cpu types here.
};
enum uphy_state {
diff --git a/drivers/phy/phy-exynos5250-usb.c
b/drivers/phy/phy-exynos5250-usb.c
new file mode 100644
index 000..156093b
--- /dev/null
+++ b/drivers/phy/phy-exynos5250-usb.c
@@ -0,0 +1,411 @@
+/*
+ * Samsung S5P/EXYNOS SoC series USB PHY driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Kamil Debski k.deb...@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 linux/spinlock.h
+#include phy-exynos-usb.h
+
+/* Exynos USB PHY registers */
+#define EXYNOS_5250_REFCLKSEL_CRYSTAL 0x0
+#define EXYNOS_5250_REFCLKSEL_XO 0x1
+#define EXYNOS_5250_REFCLKSEL_CLKCORE 0x2
+
+#define EXYNOS_5250_FSEL_9MHZ6 0x0
+#define EXYNOS_5250_FSEL_10MHZ 0x1
+#define EXYNOS_5250_FSEL_12MHZ 0x2
+#define EXYNOS_5250_FSEL_19MHZ20x3
+#define EXYNOS_5250_FSEL_20MHZ 0x4
+#define EXYNOS_5250_FSEL_24MHZ 0x5
+#define EXYNOS_5250_FSEL_50MHZ 0x7
+
+/* Normal host */
+#define EXYNOS_5250_HOSTPHYCTRL0 0x0
+
+#define EXYNOS_5250_HOSTPHYCTRL0_PHYSWRSTALL (0x1 31)
+#define EXYNOS_5250_HOSTPHYCTRL0_REFCLKSEL_SHIFT 19
+#define EXYNOS_5250_HOSTPHYCTRL0_REFCLKSEL_MASK\
+ (0x3 EXYNOS_5250_HOSTPHYCTRL0_REFCLKSEL_SHIFT)
+#define EXYNOS_5250_HOSTPHYCTRL0_FSEL_SHIFT16
+#define EXYNOS_5250_HOSTPHYCTRL0_FSEL_MASK \
+ (0x7 EXYNOS_5250_HOSTPHYCTRL0_FSEL_SHIFT)
+#define EXYNOS_5250_HOSTPHYCTRL0_TESTBURNIN(0x1 11)
+#define
Re: [PATCH v2 00/12] clk/exynos convert clock IDs to macros
Ping Regards Andrzej On 10/07/2013 10:46 AM, Andrzej Hajda wrote: On 10/06/2013 10:27 PM, Mike Turquette wrote: Quoting Kukjin Kim (2013-10-04 19:16:56) Mike Turquette wrote: Quoting Kukjin Kim (2013-09-30 03:11:41) Mike Turquette wrote: Quoting Sylwester Nawrocki (2013-09-16 07:33:45) On 09/12/2013 12:50 PM, Kukjin Kim wrote: Well...I'm not sure changing to use macro is better or not at this moment... I think it is. ;) It's really less error prone to have symbolic names instead of the plain numbers. The clock ids are defined in one place and it is more clear what a clock is by looking at symbolic name. It's especially annoying to use plain numbers where are are many clock in a single node, like 10 or more. What are you main concerns with this ? I think having the symbolic names is a win for readability. Hmm...since Mike who is a maintainer for ccf agrees with Sylwester's opinion, so I agree. Actually, I had no strong objection on this but still I'm not sure using macro is really better because sometimes the name doesn't give readability really I think though. Mike, can you give me your ack on clk stuff? Yes, but I was thinking to take this change through the clk tree. The new branch based on -rc3 will be published tonight. Let me know if it causes problems for you for me to take it. Uhm, I think dt changes can make ugly conflicts because of spread dt changing? Sure, go ahead and take the patches then. Acked-by: Mike Turquette mturque...@linaro.org Regards, Mike I can create patchset based on different git branch if neccessary. Regards Andrzej - 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 4/5] usb: ehci-s5p: Change to use phy provided by the generic phy framework
Hi Kamil,
On Mon, Oct 28, 2013 at 7:23 PM, Kamil Debski k.deb...@samsung.com wrote:
Hi Vivek,
From: Vivek Gautam [mailto:gautamvivek1...@gmail.com]
Sent: Saturday, October 26, 2013 11:41 AM
Hi Kamil,
On Fri, Oct 25, 2013 at 7:45 PM, Kamil Debski k.deb...@samsung.com
wrote:
Change the phy provider used from the old usb phy specific to a new
one using the generic phy framework.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Similar change for ohci-exynos too ?
drivers/usb/host/ehci-s5p.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-
s5p.c
index 7cc26e6..76606ff 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -19,6 +19,7 @@
#include linux/module.h
#include linux/of.h
#include linux/of_gpio.h
+#include linux/phy/phy.h
#include linux/platform_device.h
#include linux/platform_data/usb-ehci-s5p.h
#include linux/usb/phy.h
@@ -45,7 +46,7 @@ static struct hc_driver __read_mostly
s5p_ehci_hc_driver;
struct s5p_ehci_hcd {
struct clk *clk;
- struct usb_phy *phy;
+ struct phy *phy;
struct usb_otg *otg;
This can also be removed.
struct s5p_ehci_platdata *pdata; }; @@ -77,10 +78,11 @@
static int s5p_ehci_probe(struct platform_device *pdev) {
struct s5p_ehci_platdata *pdata = pdev-dev.platform_data;
struct s5p_ehci_hcd *s5p_ehci;
+ struct phy *phy;
just a nit here:
Lets keep the pointer to 'phy' and 'phy_name' together ?
and move this above phy_name ?
Thanks for pointing this out.
struct usb_hcd *hcd;
struct ehci_hcd *ehci;
struct resource *res;
- struct usb_phy *phy;
+ const char *phy_name;
int irq;
int err;
@@ -103,14 +105,14 @@ static int s5p_ehci_probe(struct
platform_device *pdev)
return -ENOMEM;
}
s5p_ehci = to_s5p_ehci(hcd);
-
+ phy_name = of_get_property(pdev-dev.of_node, phy-names,
NULL);
Sorry one more doubt here :-)
Now that we have HOST, DEVICE, HSIC0, HSIC1 as different PHYs,
and i think EHCI will be the candidate to request HSIC phy too (once
we have HSIC phy
initialization code available for each SoC);
shouldn't we be using of_count_phandle_with_args() to get HOST, and HSIC phys
and then request multiple phys here ?
+ phy = devm_phy_get(pdev-dev, phy_name);
Below check for exynos5440 was supposed to skip any request phy.
So shouldn't we place above two assignments to the original place where
devm_usb_get_phy() was called ?
May be i am not getting you intention of changing the place.
Hm... You are right - if we want to leave this check and skip phy request
for
5450 then I should leave the order as it was. And if we want to use the new
phy driver for 5450 then the check to skip phy requesting should be simply
removed.
if (of_device_is_compatible(pdev-dev.of_node,
samsung,exynos5440-ehci)) {
s5p_ehci-pdata = empty_platdata;
goto skip_phy;
}
- phy = devm_usb_get_phy(pdev-dev, USB_PHY_TYPE_USB2);
if (IS_ERR(phy)) {
/* Fallback to pdata */
if (!pdata) {
@@ -122,7 +124,6 @@ static int s5p_ehci_probe(struct platform_device
*pdev)
}
} else {
s5p_ehci-phy = phy;
- s5p_ehci-otg = phy-otg;
}
skip_phy:
@@ -166,7 +167,7 @@ skip_phy:
s5p_ehci-otg-set_host(s5p_ehci-otg, hcd-self);
Lets remove this line and similar calls to 'set_host()' in the driver,
since we don't have s5p_ehci-otg anymore after the same is removed
above.
Anyways this was helping the old phy-samsung-usb2 driver, and not
needed now.
Ok, I will.
if (s5p_ehci-phy)
- usb_phy_init(s5p_ehci-phy);
+ phy_power_on(s5p_ehci-phy);
else if (s5p_ehci-pdata-phy_init)
s5p_ehci-pdata-phy_init(pdev, USB_PHY_TYPE_HOST);
@@ -188,7 +189,7 @@ skip_phy:
fail_add_hcd:
if (s5p_ehci-phy)
- usb_phy_shutdown(s5p_ehci-phy);
+ phy_power_off(s5p_ehci-phy);
else if (s5p_ehci-pdata-phy_exit)
s5p_ehci-pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
fail_io:
@@ -209,7 +210,7 @@ static int s5p_ehci_remove(struct platform_device
*pdev)
s5p_ehci-otg-set_host(s5p_ehci-otg, hcd-self);
ditto
if (s5p_ehci-phy)
- usb_phy_shutdown(s5p_ehci-phy);
+ phy_power_off(s5p_ehci-phy);
else if (s5p_ehci-pdata-phy_exit)
s5p_ehci-pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
@@ -244,7 +245,7 @@ static int
Re: [RFC PATCH 2/5] phy: Add WIP Exynos 5250 support to the Exynos USB PHY driver
Hi Kishon,
On Fri, Oct 25, 2013 at 9:13 PM, Kishon Vijay Abraham I kis...@ti.com wrote:
Hi,
On Friday 25 October 2013 07:45 PM, Kamil Debski wrote:
Add support for Exynos 5250. This is work-in-progress commit. Not
for merging.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/phy/Kconfig |7 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos-usb.c | 10 +
drivers/phy/phy-exynos-usb.h |1 +
drivers/phy/phy-exynos5250-usb.c | 411
++
5 files changed, 430 insertions(+)
create mode 100644 drivers/phy/phy-exynos5250-usb.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 2f7ac0a..0f598d0 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -36,4 +36,11 @@ config PHY_EXYNOS4212_USB
help
Enable USB PHY support for Exynos 4212
+config PHY_EXYNOS5250_USB
+ bool Support for Exynos 5250
+ depends on PHY_EXYNOS_USB
This should be a separate driver. Not necessary to use PHY_EXYNOS_USB.
+ depends on SOC_EXYNOS5250
+ help
+ Enable USB PHY support for Exynos 5250
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index ca3dc82..0dff0dd 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_GENERIC_PHY) += phy-core.o
obj-$(CONFIG_PHY_EXYNOS_USB) += phy-exynos-usb.o
obj-$(CONFIG_PHY_EXYNOS4210_USB) += phy-exynos4210-usb.o
obj-$(CONFIG_PHY_EXYNOS4212_USB) += phy-exynos4212-usb.o
+obj-$(CONFIG_PHY_EXYNOS5250_USB) += phy-exynos5250-usb.o
diff --git a/drivers/phy/phy-exynos-usb.c b/drivers/phy/phy-exynos-usb.c
index d4a26df..172b774 100644
--- a/drivers/phy/phy-exynos-usb.c
+++ b/drivers/phy/phy-exynos-usb.c
@@ -212,6 +212,10 @@ extern const struct uphy_config exynos4210_uphy_config;
extern const struct uphy_config exynos4212_uphy_config;
#endif
+#ifdef CONFIG_PHY_EXYNOS5250_USB
+extern const struct uphy_config exynos5250_uphy_config;
+#endif
+
static const struct of_device_id exynos_uphy_of_match[] = {
#ifdef CONFIG_PHY_EXYNOS4210_USB
{
@@ -225,6 +229,12 @@ static const struct of_device_id exynos_uphy_of_match[]
= {
.data = exynos4212_uphy_config,
},
#endif
+#ifdef CONFIG_PHY_EXYNOS5250_USB
+ {
+ .compatible = samsung,exynos5250-usbphy,
+ .data = exynos5250_uphy_config,
+ },
+#endif
{ },
};
diff --git a/drivers/phy/phy-exynos-usb.h b/drivers/phy/phy-exynos-usb.h
index f45cb3c..a9febfa 100644
--- a/drivers/phy/phy-exynos-usb.h
+++ b/drivers/phy/phy-exynos-usb.h
@@ -42,6 +42,7 @@ enum samsung_cpu_type {
TYPE_S3C64XX,
TYPE_EXYNOS4210,
TYPE_EXYNOS4212,
+ TYPE_EXYNOS5250,
No cpu types here.
One question here.
In case we move to single driver for Exynos4 SoCs (4210, 4212 and 4412
later) as well as S5PV210,
there will be certain things changing from one SoC to another, how
should we target that in case we
don't have CPU types ?
May be i am misinterpreting your suggestion ?
};
enum uphy_state {
diff --git a/drivers/phy/phy-exynos5250-usb.c
b/drivers/phy/phy-exynos5250-usb.c
new file mode 100644
index 000..156093b
--- /dev/null
+++ b/drivers/phy/phy-exynos5250-usb.c
@@ -0,0 +1,411 @@
+/*
+ * Samsung S5P/EXYNOS SoC series USB PHY driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Kamil Debski k.deb...@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 linux/spinlock.h
+#include phy-exynos-usb.h
+
+/* Exynos USB PHY registers */
+#define EXYNOS_5250_REFCLKSEL_CRYSTAL0x0
+#define EXYNOS_5250_REFCLKSEL_XO 0x1
+#define EXYNOS_5250_REFCLKSEL_CLKCORE0x2
+
+#define EXYNOS_5250_FSEL_9MHZ6 0x0
+#define EXYNOS_5250_FSEL_10MHZ 0x1
+#define EXYNOS_5250_FSEL_12MHZ 0x2
+#define EXYNOS_5250_FSEL_19MHZ2 0x3
+#define EXYNOS_5250_FSEL_20MHZ 0x4
+#define EXYNOS_5250_FSEL_24MHZ 0x5
+#define EXYNOS_5250_FSEL_50MHZ 0x7
+
+/* Normal host */
+#define EXYNOS_5250_HOSTPHYCTRL0 0x0
+
+#define EXYNOS_5250_HOSTPHYCTRL0_PHYSWRSTALL (0x1 31)
+#define EXYNOS_5250_HOSTPHYCTRL0_REFCLKSEL_SHIFT 19
+#define EXYNOS_5250_HOSTPHYCTRL0_REFCLKSEL_MASK \
+ (0x3 EXYNOS_5250_HOSTPHYCTRL0_REFCLKSEL_SHIFT)
+#define EXYNOS_5250_HOSTPHYCTRL0_FSEL_SHIFT 16
+#define
Re: [PATCH] ARM: dts: disable PCIe for SD5v1 board
On Sun, Oct 27, 2013 at 10:36 PM, Jingoo Han jg1@samsung.com wrote:
On Monday, October 28, 2013 1:52 PM, Olof Johansson wrote:
On Wed, Sep 4, 2013 at 11:08 PM, Jingoo Han jg1@samsung.com wrote:
Disable PCIe for SD5v1 board, because there is no PCIe slot
on SD5v1 board.
Signed-off-by: Jingoo Han jg1@samsung.com
---
Tested on SD5v1 board.
arch/arm/boot/dts/exynos5440-sd5v1.dts |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5440-sd5v1.dts
b/arch/arm/boot/dts/exynos5440-sd5v1.dts
index 5b22508..78a239d 100644
--- a/arch/arm/boot/dts/exynos5440-sd5v1.dts
+++ b/arch/arm/boot/dts/exynos5440-sd5v1.dts
@@ -36,4 +36,11 @@
status = disabled;
};
+ pcie@29 {
+ status = disabled;
+ };
+
+ pcie@2a {
+ status = disabled;
+ };
};
Usually IP blocks like these are always left disabled in the dtsi, and
explicitly _enabled_ in the DTS on boards that make use of that part
of the chip.
So the real solution here should be to move the disabling to the 5440
.dtsi instead.
OK, right.
Thank you for your guidance.
Then, do you mean the following?
If it is right, I will send the v2 patch.
Yes, exactly!
-Olof
--
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 00/12] clk/exynos convert clock IDs to macros
On 10/28/13 07:31, Andrzej Hajda wrote: Ping Regards Andrzej On 10/07/2013 10:46 AM, Andrzej Hajda wrote: On 10/06/2013 10:27 PM, Mike Turquette wrote: Quoting Kukjin Kim (2013-10-04 19:16:56) Mike Turquette wrote: Quoting Kukjin Kim (2013-09-30 03:11:41) Mike Turquette wrote: Quoting Sylwester Nawrocki (2013-09-16 07:33:45) On 09/12/2013 12:50 PM, Kukjin Kim wrote: Well...I'm not sure changing to use macro is better or not at this moment... I think it is. ;) It's really less error prone to have symbolic names instead of the plain numbers. The clock ids are defined in one place and it is more clear what a clock is by looking at symbolic name. It's especially annoying to use plain numbers where are are many clock in a single node, like 10 or more. What are you main concerns with this ? I think having the symbolic names is a win for readability. Hmm...since Mike who is a maintainer for ccf agrees with Sylwester's opinion, so I agree. Actually, I had no strong objection on this but still I'm not sure using macro is really better because sometimes the name doesn't give readability really I think though. Mike, can you give me your ack on clk stuff? Yes, but I was thinking to take this change through the clk tree. The new branch based on -rc3 will be published tonight. Let me know if it causes problems for you for me to take it. Uhm, I think dt changes can make ugly conflicts because of spread dt changing? Sure, go ahead and take the patches then. Acked-by: Mike Turquettemturque...@linaro.org Regards, Mike I can create patchset based on different git branch if neccessary. Hi Unfortunately, this changes would be merged after release of next rc1 because of too many conflicts with other DT changes in Samsung tree. Thanks, Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: disable PCIe for SD5v1 board
On 10/28/13 08:15, Olof Johansson wrote:
On Sun, Oct 27, 2013 at 10:36 PM, Jingoo Hanjg1@samsung.com wrote:
On Monday, October 28, 2013 1:52 PM, Olof Johansson wrote:
On Wed, Sep 4, 2013 at 11:08 PM, Jingoo Hanjg1@samsung.com wrote:
Disable PCIe for SD5v1 board, because there is no PCIe slot
on SD5v1 board.
Signed-off-by: Jingoo Hanjg1@samsung.com
---
Tested on SD5v1 board.
arch/arm/boot/dts/exynos5440-sd5v1.dts |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5440-sd5v1.dts
b/arch/arm/boot/dts/exynos5440-sd5v1.dts
index 5b22508..78a239d 100644
--- a/arch/arm/boot/dts/exynos5440-sd5v1.dts
+++ b/arch/arm/boot/dts/exynos5440-sd5v1.dts
@@ -36,4 +36,11 @@
status = disabled;
};
+ pcie@29 {
+ status = disabled;
+ };
+
+ pcie@2a {
+ status = disabled;
+ };
};
Usually IP blocks like these are always left disabled in the dtsi, and
explicitly _enabled_ in the DTS on boards that make use of that part
of the chip.
So the real solution here should be to move the disabling to the 5440
.dtsi instead.
OK, right.
Thank you for your guidance.
Then, do you mean the following?
If it is right, I will send the v2 patch.
Yes, exactly!
Hmm...I thought both ways (#1 disabling something in soc dt, enabling in
board dt if required, #2 enabling in soc dt, disabling in board dt if
required) are possible but I have no strong objection with your
suggestion. In addition, just one way is more clear to us :)
OK, I will keep the way for Samsung stuff.
Thanks,
Kukjin
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/12] Add DRM Exynos HDMI on SoCs from Exynos4 family
On 10/28/13 06:42, Inki Dae wrote: Hi Tomasz, I have merged the re-factoring patch set from Sean Paul. Can you re-base your patch set at top of exynos-drm-next? Basically, RFC is not patch for merge. So Tomasz needs to re-submit after addressing comments from RFC. Thanks, Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: disable PCIe for SD5v1 board
On Mon, Oct 28, 2013 at 8:12 AM, Kukjin Kim kgene@samsung.com wrote:
On 10/28/13 08:15, Olof Johansson wrote:
On Sun, Oct 27, 2013 at 10:36 PM, Jingoo Hanjg1@samsung.com wrote:
On Monday, October 28, 2013 1:52 PM, Olof Johansson wrote:
On Wed, Sep 4, 2013 at 11:08 PM, Jingoo Hanjg1@samsung.com wrote:
Disable PCIe for SD5v1 board, because there is no PCIe slot
on SD5v1 board.
Signed-off-by: Jingoo Hanjg1@samsung.com
---
Tested on SD5v1 board.
arch/arm/boot/dts/exynos5440-sd5v1.dts |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5440-sd5v1.dts
b/arch/arm/boot/dts/exynos5440-sd5v1.dts
index 5b22508..78a239d 100644
--- a/arch/arm/boot/dts/exynos5440-sd5v1.dts
+++ b/arch/arm/boot/dts/exynos5440-sd5v1.dts
@@ -36,4 +36,11 @@
status = disabled;
};
+ pcie@29 {
+ status = disabled;
+ };
+
+ pcie@2a {
+ status = disabled;
+ };
};
Usually IP blocks like these are always left disabled in the dtsi, and
explicitly _enabled_ in the DTS on boards that make use of that part
of the chip.
So the real solution here should be to move the disabling to the 5440
.dtsi instead.
OK, right.
Thank you for your guidance.
Then, do you mean the following?
If it is right, I will send the v2 patch.
Yes, exactly!
Hmm...I thought both ways (#1 disabling something in soc dt, enabling in
board dt if required, #2 enabling in soc dt, disabling in board dt if
required) are possible but I have no strong objection with your suggestion.
In addition, just one way is more clear to us :)
OK, I will keep the way for Samsung stuff.
It varies, in some cases it makes sense to make the default enabled
and just disable where needed, for example for entirely on-chip IP
blocks.
For things like PCI-e, where different board manufacturers might
choose to use it or not, it seems that keeping disabled by default is
sensible.
-Olof
--
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 00/12] Add DRM Exynos HDMI on SoCs from Exynos4 family
2013/10/29 Kukjin Kim kgene@samsung.com: On 10/28/13 06:42, Inki Dae wrote: Hi Tomasz, I have merged the re-factoring patch set from Sean Paul. Can you re-base your patch set at top of exynos-drm-next? Basically, RFC is not patch for merge. So Tomasz needs to re-submit after addressing comments from RFC. There must definitely be your misunderstanding. I have never merged this RFC patch set. For review, shouldn't this RFC patch set be rebased at top of latest exynos-drm-next? :) Thanks, Inki Dae 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 -- 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/5] phy: Add new Exynos USB PHY driver
Hi Kamil,
On Monday 28 of October 2013 14:52:19 Kamil Debski wrote:
Hi Kishon,
Thank you for your review! I will answer your comments below.
[snip]
+
+ switch (drv-cfg-cpu) {
+ case TYPE_EXYNOS4210:
+ case TYPE_EXYNOS4212:
Lets not add such cpu checks inside driver.
Some SoC have a special register, which switches the OTG lines between
device and host modes. I understand that it might not be the prettiest
code. I see this as a good compromise between having a single huge
driver for all Exynos SoCs and having a multiple drivers for each SoC
version. PHY IPs in these chips very are similar but have to be handled
differently. Any other ideas to solve this issue?
Maybe adding a flag in drv-cfg called, for example, .has_mode_switch
could solve this problem without having to check the SoC type explicitly?
[snip]
+#ifdef CONFIG_PHY_EXYNOS4210_USB
Do we really need this?
No we don't. The driver can always support all Exynos SoC versions.
These config options were added for flexibility.
+extern const struct uphy_config exynos4210_uphy_config; #endif
+
+#ifdef CONFIG_PHY_EXYNOS4212_USB
Same here.
+extern const struct uphy_config exynos4212_uphy_config; #endif
+
+static const struct of_device_id exynos_uphy_of_match[] = { #ifdef
+CONFIG_PHY_EXYNOS4210_USB
#if not needed here.
If the #ifdef CONFIG_PHY_EXYNOS4210_USB is removed then yes. Otherwise
it is necessary - exynos4210_uphy_config may be undefined.
I believe this and other ifdefs below are needed, otherwise, with support
for one of the SoCs disabled, the driver could still bind to its
compatible value.
Best regards,
Tomasz
--
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 v10 01/12] exynos5-fimc-is: Add Exynos5 FIMC-IS device tree bindings documentation
Hi, Apologies for the late reply. I have a few comments, but nothing major. On Fri, Oct 18, 2013 at 06:37:28AM +0100, Arun Kumar K wrote: The patch adds the DT binding documentation for Samsung Exynos5 SoC series imaging subsystem (FIMC-IS). Signed-off-by: Arun Kumar K arun...@samsung.com Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com --- .../devicetree/bindings/media/exynos5-fimc-is.txt | 84 1 file changed, 84 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/exynos5-fimc-is.txt diff --git a/Documentation/devicetree/bindings/media/exynos5-fimc-is.txt b/Documentation/devicetree/bindings/media/exynos5-fimc-is.txt new file mode 100644 index 000..0525417 --- /dev/null +++ b/Documentation/devicetree/bindings/media/exynos5-fimc-is.txt @@ -0,0 +1,84 @@ +Samsung EXYNOS5 SoC series Imaging Subsystem (FIMC-IS) +-- + +The camera subsystem on Samsung Exynos5 SoC has some changes relative +to previous SoC versions. Exynos5 has almost similar MIPI-CSIS and +FIMC-LITE IPs but has a much improved version of FIMC-IS which can +handle sensor controls and camera post-processing operations. The +Exynos5 FIMC-IS has a dedicated ARM Cortex A5 processor, many +post-processing blocks (ISP, DRC, FD, ODC, DIS, 3DNR) and two +dedicated scalers (SCC and SCP). + +fimc-is node + + +Required properties: + +- compatible: must be samsung,exynos5250-fimc-is s/must be/should contain/ +- reg : physical base address and size of the memory mapped + registers +- interrupt-parent : parent interrupt controller I don't think this is actually required in all cases. It's a standard property that people can add if it happens to be required in a particular instance. +- interrupts: fimc-is interrupt to the parent interrupt controller Is this the only interrupt the device generates? If so: - interrupts: interrupt-specifier for the fimc-is interrupt. +- clocks: list of clock specifiers, corresponding to entries in + clock-names property +- clock-names : must contain isp, mcu_isp, isp_div0, isp_div1, + isp_divmpwm, mcu_isp_div0, mcu_isp_div1 entries, + matching entries in the clocks property +- samsung,pmu : phandle to the Power Management Unit (PMU) node + +i2c-isp (ISP I2C bus controller) nodes +-- +The i2c-isp node is defined as the child node of fimc-is. There are multiple of these, so how about the following instead: The i2c-isp nodes should be children of the fimc-is node. It might be worth pointing out that ranges, #address-cells, and #size-cells should be present as appropriate. + +Required properties: + +- compatible : should be samsung,exynos4212-i2c-isp for Exynos4212, + Exynos4412 and Exynos5250 SoCs Similarly, s/should be/must contain/ +- reg: physical base address and length of the registers set +- clocks : must contain gate clock specifier for this controller +- clock-names: must contain i2c_isp entry I'd prefer clocks to be described as for the simc-is, with clock names being something like: - clock-names: should contain i2c_isp for the gate clock. + +For the i2c-isp node, it is required to specify a pinctrl state named default, +according to the pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt. I'd prefer a mention of pinctrl-0 and pinctrl-names, as that's what most other bindings do. Also, as this is described as required it should be in the example. + +Device tree nodes of the image sensors controlled directly by the FIMC-IS +firmware must be child nodes of their corresponding ISP I2C bus controller node. +The data link of these image sensors must be specified using the common video +interfaces bindings, defined in video-interfaces.txt. These don't seem to be in the example and probably should be. Otherwise, this looks fine. With those points fixed up: Acked-by: Mark Rutland mark.rutl...@arm.com Thanks, Mark. -- 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 v10 11/12] V4L: Add DT binding doc for s5k4e5 image sensor
On Fri, Oct 18, 2013 at 06:37:38AM +0100, Arun Kumar K wrote: S5K4E5 is a Samsung raw image sensor controlled via I2C. This patch adds the DT binding documentation for the same. Signed-off-by: Arun Kumar K arun...@samsung.com Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com --- .../devicetree/bindings/media/samsung-s5k4e5.txt | 45 1 file changed, 45 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/samsung-s5k4e5.txt diff --git a/Documentation/devicetree/bindings/media/samsung-s5k4e5.txt b/Documentation/devicetree/bindings/media/samsung-s5k4e5.txt new file mode 100644 index 000..0fca087 --- /dev/null +++ b/Documentation/devicetree/bindings/media/samsung-s5k4e5.txt @@ -0,0 +1,45 @@ +* Samsung S5K4E5 Raw Image Sensor + +S5K4E5 is a raw image sensor with maximum resolution of 2560x1920 +pixels. Data transfer is carried out via MIPI CSI-2 port and controls +via I2C bus. + +Required Properties: +- compatible : must be samsung,s5k4e5 s/must be/should contain/ +- reg: I2C device address +- reset-gpios: specifier of a GPIO connected to the RESET pin +- clocks : should contain the sensor's EXTCLK clock specifier, from + the common clock bindings I would reword this to reference clock-names so as to make the ordering relationship explicit. With that, as everything else looks sane: Acked-by: Mark Rutland mark.rutl...@arm.com Thanks Mark. -- 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 0/7] drm/exynos: move hdmiphy related code to hdmiphy driver
On 28 October 2013 19:10, Inki Dae inki@samsung.com wrote: Hi Rahul, I have merged the re-factoring patch set from Sean Paul to exynos-drm-next except eDP related patch set that these need more reviews. Can you re-base at top of exynos-drm-next? Ok. I will rebase and post it again. regards, Rahul Sharma. Thanks, Inki Dae 2013/10/22 Rahul Sharma rahul.sha...@samsung.com: Currently, exynos hdmiphy operations and configs are kept inside the hdmi driver. Hdmiphy related code is very tightly coupled with hdmi IP driver. With these patches, hdmiphy related stuff is moved to hdmiphy i2c driver for exynos4 and exynos5250 socs. hdmi driver, being the phy controller, calls exynos hdmiphy interfaces. This series also removes hdmiphy dummy clock for hdmiphy and replace it with Phy PMU Control from the hdmiphy driver. At the end, support for exynos5420 hdmiphy is added to the hdmiphy platform driver. Drm related paches are based on exynos-drm-next branch at git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git Arch related paches are based on for-next branch at http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git Rahul Sharma (7): drm/exynos: move hdmiphy code to hdmiphy i2c driver drm/exynos: remove dummy hdmiphy clock drm/exynos: add hdmiphy platform driver for exynos5420 drm/exynos: add hdmiphy pmu bit control in hdmiphy drivers exynos/drm: fix ddc i2c device probe failure ARM: dts: update hdmiphy dt node for exynos5250 ARM: dts: update hdmiphy dt node for exynos5420 .../devicetree/bindings/video/exynos_hdmi.txt |2 + .../devicetree/bindings/video/exynos_hdmiphy.txt |8 +- arch/arm/boot/dts/exynos5250-smdk5250.dts |9 +- arch/arm/boot/dts/exynos5420.dtsi | 14 +- drivers/gpu/drm/exynos/Makefile|3 +- drivers/gpu/drm/exynos/exynos_ddc.c|5 + drivers/gpu/drm/exynos/exynos_hdmi.c | 407 +--- drivers/gpu/drm/exynos/exynos_hdmiphy.c| 65 --- drivers/gpu/drm/exynos/exynos_hdmiphy.h| 46 ++ drivers/gpu/drm/exynos/exynos_hdmiphy_i2c.c| 484 drivers/gpu/drm/exynos/exynos_hdmiphy_platform.c | 418 + drivers/gpu/drm/exynos/exynos_hdmiphy_priv.h | 36 ++ drivers/gpu/drm/exynos/regs-hdmiphy.h | 37 ++ 13 files changed, 1174 insertions(+), 360 deletions(-) delete mode 100644 drivers/gpu/drm/exynos/exynos_hdmiphy.c create mode 100644 drivers/gpu/drm/exynos/exynos_hdmiphy.h create mode 100644 drivers/gpu/drm/exynos/exynos_hdmiphy_i2c.c create mode 100644 drivers/gpu/drm/exynos/exynos_hdmiphy_platform.c create mode 100644 drivers/gpu/drm/exynos/exynos_hdmiphy_priv.h create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h -- 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 -- 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/1] pwm: samsung: Fix kernel warning while unexporting a channel
On Tuesday, October 29, 2013 1:58 PM, Sachin Kamat wrote:
PWM channel data was set to NULL before freeing it. This caused the
following kernel warning while unexporting the channel. Set the channel
data to NULL after freeing it.
[ 70.495000] WARNING: CPU: 0 PID: 1 at drivers/base/devres.c:805
pwm_put+0x48/0x80()
[ 70.505000] Modules linked in:
[ 70.505000] CPU: 0 PID: 1 Comm: sh Not tainted
3.12.0-rc6-next-20131024-00012-gd4aec04-dirty #58
[ 70.515000] [c0014ddc] (unwind_backtrace+0x0/0xf4) from [c0011784]
(show_stack+0x10/0x14)
[ 70.525000] [c0011784] (show_stack+0x10/0x14) from [c03a3cbc]
(dump_stack+0x7c/0xb0)
[ 70.53] [c03a3cbc] (dump_stack+0x7c/0xb0) from [c001de68]
(warn_slowpath_common+0x6c/0x88)
[ 70.54] [c001de68] (warn_slowpath_common+0x6c/0x88) from [c001df20]
(warn_slowpath_null+0x1c/0x24)
[ 70.55] [c001df20] (warn_slowpath_null+0x1c/0x24) from [c01d1af8]
(pwm_put+0x48/0x80)
[ 70.56] [c01d1af8] (pwm_put+0x48/0x80) from [c01d21c8]
(pwm_unexport_store+0x94/0xac)
[ 70.565000] [c01d21c8] (pwm_unexport_store+0x94/0xac) from [c010991c]
(sysfs_write_file+0x148/0x1d8)
[ 70.575000] [c010991c] (sysfs_write_file+0x148/0x1d8) from [c00b2a80]
(vfs_write+0xb4/0x1a0)
[ 70.585000] [c00b2a80] (vfs_write+0xb4/0x1a0) from [c00b3068]
(SyS_write+0x3c/0x78)
[ 70.595000] [c00b3068] (SyS_write+0x3c/0x78) from [c000e2e0]
(ret_fast_syscall+0x0/0x30)
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Reviewed-by: Jingoo Han jg1@samsung.com
Best regards,
Jingoo Han
---
drivers/pwm/pwm-samsung.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
index b2c54c8..6d23eb3 100644
--- a/drivers/pwm/pwm-samsung.c
+++ b/drivers/pwm/pwm-samsung.c
@@ -226,8 +226,8 @@ static int pwm_samsung_request(struct pwm_chip *chip,
struct pwm_device *pwm)
static void pwm_samsung_free(struct pwm_chip *chip, struct pwm_device *pwm)
{
- pwm_set_chip_data(pwm, NULL);
devm_kfree(chip-dev, pwm_get_chip_data(pwm));
+ pwm_set_chip_data(pwm, NULL);
}
static int pwm_samsung_enable(struct pwm_chip *chip, struct pwm_device *pwm)
--
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 1/7] VFIO_IOMMU_TYPE1 workaround to build for platform devices
On 10/02/2013 08:14 AM, Alexander Graf wrote:
On 01.10.2013, at 21:21, Yoder Stuart-B08248 wrote:
static int __init vfio_iommu_type1_init(void)
{
- if (!iommu_present(pci_bus_type))
+#ifdef CONFIG_PCI
+ if (iommu_present(pci_bus_type)) {
+ iommu_bus_type =pci_bus_type;
+ /* For PCI targets, IOMMU_CAP_INTR_REMAP is required */
+ require_cap_intr_remap = true;
+ }
+#endif
+ if (!iommu_bus_type iommu_present(platform_bus_type))
+ iommu_bus_type =platform_bus_type;
+
+ if(!iommu_bus_type)
return -ENODEV;
return vfio_register_iommu_driver(vfio_iommu_driver_ops_type1);
Is it possible to have a system with both PCI and platform devices? How
would you support that? Thanks,
It most certainly is a requirement to support both. This is how
all of our (FSL) SoCs will expect to work.
I thought the PCI bus emits a cookie that the system wide IOMMU can then use to
differentiate the origin of the transaction? So the same IOMMU can be used for
PCI as well as platform routing.
*can* be the same IOMMU, yes;
have to, no, so there can be multiple IOMMUs of different types.
Alex
___
iommu mailing list
io...@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
--
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
