Re: [PATCH 10/29] drivers: add DRIVER_HAS_OWN_IOMMU_MANAGER flag
On Mon, Sep 01, 2014 at 07:22:32AM +0200, Marek Szyprowski wrote:
Hi Greg,
On 2014-08-05 12:47, Marek Szyprowski wrote:
This patch adds a new flags for device drivers. This flag instructs
kernel that the device driver does it own management of IOMMU assisted
IO address space translations, so no default dma-mapping structures
should be initialized.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
include/linux/device.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index 5f4ff02..2e62371 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -253,6 +253,8 @@ struct device_driver {
/* disables bind/unbind via sysfs */
#define DRIVER_SUPPRESS_BIND_ATTRS(1 0)
+/* driver uses own methods to manage IO address space */
+#define DRIVER_HAS_OWN_IOMMU_MANAGER (1 1)
extern int __must_check driver_register(struct device_driver *drv);
extern void driver_unregister(struct device_driver *drv);
Could you comment if the approach of using flags in the struct driver
could be accepted? I've converted suppress_bind_attrs entry to flags to
avoid extending the structure, please see patch [PATCH 05/29] drivers:
convert suppress_bind_attrs parameter into flags.
Is this really necessary? What I did as part of an RFC series for Tegra
IOMMU support is keep this knowledge within the IOMMU driver rather than
export it to the driver core.
The idea being that the IOMMU driver wouldn't create an ARM DMA/IOMMU
mapping by default but rather allow individual drivers to be marked as
kernel-internal and use the DMA/IOMMU glue in that case. Drivers such
as DRM would use the IOMMU API directly.
Thierry
pgp4tBk3cYzvn.pgp
Description: PGP signature
Re: [PATCH] mfd: syscon: Decouple syscon interface from syscon devices
On Fri, 22 Aug 2014, Pankaj Dubey wrote:
From: Tomasz Figa t.f...@samsung.com
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated driver. However in certain use
cases it is desirable to make a device used with another driver a syscon
interface provider. For example, certain SoCs (e.g. Exynos) contain
system controller blocks which perform various functions such as power
domain control, CPU power management, low power mode control, but in
addition contain certain IP integration glue, such as various signal
masks, coprocessor power control, etc. In such case, there is a need to
have a dedicated driver for such system controller but also share
registers with other drivers. The latter is where the syscon interface
is helpful.
This patch decouples syscon object from syscon driver, so that it can be
registered from any driver in addition to the original syscon platform
driver.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
RFC patch [1] was posted by Tomasz Figa. This patch addresses some of
comments given by Arnd to RFC patch, and further decouples syscon from
device model. It also gives flexibility of registering with syscon at
early stage using device_node object.
It would be helpful if Arnd gave this revision his blessing (Ack).
[1]: https://lkml.org/lkml/2014/6/17/331
drivers/mfd/syscon.c | 112
include/linux/mfd/syscon.h | 14 ++
2 files changed, 86 insertions(+), 40 deletions(-)
diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
index ca15878..a91db30 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
@@ -14,6 +14,7 @@
[...]
struct regmap *syscon_regmap_lookup_by_pdevname(const char *s)
{
- struct device *dev;
- struct syscon *syscon;
-
- dev = driver_find_device(syscon_driver.driver, NULL, (void *)s,
- syscon_match_pdevname);
- if (!dev)
- return ERR_PTR(-EPROBE_DEFER);
-
- syscon = dev_get_drvdata(dev);
+ struct syscon *entry, *syscon = NULL;
+ struct platform_device *pdev = NULL;
+
+ spin_lock(syscon_list_slock);
+ list_for_each_entry(entry, syscon_list, list) {
+ pdev = of_find_device_by_node(entry-np);
White space error.
Did you run this through checkpatch.pl?
+ if (pdev !strcmp(dev_name(pdev-dev), s)) {
+ syscon = entry;
+ break;
+ }
+ }
+ spin_unlock(syscon_list_slock);
- return syscon-regmap;
+ return syscon ? syscon-regmap : ERR_PTR(-EPROBE_DEFER);
}
EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_pdevname);
[...]
--
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 10/29] drivers: add DRIVER_HAS_OWN_IOMMU_MANAGER flag
Hello,
On 2014-09-01 09:07, Thierry Reding wrote:
On Mon, Sep 01, 2014 at 07:22:32AM +0200, Marek Szyprowski wrote:
Hi Greg,
On 2014-08-05 12:47, Marek Szyprowski wrote:
This patch adds a new flags for device drivers. This flag instructs
kernel that the device driver does it own management of IOMMU assisted
IO address space translations, so no default dma-mapping structures
should be initialized.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
include/linux/device.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index 5f4ff02..2e62371 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -253,6 +253,8 @@ struct device_driver {
/* disables bind/unbind via sysfs */
#define DRIVER_SUPPRESS_BIND_ATTRS (1 0)
+/* driver uses own methods to manage IO address space */
+#define DRIVER_HAS_OWN_IOMMU_MANAGER (1 1)
extern int __must_check driver_register(struct device_driver *drv);
extern void driver_unregister(struct device_driver *drv);
Could you comment if the approach of using flags in the struct driver
could be accepted? I've converted suppress_bind_attrs entry to flags to
avoid extending the structure, please see patch [PATCH 05/29] drivers:
convert suppress_bind_attrs parameter into flags.
Is this really necessary? What I did as part of an RFC series for Tegra
IOMMU support is keep this knowledge within the IOMMU driver rather than
export it to the driver core.i
The problem with embedding the list of drivers that you would need to update
it everytime when you modify or extend iommu support in the other drivers.
I've tried also other approach, like adding respective notifiers to
individual
drivers to initialize custom iommu support (or disable default iommu
mapping)
before iommu driver gets initialized, but such solution is in my opinion too
complex and hard to understand if one is not familiar will all this stuff.
All in all it turned out that the simplest and most generic way is to simply
add the flag to the driver core. Flags might be also used in the future
to model other kinds of dependencies between device drivers and/or driver
core.
The idea being that the IOMMU driver wouldn't create an ARM DMA/IOMMU
mapping by default but rather allow individual drivers to be marked as
kernel-internal and use the DMA/IOMMU glue in that case. Drivers such
as DRM would use the IOMMU API directly.
Best regards
--
Marek Szyprowski, PhD
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 3/5] phy: exynos5-usbdrd: Add facility for VBUS-BOOST-5V supply
Hi Felipe,
On Fri, Aug 29, 2014 at 12:46 AM, Felipe Balbi ba...@ti.com wrote:
hi,
On Thu, Aug 28, 2014 at 01:31:58PM +0530, Vivek Gautam wrote:
@@ -457,11 +458,19 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
clk_prepare_enable(phy_drd-ref_clk);
/* Enable VBUS supply */
+ if (phy_drd-vbus_boost) {
+ ret = regulator_enable(phy_drd-vbus_boost);
+ if (ret) {
+ dev_err(phy_drd-dev,
+ Failed to enable VBUS boost supply\n);
+ goto fail_vbus;
+ }
+ }
really this is nitpicking, but can you add a blank line here just make
my inner child happy ? :-)
Sure will add an extra line here and similar instances of this change.
@@ -470,6 +479,9 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
return 0;
+fail_vbus_boost:
+ if (phy_drd-vbus_boost)
+ regulator_disable(phy_drd-vbus_boost);
same here
--
balbi
--
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
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 5/5] phy: exynos5-usbdrd: Adding Kconfig dependency for Exynos7
On Thu, Aug 28, 2014 at 8:36 PM, Daniele Forsi dfo...@gmail.com wrote: 2014-08-28 10:02 GMT+02:00 Vivek Gautam: This USB 3.0 PHY controller is also present on Exynos7 platform, so adding the dependency on ARCH_EXYNOS7 for this driver. +++ b/drivers/phy/Kconfig @@ -186,7 +186,7 @@ config PHY_EXYNOS5250_USB2 config PHY_EXYNOS5_USBDRD tristate Exynos5 SoC series USB DRD PHY driver - depends on ARCH_EXYNOS5 OF + depends on (ARCH_EXYNOS5 || ARCH_EXYNOS7) OF shouldn't that prompt and its help text be updated to mention also Exynos7? Right, even that has to be updated accordingly. Will update the same in next version of the patch. Thanks for pointing this. -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- 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] drivers: mfd: exynos-pmu: Add support for Exynos7
On Mon, 01 Sep 2014, Abhilash Kesavan wrote: Add intial PMU settings for exynos7. This is required for future suspend-to-ram and cpuidle support. Signed-off-by: Eunseok Choi es10.c...@samsung.com Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com --- This patch has been tested on an Exynos7 espresso board and is based on Kgene's tree (for-next branch). Following are the dependencies: 1) Support 64bit Cortex A57 based Exynos7 SoC http://www.spinics.net/lists/arm-kernel/msg357380.html 2) mfd: syscon: Decouple syscon interface from syscon devices http://www.spinics.net/lists/linux-samsung-soc/msg35906.html 3) ARM: EXYNOS: Add platform driver support for Exynos PMU http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/275675.html 4) ARM: EXYNOS: Move PMU specific definitions from common.h http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/270655.html 5) ARM: EXYNOS: Move pmu specific header files under linux/mfd/samsung https://lkml.org/lkml/2014/4/28/217 6) drivers: mfd: Add support for Exynos PMU driver https://lkml.org/lkml/2014/4/28/332 NOTE: The above dependencies are not final yet, especially the movement of exynos pmu driver to the mfd directory. I will re-work this patch when the final location for exynos PMU driver is decided. Let me know when this patch is ready to go in and I'll review. .../devicetree/bindings/arm/samsung/pmu.txt|1 + arch/arm64/boot/dts/exynos7.dtsi |5 + drivers/mfd/exynos-pmu.c | 285 include/linux/mfd/samsung/exynos-regs-pmu.h| 212 +++ 4 files changed, 503 insertions(+) This all needs to be broken up into seperate patches. Also, see: Documentation/devicetree/bindings/submitting-patches.txt. -- 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 RESEND] ARM: EXYNOS: Do not calculate boot address twice
On pią, 2014-07-04 at 17:41 +0900, Kukjin Kim wrote: Krzysztof Kozlowski wrote: Commit b3205dea8fbf (ARM: EXYNOS: Map SYSRAM through generic DT bindings) introduced local variable boot_reg where boot address from cpu_boot_reg() call is stored. Re-use it instead calling cpu_boot_reg() again. Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com --- arch/arm/mach-exynos/platsmp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c index 1c8d31e39520..55ed2e6729c5 100644 --- a/arch/arm/mach-exynos/platsmp.c +++ b/arch/arm/mach-exynos/platsmp.c @@ -155,7 +155,7 @@ static int exynos_boot_secondary(unsigned int cpu, struct task_struct *idle) ret = PTR_ERR(boot_reg); goto fail; } - __raw_writel(boot_addr, cpu_boot_reg(phys_cpu)); + __raw_writel(boot_addr, boot_reg); } call_firmware_op(cpu_boot, phys_cpu); @@ -242,7 +242,7 @@ static void __init exynos_smp_prepare_cpus(unsigned int max_cpus) if (IS_ERR(boot_reg)) break; - __raw_writel(boot_addr, cpu_boot_reg(phys_cpu)); + __raw_writel(boot_addr, boot_reg); } } } -- 1.9.1 Oh, good catch. will apply :-) Hi Kukjin, I cannot find this patch in your tree or in next. Did you applied this? Best regards, Krzysztof 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 v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Hi Kevin, On Fri, Aug 29, 2014 at 8:33 PM, Kevin Hilman khil...@kernel.org wrote: Hi Thomas, On Fri, Aug 29, 2014 at 5:52 AM, Thomas Abraham ta.oma...@gmail.com wrote: Hi Kevin, On Wed, Aug 27, 2014 at 3:55 AM, Kevin Hilman khil...@linaro.org wrote: On Tue, Aug 26, 2014 at 8:15 AM, Kevin Hilman khil...@linaro.org wrote: On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap k.chan...@samsung.com wrote: [...] Can you clarify how you're setting the voltages to ensure stability? below is the diff : wip/exynos/integ Thanks. I've applied your patch, and bootup shows vdd_arm and vdd_kfc at 1500mV, but still when booting with cpuidle enabled (bL switcher disabled), I'm seeing lockups with no kernel output. With CPUidle disabled, things are pretty stable. What tree are you using to test this out on 5420? I'm using mainline v3.17-rc1 + DT patch for CPUidle and this cpufreq series. See my wip/exynos/integ branch at git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git. I mis-stated this. Actually my tree is based on the v3.17-rc1 branch of the exynos-reference tree[1] + the above mentioned patches for cpuidle and cpufreq. Also, I've narrowed down the instability a bit, and it's not related to CPUidle. I can now trigger a boot hang even without CPUidle enabled. Here's a quick way to cause a boot lockup. With the switcher disabled, I enable CPUfreq and set the default governor to performance. As soon as cpufreq driver loads, it tries to use the top frequences for both clusters, and it hangs. Selectively disabling frequencies, I narrowed it down to the 1.3GHz and 1.2GHz frequencies of the little cluster. With these commented out in the DT, it will fully boot with the performance governor enabled. So that leads to the question. Are all of the operating points in exynos5420.dtsi valid for exynos5800, and have they been validated? I tried to recreate the boot lockup issue using the same steps you listed above for the Exynos5800 peach-pi platform (Chromebook2), but I do not see any issues. I can see both clusters with max clock speed after boot (1.8GHz and 1.3GHz). I am using v3.17-rc2 + CPUFreq Patches + max77802 regulator support patches for Chromebook2 + temp hack to set A15 voltage to 1.35V and A7 voltage to 1.3V. Can you share your branch and temp hack(s) as well as your defconfig? I'm using the v3.17-rc1 branch from the exynos tree (which includes the max77802 series) but also has a bunch of other stuff which may be causing the issue. It would be good if I can reproduce your exact tree/branch and see if I still have the same problem. The branch with the patches that have been used to test cpufreq on Exynos5800 is available at https://github.com/exynos-reference/kernel/tree/exynos5-v3.17-rc3-temp-cpufreq Please let me know if this works or if there are any issues. Thanks, Thomas. Thanks for looking into this, Kevin -- 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 10/29] drivers: add DRIVER_HAS_OWN_IOMMU_MANAGER flag
On Monday 01 September 2014 09:53:29 Marek Szyprowski wrote:
On 2014-09-01 09:07, Thierry Reding wrote:
On Mon, Sep 01, 2014 at 07:22:32AM +0200, Marek Szyprowski wrote:
Hi Greg,
On 2014-08-05 12:47, Marek Szyprowski wrote:
This patch adds a new flags for device drivers. This flag instructs
kernel that the device driver does it own management of IOMMU assisted
IO address space translations, so no default dma-mapping structures
should be initialized.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
include/linux/device.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index 5f4ff02..2e62371 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -253,6 +253,8 @@ struct device_driver {
/* disables bind/unbind via sysfs */
#define DRIVER_SUPPRESS_BIND_ATTRS (1 0)
+/* driver uses own methods to manage IO address space */
+#define DRIVER_HAS_OWN_IOMMU_MANAGER (1 1)
extern int __must_check driver_register(struct device_driver *drv);
extern void driver_unregister(struct device_driver *drv);
Could you comment if the approach of using flags in the struct driver
could be accepted? I've converted suppress_bind_attrs entry to flags to
avoid extending the structure, please see patch [PATCH 05/29] drivers:
convert suppress_bind_attrs parameter into flags.
Is this really necessary? What I did as part of an RFC series for Tegra
IOMMU support is keep this knowledge within the IOMMU driver rather than
export it to the driver core.i
The problem with embedding the list of drivers that you would need to update
it everytime when you modify or extend iommu support in the other drivers.
I've tried also other approach, like adding respective notifiers to
individual
drivers to initialize custom iommu support (or disable default iommu
mapping)
before iommu driver gets initialized, but such solution is in my opinion too
complex and hard to understand if one is not familiar will all this stuff.
All in all it turned out that the simplest and most generic way is to simply
add the flag to the driver core. Flags might be also used in the future
to model other kinds of dependencies between device drivers and/or driver
core.
I don't get it yet. I would expect that a driver doing its own management
of the iommu gets to use the linux/iommu.h interfaces, while a driver
using the default iommu setup uses linux/dma-mapping.h. Who do you think
needs to set this flag, and who needs to read it?
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] usb: dwc3: exynos: remove usb_phy_generic support
Hi, On Friday, August 29, 2014 11:33:04 AM Greg Kroah-Hartman wrote: On Fri, Aug 29, 2014 at 11:02:52AM +0200, Bartlomiej Zolnierkiewicz wrote: On Thursday, August 28, 2014 12:29:52 PM Greg Kroah-Hartman wrote: On Thu, Aug 28, 2014 at 08:11:04PM +0200, Bartlomiej Zolnierkiewicz wrote: [ added Alan and Greg to cc: ] Hi, On Wednesday, August 27, 2014 11:42:25 PM Vivek Gautam wrote: Hi Baltlomiej, On Wed, Aug 27, 2014 at 1:22 PM, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: dwc3 driver is using the new Exynos5 SoC series USB DRD PHY driver (PHY_EXYNOS5_USBDRD which selects GENERIC_PHY) as can be seen by looking at the following commits: 7a4cf0fde054 (ARM: dts: Update DWC3 usb controller to use new phy driver for exynos5250) f070267b5fc1 (ARM: dts: Enable support for DWC3 controller for exynos5420) Thus remove unused usb_phy_generic support from dwc3 Exynos glue layer. [ The code that is being removed is harmful in the context of multi_v7_defconfig and enabling EHCI support for Samsung S5P/EXYNOS SoC Series (USB_EHCI_EXYNOS) + OHCI support for Samsung S5P/EXYNOS SoC Series (USB_OHCI_EXYNOS) because EHCI support for OMAP3 and later chips (USB_EHCI_HCD_OMAP) selects NOP USB Transceiver Driver (NOP_USB_XCEIV). NOP USB driver attaches itself to usb_phy_generic platform devices created by dwc3 Exynos glue layer and later causes Exynos EHCI driver to fail probe and Exynos OHCI driver to hang on probe (as observed on Exynos5250 Arndale board). ] The issue with EHCI and OHCI on exynos platforms is that until now they also request usb-phy and only later if they don't find one, they go ahead and get a 'phy' generic. Fortunately we missed this issue with exynos_defconfig, and as you rightly mentioned with multi_v7_defconfig, the NOP_USB_XCEIV gets enabled and EHCI and OHCI exynos get no-op usb-phy, which actually blocks EHCI/OHCI from initializing the real PHYs. This issue is resolved with patches: [PATCH v2 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support [PATCH v2 2/2] usb: host: ohci-exynos: Remove unnecessary usb-phy support wherein we are completely removing the usb-phy support from ehci/ohci-exynos. So with these patches we should not see the issue mentioned by you. Indeed, your patches fix the issue. Greg, could these two patches ([1] [2]) get merged quickly, pretty please (they were already acked by Alan)? They are not a mere cleanups because they fix the actual problem with using multi_v7_defconfig which in turn has been blocking Olof's defconfig update patch [3] for quite some time now. Moreover these patches are limited to Exynos host drivers so they should be pretty safe when it comes to potential regressions. [1] http://www.spinics.net/lists/linux-usb/msg112294.html [2] http://www.spinics.net/lists/linux-usb/msg112293.html [3] http://www.spinics.net/lists/arm-kernel/msg349654.html merged for 3.18-rc1, or do you need them for 3.17-final? If it is not too much trouble please push them to 3.17-final. They don't meet the regression or bugfix rule at all, so I can't do this, sorry. I'll queue them up for 3.18. These patches fix a real problem of boot hang when enabling Exynos USB host drivers and using ARM multiplatform config so IMHO they fall into bugfix category. I already reverted one patch for exynos for 3.17-final that is sitting in my tree to go to Linus soon as you all didn't seem to want it anymore, so I'm getting really confused here... These two patches are a replacement for the one reverted and they just remove the old code instead of keeping it as fallback. This means that the reverted patch was not breaking anything and these two new patches could have been also done as incremental ones. Sorry for the confusion. As they came in too late for 3.17-rc1, they will have to wait for 3.18-rc1. Okay.. Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics -- 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] drm/panel: simple: Add AUO B116XW03 panel support
The AUO B116XW03 is a 11.6 HD TFT LCD panel connecting to a LVDS
interface and with an integrated LED backlight unit.
This panel is used on the Samsung Chromebook(XE303C12).
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/panel/auo,b116xw03.txt |7 ++
drivers/gpu/drm/panel/panel-simple.c | 25
2 files changed, 32 insertions(+)
create mode 100644 Documentation/devicetree/bindings/panel/auo,b116xw03.txt
diff --git a/Documentation/devicetree/bindings/panel/auo,b116xw03.txt
b/Documentation/devicetree/bindings/panel/auo,b116xw03.txt
new file mode 100644
index 000..690d0a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/auo,b116xw03.txt
@@ -0,0 +1,7 @@
+AU Optronics Corporation 11.6 HD (1366x768) color TFT-LCD panel
+
+Required properties:
+- compatible: should be auo,b116xw03
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 4ce1db0..51566e0 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -352,6 +352,28 @@ static const struct panel_desc auo_b101aw03 = {
},
};
+static const struct drm_display_mode auo_b116xw03_mode = {
+ .clock = 70589,
+ .hdisplay = 1366,
+ .hsync_start = 1366 + 40,
+ .hsync_end = 1366 + 40 + 40,
+ .htotal = 1366 + 40 + 40 + 32,
+ .vdisplay = 768,
+ .vsync_start = 768 + 10,
+ .vsync_end = 768 + 10 + 12,
+ .vtotal = 768 + 10 + 12 + 6,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc auo_b116xw03 = {
+ .modes = auo_b116xw03_mode,
+ .num_modes = 1,
+ .size = {
+ .width = 256,
+ .height = 144,
+ },
+};
+
static const struct drm_display_mode auo_b133xtn01_mode = {
.clock = 69500,
.hdisplay = 1366,
@@ -616,6 +638,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = auo,b101aw03,
.data = auo_b101aw03,
}, {
+ .compatible = auo,b116xw03,
+ .data = auo_b116xw03,
+ }, {
.compatible = auo,b133htn01,
.data = auo_b133htn01,
}, {
--
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] mfd: syscon: Decouple syscon interface from syscon devices
On Monday 01 September 2014 08:49:18 Lee Jones wrote: On Fri, 22 Aug 2014, Pankaj Dubey wrote: From: Tomasz Figa t.f...@samsung.com Currently a syscon entity can be only registered directly through a platform device that binds to a dedicated driver. However in certain use cases it is desirable to make a device used with another driver a syscon interface provider. For example, certain SoCs (e.g. Exynos) contain system controller blocks which perform various functions such as power domain control, CPU power management, low power mode control, but in addition contain certain IP integration glue, such as various signal masks, coprocessor power control, etc. In such case, there is a need to have a dedicated driver for such system controller but also share registers with other drivers. The latter is where the syscon interface is helpful. This patch decouples syscon object from syscon driver, so that it can be registered from any driver in addition to the original syscon platform driver. Signed-off-by: Tomasz Figa t.f...@samsung.com Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- RFC patch [1] was posted by Tomasz Figa. This patch addresses some of comments given by Arnd to RFC patch, and further decouples syscon from device model. It also gives flexibility of registering with syscon at early stage using device_node object. It would be helpful if Arnd gave this revision his blessing (Ack). I never saw a reason why we don't take this all the way as discussed a few times: Completely remove the dependency of syscon on having a platform driver for it, and make it possible to just call syscon_regmap_lookup_by_phandle() without having to register it first. 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
[PATCH V3 1/2] ARM: dts: Add DT changes for display on snow
Add DT nodes for ptn3460 bridge chip and panel.
Add backlight enable pin and backlight power supply for pwm-backlight.
Also add bridge phandle needed by dp to enable display on snow.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
Changes since V1:
-- Remove simple-panel compatible string.
-- Use GPIO_ACTIVE_HIGH instead of 0.
-- Change panel node naming from panel-simple to panel.
Changes since V2:
-- Use proper compatible string: auo,b116xw03
arch/arm/boot/dts/exynos5250-snow.dts | 41 ++---
1 file changed, 22 insertions(+), 19 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index f2b8c41..1ac9709 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -9,6 +9,7 @@
*/
/dts-v1/;
+#include dt-bindings/gpio/gpio.h
#include exynos5250.dtsi
#include exynos5250-cros-common.dtsi
@@ -181,7 +182,7 @@
dcdc3 {
ti,enable-ext-control;
};
- fet1 {
+ fet1: fet1 {
regulator-name = vcd_led;
ti,overcurrent-wait = 3;
};
@@ -204,7 +205,7 @@
regulator-always-on;
ti,overcurrent-wait = 3;
};
- fet6 {
+ fet6: fet6 {
regulator-name = lcd_vdd;
ti,overcurrent-wait = 3;
};
@@ -253,6 +254,15 @@
pinctrl-0 = max98095_en;
pinctrl-names = default;
};
+
+ ptn3460: lvds-bridge@20 {
+ compatible = nxp,ptn3460;
+ reg = 0x20;
+ powerdown-gpios = gpy2 5 GPIO_ACTIVE_HIGH;
+ reset-gpios = gpx1 5 GPIO_ACTIVE_HIGH;
+ edid-emulation = 5;
+ panel = panel;
+ };
};
i2s0: i2s@0383 {
@@ -300,11 +310,13 @@
vdd_pll-supply = ldo8_reg;
};
- backlight {
+ backlight: backlight {
compatible = pwm-backlight;
pwms = pwm 0 100 0;
brightness-levels = 0 100 500 1000 1500 2000 2500 2800;
default-brightness-level = 7;
+ enable-gpios = gpx3 0 GPIO_ACTIVE_HIGH;
+ power-supply = fet1;
pinctrl-0 = pwm0_out;
pinctrl-names = default;
};
@@ -314,6 +326,12 @@
samsung,invert-vclk;
};
+ panel: panel {
+ compatible = auo,b116xw03;
+ power-supply = fet6;
+ backlight = backlight;
+ };
+
dp-controller@145B {
status = okay;
pinctrl-names = default;
@@ -325,22 +343,7 @@
samsung,link-rate = 0x0a;
samsung,lane-count = 2;
samsung,hpd-gpio = gpx0 7 0;
-
- display-timings {
- native-mode = timing1;
-
- timing1: timing@1 {
- clock-frequency = 70589280;
- hactive = 1366;
- vactive = 768;
- hfront-porch = 40;
- hback-porch = 40;
- hsync-len = 32;
- vback-porch = 10;
- vfront-porch = 12;
- vsync-len = 6;
- };
- };
+ bridge = ptn3460;
};
};
--
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
[PATCH V3 2/2] ARM: dts: Add DT changes for display on peach_pit
Add DT nodes for ps8622 bridge chip and panel.
Add backlight power supply for pwm-backlight.
Also add bridge phandle needed by dp to enable display on peach_pit.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
Changes since V1:
-- Remove simple-panel compatible string.
-- Use GPIO_ACTIVE_HIGH instead of 0.
-- Change panel node naming from panel-simple to panel.
Changes since V2:
-- Use proper compatible string: auo,b116xw03
arch/arm/boot/dts/exynos5420-peach-pit.dts | 36 +++-
1 file changed, 19 insertions(+), 17 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 228a6b1..1070a31 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -30,11 +30,12 @@
i2c20 = /spi@12d4/cros-ec@0/i2c-tunnel;
};
- backlight {
+ backlight: backlight {
compatible = pwm-backlight;
pwms = pwm 0 100 0;
brightness-levels = 0 100 500 1000 1500 2000 2500 2800;
default-brightness-level = 7;
+ power-supply = tps65090_fet1;
pinctrl-0 = pwm0_out;
pinctrl-names = default;
};
@@ -100,6 +101,12 @@
regulator-boot-on;
regulator-always-on;
};
+
+ panel: panel {
+ compatible = auo,b116xw03;
+ power-supply = tps65090_fet6;
+ backlight = backlight;
+ };
};
dp {
@@ -113,22 +120,7 @@
samsung,link-rate = 0x06;
samsung,lane-count = 2;
samsung,hpd-gpio = gpx2 6 0;
-
- display-timings {
- native-mode = timing1;
-
- timing1: timing@1 {
- clock-frequency = 70589280;
- hactive = 1366;
- vactive = 768;
- hfront-porch = 40;
- hback-porch = 40;
- hsync-len = 32;
- vback-porch = 10;
- vfront-porch = 12;
- vsync-len = 6;
- };
- };
+ bridge = ps8625;
};
fimd {
@@ -155,6 +147,16 @@
pinctrl-names = default;
pinctrl-0 = max98090_irq;
};
+
+ ps8625: lvds-bridge@48 {
+ compatible = parade,ps8625;
+ reg = 0x48;
+ sleep-gpios = gpx3 5 GPIO_ACTIVE_HIGH;
+ reset-gpios = gpy7 7 GPIO_ACTIVE_HIGH;
+ lane-count = 2;
+ panel = panel;
+ use-external-pwm;
+ };
};
hsi2c_9 {
--
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 10/29] drivers: add DRIVER_HAS_OWN_IOMMU_MANAGER flag
Hello,
On 2014-09-01 11:38, Arnd Bergmann wrote:
On Monday 01 September 2014 09:53:29 Marek Szyprowski wrote:
On 2014-09-01 09:07, Thierry Reding wrote:
On Mon, Sep 01, 2014 at 07:22:32AM +0200, Marek Szyprowski wrote:
Hi Greg,
On 2014-08-05 12:47, Marek Szyprowski wrote:
This patch adds a new flags for device drivers. This flag instructs
kernel that the device driver does it own management of IOMMU assisted
IO address space translations, so no default dma-mapping structures
should be initialized.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
include/linux/device.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index 5f4ff02..2e62371 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -253,6 +253,8 @@ struct device_driver {
/* disables bind/unbind via sysfs */
#define DRIVER_SUPPRESS_BIND_ATTRS (1 0)
+/* driver uses own methods to manage IO address space */
+#define DRIVER_HAS_OWN_IOMMU_MANAGER (1 1)
extern int __must_check driver_register(struct device_driver *drv);
extern void driver_unregister(struct device_driver *drv);
Could you comment if the approach of using flags in the struct driver
could be accepted? I've converted suppress_bind_attrs entry to flags to
avoid extending the structure, please see patch [PATCH 05/29] drivers:
convert suppress_bind_attrs parameter into flags.
Is this really necessary? What I did as part of an RFC series for Tegra
IOMMU support is keep this knowledge within the IOMMU driver rather than
export it to the driver core.i
The problem with embedding the list of drivers that you would need to update
it everytime when you modify or extend iommu support in the other drivers.
I've tried also other approach, like adding respective notifiers to
individual
drivers to initialize custom iommu support (or disable default iommu
mapping)
before iommu driver gets initialized, but such solution is in my opinion too
complex and hard to understand if one is not familiar will all this stuff.
All in all it turned out that the simplest and most generic way is to simply
add the flag to the driver core. Flags might be also used in the future
to model other kinds of dependencies between device drivers and/or driver
core.
I don't get it yet. I would expect that a driver doing its own management
of the iommu gets to use the linux/iommu.h interfaces, while a driver
using the default iommu setup uses linux/dma-mapping.h.
You are right.
Who do you think needs to set this flag, and who needs to read it?
In the proposed solution Exynos IOMMU driver creates a separate IO
address space
for every client device in a system and binds it to the default
dma-mapping space
for the given device. When drivers are doing its own management of IO
address
space, instead of relying on what is available by default with dma-mapping
interface, this will require releasing of the previously created default
structures and resources. So this flag is set by the driver doing its own
management of io address space. The flags is then checked by Exynos
IOMMU driver
to avoid creating the default dma-mapping address space for devices
which driver
does its own management.
Best regards
--
Marek Szyprowski, PhD
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 v3 0/8] thermal: exynos: various cleanups
On Thu, Aug 28, 2014 at 8:19 PM, Eduardo Valentin edubez...@gmail.com wrote: Amit, On Thu, Jul 31, 2014 at 07:10:58PM +0200, Bartlomiej Zolnierkiewicz wrote: Hi, This patch series contains various cleanups for EXYNOS thermal driver. Overall it decreases driver's LOC by 9%. It is based on next-20140731 kernel. It should not cause any functionality changes. Did you have the time to test this series? Hi Eduardo/Bartlomiej, For the whole series tested on exynos5250 based arndale board. Tested-by: Amit Daniel Kachhap amit.dan...@samsung.com Sorry for the delay as I was busy in some internal work. Thanks, Amit D Changes since v2 (https://lkml.org/lkml/2014/6/17/436): - synced patches against next-20140731 - dropped patch thermal: exynos: remove dead code for TYPE_TWO_POINT_TRIMMING calibration (newly added Exynos3250 SoC support uses TYPE_TWO_POINT_TRIMMING calibration) - updated patch description for patch #2 - dropped Reviewed-by from Amit from patch #8 (due to changed scope of the patch) Changes since v1 (https://lkml.org/lkml/2014/5/5/194): - synced patches against next-20140617 - merged patch thermal: exynos: remove unused defines into thermal: exynos: remove unused struct exynos_tmu_registers entries one (per request from Eduardo) - improved patch descriptions for patches #1-5 - fixed documentation for pdata-gain and pdata-reference_voltage - added Reviewed-by from Amit to patches #6, #7 and #10 - added missing Acked-by from Kyungmin Park Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics Bartlomiej Zolnierkiewicz (8): thermal: exynos: remove unused struct exynos_tmu_registers entries thermal: exynos: remove dead code for HW_MODE calibration thermal: exynos: remove redundant pdata checks from exynos_tmu_initialize() thermal: exynos: remove redundant threshold_code checks from exynos_tmu_initialize() thermal: exynos: simplify temp_to_code() and code_to_temp() thermal: exynos: cache non_hw_trigger_levels in pdata thermal: exynos: remove redundant pdata checks from exynos_tmu_control() thermal: exynos: remove identical values from exynos*_tmu_registers structures drivers/thermal/samsung/exynos_thermal_common.h | 1 - drivers/thermal/samsung/exynos_tmu.c| 126 +--- drivers/thermal/samsung/exynos_tmu.h| 74 +- drivers/thermal/samsung/exynos_tmu_data.c | 56 ++- drivers/thermal/samsung/exynos_tmu_data.h | 31 +- 5 files changed, 35 insertions(+), 253 deletions(-) -- 1.8.2.3 -- To unsubscribe from this list: send the line unsubscribe linux-pm 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 -- 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 0/8] thermal: exynos: various cleanups
Amit On Mon, Sep 1, 2014 at 6:53 AM, amit daniel kachhap amit.dan...@samsung.com wrote: On Thu, Aug 28, 2014 at 8:19 PM, Eduardo Valentin edubez...@gmail.com wrote: Amit, On Thu, Jul 31, 2014 at 07:10:58PM +0200, Bartlomiej Zolnierkiewicz wrote: Hi, This patch series contains various cleanups for EXYNOS thermal driver. Overall it decreases driver's LOC by 9%. It is based on next-20140731 kernel. It should not cause any functionality changes. Did you have the time to test this series? Hi Eduardo/Bartlomiej, For the whole series tested on exynos5250 based arndale board. Tested-by: Amit Daniel Kachhap amit.dan...@samsung.com Thanks! I will pull the series on my tree. Sorry for the delay as I was busy in some internal work. Thanks, Amit D Changes since v2 (https://lkml.org/lkml/2014/6/17/436): - synced patches against next-20140731 - dropped patch thermal: exynos: remove dead code for TYPE_TWO_POINT_TRIMMING calibration (newly added Exynos3250 SoC support uses TYPE_TWO_POINT_TRIMMING calibration) - updated patch description for patch #2 - dropped Reviewed-by from Amit from patch #8 (due to changed scope of the patch) Changes since v1 (https://lkml.org/lkml/2014/5/5/194): - synced patches against next-20140617 - merged patch thermal: exynos: remove unused defines into thermal: exynos: remove unused struct exynos_tmu_registers entries one (per request from Eduardo) - improved patch descriptions for patches #1-5 - fixed documentation for pdata-gain and pdata-reference_voltage - added Reviewed-by from Amit to patches #6, #7 and #10 - added missing Acked-by from Kyungmin Park Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics Bartlomiej Zolnierkiewicz (8): thermal: exynos: remove unused struct exynos_tmu_registers entries thermal: exynos: remove dead code for HW_MODE calibration thermal: exynos: remove redundant pdata checks from exynos_tmu_initialize() thermal: exynos: remove redundant threshold_code checks from exynos_tmu_initialize() thermal: exynos: simplify temp_to_code() and code_to_temp() thermal: exynos: cache non_hw_trigger_levels in pdata thermal: exynos: remove redundant pdata checks from exynos_tmu_control() thermal: exynos: remove identical values from exynos*_tmu_registers structures drivers/thermal/samsung/exynos_thermal_common.h | 1 - drivers/thermal/samsung/exynos_tmu.c| 126 +--- drivers/thermal/samsung/exynos_tmu.h| 74 +- drivers/thermal/samsung/exynos_tmu_data.c | 56 ++- drivers/thermal/samsung/exynos_tmu_data.h | 31 +- 5 files changed, 35 insertions(+), 253 deletions(-) -- 1.8.2.3 -- To unsubscribe from this list: send the line unsubscribe linux-pm 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 -- Eduardo Bezerra Valentin -- 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] mfd: syscon: Decouple syscon interface from syscon devices
On Mon, 01 Sep 2014, Arnd Bergmann wrote: On Monday 01 September 2014 08:49:18 Lee Jones wrote: On Fri, 22 Aug 2014, Pankaj Dubey wrote: From: Tomasz Figa t.f...@samsung.com Currently a syscon entity can be only registered directly through a platform device that binds to a dedicated driver. However in certain use cases it is desirable to make a device used with another driver a syscon interface provider. For example, certain SoCs (e.g. Exynos) contain system controller blocks which perform various functions such as power domain control, CPU power management, low power mode control, but in addition contain certain IP integration glue, such as various signal masks, coprocessor power control, etc. In such case, there is a need to have a dedicated driver for such system controller but also share registers with other drivers. The latter is where the syscon interface is helpful. This patch decouples syscon object from syscon driver, so that it can be registered from any driver in addition to the original syscon platform driver. Signed-off-by: Tomasz Figa t.f...@samsung.com Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- RFC patch [1] was posted by Tomasz Figa. This patch addresses some of comments given by Arnd to RFC patch, and further decouples syscon from device model. It also gives flexibility of registering with syscon at early stage using device_node object. It would be helpful if Arnd gave this revision his blessing (Ack). I never saw a reason why we don't take this all the way as discussed a few times: Completely remove the dependency of syscon on having a platform driver for it, and make it possible to just call syscon_regmap_lookup_by_phandle() without having to register it first. I think this sounds like a good end-state. Migrating over by supporting both methods in this way does sound like the correct thing to do though. Doing so is likely to dramatically reduce the effect on current users. -- 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] mfd: syscon: Decouple syscon interface from syscon devices
Hi Arnd, -Original Message- From: Arnd Bergmann [mailto:a...@arndb.de] Sent: Monday, September 01, 2014 4:07 PM To: Lee Jones Cc: Pankaj Dubey; linux-arm-ker...@lists.infradead.org; linux-samsung- s...@vger.kernel.org; linux-ker...@vger.kernel.org; kgene@samsung.com; li...@arm.linux.org.uk; vikas.saj...@samsung.com; jo...@samsung.com; naus...@samsung.com; thomas...@samsung.com; chow@samsung.com; Tomasz Figa; broo...@kernel.org Subject: Re: [PATCH] mfd: syscon: Decouple syscon interface from syscon devices On Monday 01 September 2014 08:49:18 Lee Jones wrote: On Fri, 22 Aug 2014, Pankaj Dubey wrote: From: Tomasz Figa t.f...@samsung.com Currently a syscon entity can be only registered directly through a platform device that binds to a dedicated driver. However in certain use cases it is desirable to make a device used with another driver a syscon interface provider. For example, certain SoCs (e.g. Exynos) contain system controller blocks which perform various functions such as power domain control, CPU power management, low power mode control, but in addition contain certain IP integration glue, such as various signal masks, coprocessor power control, etc. In such case, there is a need to have a dedicated driver for such system controller but also share registers with other drivers. The latter is where the syscon interface is helpful. This patch decouples syscon object from syscon driver, so that it can be registered from any driver in addition to the original syscon platform driver. Signed-off-by: Tomasz Figa t.f...@samsung.com Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- RFC patch [1] was posted by Tomasz Figa. This patch addresses some of comments given by Arnd to RFC patch, and further decouples syscon from device model. It also gives flexibility of registering with syscon at early stage using device_node object. It would be helpful if Arnd gave this revision his blessing (Ack). I never saw a reason why we don't take this all the way as discussed a few times: Completely remove the dependency of syscon on having a platform driver for it, and make it possible to just call syscon_regmap_lookup_by_phandle() without having to register it first. Please have a look at this thread [1], where we discussed the need of syscon as platform device. Looks like still there are users of syscon_regmap_lookup_by_pdevname (clps711x.c). So we can't make it completely independent of platform_device. [1] https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg35708.html 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 10/29] drivers: add DRIVER_HAS_OWN_IOMMU_MANAGER flag
On Monday 01 September 2014 12:47:08 Marek Szyprowski wrote: Who do you think needs to set this flag, and who needs to read it? In the proposed solution Exynos IOMMU driver creates a separate IO address space for every client device in a system and binds it to the default dma-mapping space for the given device. When drivers are doing its own management of IO address space, instead of relying on what is available by default with dma-mapping interface, this will require releasing of the previously created default structures and resources. So this flag is set by the driver doing its own management of io address space. The flags is then checked by Exynos IOMMU driver to avoid creating the default dma-mapping address space for devices which driver does its own management. I don't completely understand it yet. I would assume the device to be added to the default domain at device creation time (of_platform_populate), way before we know which device driver is going to be used. How can this prevent the iommu driver from doing the association with the domain? 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 10/29] drivers: add DRIVER_HAS_OWN_IOMMU_MANAGER flag
Hello, On 2014-09-01 13:56, Arnd Bergmann wrote: On Monday 01 September 2014 12:47:08 Marek Szyprowski wrote: Who do you think needs to set this flag, and who needs to read it? In the proposed solution Exynos IOMMU driver creates a separate IO address space for every client device in a system and binds it to the default dma-mapping space for the given device. When drivers are doing its own management of IO address space, instead of relying on what is available by default with dma-mapping interface, this will require releasing of the previously created default structures and resources. So this flag is set by the driver doing its own management of io address space. The flags is then checked by Exynos IOMMU driver to avoid creating the default dma-mapping address space for devices which driver does its own management. I don't completely understand it yet. I would assume the device to be added to the default domain at device creation time (of_platform_populate), way before we know which device driver is going to be used. How can this prevent the iommu driver from doing the association with the domain? of_platform_populate() is too early to do the association, because that time the exynos iommu driver is even not yet probed. The association with default dma-mapping domain is done in IOMMU_GROUP_NOTIFY_BIND_DRIVER notifier, just before binding the driver to the given device. This way iommu driver can check dev-driver-flags and skip creating default dma-mapping domain if driver announces that it wants to handle it by itself. Best regards -- Marek Szyprowski, PhD 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
[PATCH] drm/exynos: update to use component match support
Update Exynos's DRM driver to use component match support rater than
add_components.
Signed-off-by: Inki Dae inki@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 40 ++-
1 file changed, 18 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index feee991..dae62c2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -503,16 +503,15 @@ static int compare_of(struct device *dev, void *data)
return dev == (struct device *)data;
}
-static int exynos_drm_add_components(struct device *dev, struct master *m)
+static struct component_match *exynos_drm_match_add(struct device *dev)
{
+ struct component_match *match = NULL;
struct component_dev *cdev;
unsigned int attach_cnt = 0;
mutex_lock(drm_component_lock);
list_for_each_entry(cdev, drm_component_list, list) {
- int ret;
-
/*
* Add components to master only in case that crtc and
* encoder/connector device objects exist.
@@ -527,16 +526,10 @@ static int exynos_drm_add_components(struct device *dev,
struct master *m)
/*
* fimd and dpi modules have same device object so add
* only crtc device object in this case.
-*
-* TODO. if dpi module follows driver-model driver then
-* below codes can be removed.
*/
if (cdev-crtc_dev == cdev-conn_dev) {
- ret = component_master_add_child(m, compare_of,
- cdev-crtc_dev);
- if (ret 0)
- return ret;
-
+ component_match_add(dev, match, compare_of,
+ cdev-crtc_dev);
goto out_lock;
}
@@ -546,11 +539,8 @@ static int exynos_drm_add_components(struct device *dev,
struct master *m)
* connector/encoder need pipe number of crtc when they
* are created.
*/
- ret = component_master_add_child(m, compare_of, cdev-crtc_dev);
- ret |= component_master_add_child(m, compare_of,
- cdev-conn_dev);
- if (ret 0)
- return ret;
+ component_match_add(dev, match, compare_of, cdev-crtc_dev);
+ component_match_add(dev, match, compare_of, cdev-conn_dev);
out_lock:
mutex_lock(drm_component_lock);
@@ -558,7 +548,7 @@ out_lock:
mutex_unlock(drm_component_lock);
- return attach_cnt ? 0 : -ENODEV;
+ return attach_cnt ? match : ERR_PTR(-EPROBE_DEFER);
}
static int exynos_drm_bind(struct device *dev)
@@ -572,13 +562,13 @@ static void exynos_drm_unbind(struct device *dev)
}
static const struct component_master_ops exynos_drm_ops = {
- .add_components = exynos_drm_add_components,
.bind = exynos_drm_bind,
.unbind = exynos_drm_unbind,
};
static int exynos_drm_platform_probe(struct platform_device *pdev)
{
+ struct component_match *match;
int ret;
pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
@@ -645,13 +635,19 @@ static int exynos_drm_platform_probe(struct
platform_device *pdev)
goto err_unregister_ipp_drv;
#endif
- ret = component_master_add(pdev-dev, exynos_drm_ops);
- if (ret 0)
- DRM_DEBUG_KMS(re-tried by last sub driver probed later.\n);
+ match = exynos_drm_match_add(pdev-dev);
+ if (IS_ERR(match)) {
+ ret = PTR_ERR(match);
+ goto err_unregister_ipp_dev;
+ }
- return 0;
+ return component_master_add_with_match(pdev-dev, exynos_drm_ops,
+ match);
+
+err_unregister_ipp_dev:
#ifdef CONFIG_DRM_EXYNOS_IPP
+ exynos_platform_device_ipp_unregister();
err_unregister_ipp_drv:
platform_driver_unregister(ipp_driver);
err_unregister_gsc_drv:
--
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: [Linaro-mm-sig] [PATCH 10/29] drivers: add DRIVER_HAS_OWN_IOMMU_MANAGER flag
On Monday 01 September 2014 14:07:34 Marek Szyprowski wrote: On 2014-09-01 13:56, Arnd Bergmann wrote: On Monday 01 September 2014 12:47:08 Marek Szyprowski wrote: Who do you think needs to set this flag, and who needs to read it? In the proposed solution Exynos IOMMU driver creates a separate IO address space for every client device in a system and binds it to the default dma-mapping space for the given device. When drivers are doing its own management of IO address space, instead of relying on what is available by default with dma-mapping interface, this will require releasing of the previously created default structures and resources. So this flag is set by the driver doing its own management of io address space. The flags is then checked by Exynos IOMMU driver to avoid creating the default dma-mapping address space for devices which driver does its own management. I don't completely understand it yet. I would assume the device to be added to the default domain at device creation time (of_platform_populate), way before we know which device driver is going to be used. How can this prevent the iommu driver from doing the association with the domain? of_platform_populate() is too early to do the association, because that time the exynos iommu driver is even not yet probed. Please have a look at the Introduce automatic DMA configuration for IOMMU masters series that Will Deacon sent out the other day. The idea is that we are changing the probe order so that the iommu gets initialized early enough for all IOMMU association to be done there. The association with default dma-mapping domain is done in IOMMU_GROUP_NOTIFY_BIND_DRIVER notifier, just before binding the driver to the given device. This way iommu driver can check dev-driver-flags and skip creating default dma-mapping domain if driver announces that it wants to handle it by itself. I really want to kill off those notifiers. 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] mfd: syscon: Decouple syscon interface from syscon devices
On Monday 01 September 2014 12:25:49 Lee Jones wrote:
On Mon, 01 Sep 2014, Arnd Bergmann wrote:
On Monday 01 September 2014 08:49:18 Lee Jones wrote:
On Fri, 22 Aug 2014, Pankaj Dubey wrote:
From: Tomasz Figa t.f...@samsung.com
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated driver. However in certain use
cases it is desirable to make a device used with another driver a syscon
interface provider. For example, certain SoCs (e.g. Exynos) contain
system controller blocks which perform various functions such as power
domain control, CPU power management, low power mode control, but in
addition contain certain IP integration glue, such as various signal
masks, coprocessor power control, etc. In such case, there is a need to
have a dedicated driver for such system controller but also share
registers with other drivers. The latter is where the syscon interface
is helpful.
This patch decouples syscon object from syscon driver, so that it can be
registered from any driver in addition to the original syscon platform
driver.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
RFC patch [1] was posted by Tomasz Figa. This patch addresses some of
comments given by Arnd to RFC patch, and further decouples syscon from
device model. It also gives flexibility of registering with syscon at
early stage using device_node object.
It would be helpful if Arnd gave this revision his blessing (Ack).
I never saw a reason why we don't take this all the way as discussed
a few times: Completely remove the dependency of syscon on having
a platform driver for it, and make it possible to just call
syscon_regmap_lookup_by_phandle() without having to register
it first.
I think this sounds like a good end-state. Migrating over by
supporting both methods in this way does sound like the correct thing
to do though. Doing so is likely to dramatically reduce the effect on
current users.
Maybe I'm misreading the patch, but I don't see how it creates a
migration path. What I want to end up with is infrastructure that
lets anybody call syscon_regmap_lookup_by_pdevname or
syscon_regmap_lookup_by_compatible (if they really need to)
without needing the platform_driver for syscon. That should not
require any form of compatibility layer because to the driver
using it there is no API change.
In contrast, this patch introduces a new of_syscon_{un,}register()
interface that would get removed after the the above has
been implemented, causing extra churn for any driver that also
wants to provide a regmap-like interface.
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
[PATCH 1/3] clk: samsung: exynos3250: Register DMC clk provider
Add clock provider for clocks in DMC domain including EPLL and BPLL. The
DMC clocks are necessary for Exynos3 devfreq driver.
The DMC clock domain uses different address space (0x105C) than
standard clock domain (0x1003 - 0x1005). The difference is huge
enough to add new DT node for the clock provider, rather than extending
existing address space.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
drivers/clk/samsung/clk-exynos3250.c | 194 +
include/dt-bindings/clock/exynos3250.h | 27 +
2 files changed, 221 insertions(+)
diff --git a/drivers/clk/samsung/clk-exynos3250.c
b/drivers/clk/samsung/clk-exynos3250.c
index dc85f8e7a2d7..6cda52031b30 100644
--- a/drivers/clk/samsung/clk-exynos3250.c
+++ b/drivers/clk/samsung/clk-exynos3250.c
@@ -110,6 +110,12 @@ enum exynos3250_plls {
nr_plls
};
+/* list of PLLs in DMC block to be registered */
+enum exynos3250_dmc_plls {
+ bpll, epll,
+ nr_dmc_plls
+};
+
static void __iomem *reg_base;
/*
@@ -724,6 +730,25 @@ static struct samsung_pll_rate_table
exynos3250_pll_rates[] = {
{ /* sentinel */ }
};
+/* EPLL */
+static struct samsung_pll_rate_table exynos3250_epll_rates[] = {
+ PLL_36XX_RATE(8, 200, 3, 1, 0),
+ PLL_36XX_RATE(28800, 96, 2, 2, 0),
+ PLL_36XX_RATE(19200, 128, 2, 3, 0),
+ PLL_36XX_RATE(14400, 96, 2, 3, 0),
+ PLL_36XX_RATE( 9600, 128, 2, 4, 0),
+ PLL_36XX_RATE( 8400, 112, 2, 4, 0),
+ PLL_36XX_RATE( 8004, 106, 2, 4, 43691),
+ PLL_36XX_RATE( 73728000, 98, 2, 4, 19923),
+ PLL_36XX_RATE( 67737598, 270, 3, 5, 62285),
+ PLL_36XX_RATE( 65535999, 174, 2, 5, 49982),
+ PLL_36XX_RATE( 5000, 200, 3, 5, 0),
+ PLL_36XX_RATE( 49152002, 131, 2, 5, 4719),
+ PLL_36XX_RATE( 4800, 128, 2, 5, 0),
+ PLL_36XX_RATE( 45158401, 180, 3, 5, 41524),
+ { /* sentinel */ }
+};
+
/* VPLL */
static struct samsung_pll_rate_table exynos3250_vpll_rates[] = {
PLL_36XX_RATE(6, 100, 2, 1, 0),
@@ -821,3 +846,172 @@ static void __init exynos3250_cmu_init(struct device_node
*np)
samsung_clk_of_add_provider(np, ctx);
}
CLK_OF_DECLARE(exynos3250_cmu, samsung,exynos3250-cmu, exynos3250_cmu_init);
+
+/*
+ * CMU DMC
+ */
+
+#define BPLL_LOCK 0x0118
+#define BPLL_CON0 0x0218
+#define BPLL_CON1 0x021c
+#define BPLL_CON2 0x0220
+#define SRC_DMC0x0300
+#define DIV_DMC1 0x0504
+#define GATE_BUS_DMC0 0x0700
+#define GATE_BUS_DMC1 0x0704
+#define GATE_BUS_DMC2 0x0708
+#define GATE_BUS_DMC3 0x070c
+#define GATE_SCLK_DMC 0x0800
+#define GATE_IP_DMC0 0x0900
+#define GATE_IP_DMC1 0x0904
+#define EPLL_LOCK 0x1110
+#define EPLL_CON0 0x1114
+#define EPLL_CON1 0x1118
+#define EPLL_CON2 0x111c
+#define SRC_EPLL 0x1120
+
+/*
+ * Support for CMU save/restore across system suspends
+ */
+#ifdef CONFIG_PM_SLEEP
+static struct samsung_clk_reg_dump *exynos3250_dmc_clk_regs;
+
+static unsigned long exynos3250_cmu_dmc_clk_regs[] __initdata = {
+ BPLL_LOCK,
+ BPLL_CON0,
+ BPLL_CON1,
+ BPLL_CON2,
+ SRC_DMC,
+ DIV_DMC1,
+ GATE_BUS_DMC0,
+ GATE_BUS_DMC1,
+ GATE_BUS_DMC2,
+ GATE_BUS_DMC3,
+ GATE_SCLK_DMC,
+ GATE_IP_DMC0,
+ GATE_IP_DMC1,
+ EPLL_LOCK,
+ EPLL_CON0,
+ EPLL_CON1,
+ EPLL_CON2,
+ SRC_EPLL,
+};
+
+static int exynos3250_dmc_clk_suspend(void)
+{
+ samsung_clk_save(reg_base, exynos3250_dmc_clk_regs,
+ ARRAY_SIZE(exynos3250_cmu_dmc_clk_regs));
+ return 0;
+}
+
+static void exynos3250_dmc_clk_resume(void)
+{
+ samsung_clk_restore(reg_base, exynos3250_dmc_clk_regs,
+ ARRAY_SIZE(exynos3250_cmu_dmc_clk_regs));
+}
+
+static struct syscore_ops exynos3250_dmc_clk_syscore_ops = {
+ .suspend = exynos3250_dmc_clk_suspend,
+ .resume = exynos3250_dmc_clk_resume,
+};
+
+static void exynos3250_dmc_clk_sleep_init(void)
+{
+ exynos3250_dmc_clk_regs =
+ samsung_clk_alloc_reg_dump(exynos3250_cmu_dmc_clk_regs,
+ ARRAY_SIZE(exynos3250_cmu_dmc_clk_regs));
+ if (!exynos3250_dmc_clk_regs) {
+ pr_warn(%s: Failed to allocate sleep save data\n, __func__);
+ goto err;
+ }
+
+ register_syscore_ops(exynos3250_dmc_clk_syscore_ops);
+ return;
+err:
+ kfree(exynos3250_dmc_clk_regs);
+}
+#else
+static inline void exynos3250_dmc_clk_sleep_init(void) { }
+#endif
+
+PNAME(mout_epll_p) = { fin_pll, fout_epll, };
+PNAME(mout_bpll_p) = { fin_pll, fout_bpll, };
+PNAME(mout_mpll_mif_p) = { fin_pll, sclk_mpll_mif, };
+PNAME(mout_dphy_p)
[PATCH 2/3] ARM: dts: exynos3250: Add CMU node for DMC domain clocks
Add CMU (Clock Management Unit) node for DMC (Dynamic Memory Controller)
domain clocks on Exynos3250.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
arch/arm/boot/dts/exynos3250.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 429a6c6cfcf9..8c3a9cc0a4d1 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -163,6 +163,12 @@
#clock-cells = 1;
};
+ cmu_dmc: clock-controller@105C {
+ compatible = samsung,exynos3250-cmu-dmc;
+ reg = 0x105C 0x2000;
+ #clock-cells = 1;
+ };
+
rtc: rtc@1007 {
compatible = samsung,exynos3250-rtc;
reg = 0x1007 0x100;
--
1.9.1
--
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] MAINTAINERS: Tomasz has moved
Quoting Linus Walleij (2014-08-29 05:18:15) On Tue, Aug 26, 2014 at 4:30 PM, Tomasz Figa t.f...@samsung.com wrote: I am leaving Samsung, so my current e-mail address is not going to work any longer. Replace it with my private one. In addition, Sylwester Nawrocki is being added as co-maintainer for Samsung clock drivers to take some of the responsibilities, as I will be doing my part in my spare time. Signed-off-by: Tomasz Figa t.f...@samsung.com OK I'm taking this patch through pinctrl fixes. Not much controversy here, Mike you need not worry about it. Ack. Regards, Mike Patch applied. Yours, Linus Walleij -- 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] mfd: syscon: Decouple syscon interface from syscon devices
On Mon, 01 Sep 2014, Arnd Bergmann wrote:
On Monday 01 September 2014 12:25:49 Lee Jones wrote:
On Mon, 01 Sep 2014, Arnd Bergmann wrote:
On Monday 01 September 2014 08:49:18 Lee Jones wrote:
On Fri, 22 Aug 2014, Pankaj Dubey wrote:
From: Tomasz Figa t.f...@samsung.com
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated driver. However in certain
use
cases it is desirable to make a device used with another driver a
syscon
interface provider. For example, certain SoCs (e.g. Exynos) contain
system controller blocks which perform various functions such as power
domain control, CPU power management, low power mode control, but in
addition contain certain IP integration glue, such as various signal
masks, coprocessor power control, etc. In such case, there is a need
to
have a dedicated driver for such system controller but also share
registers with other drivers. The latter is where the syscon interface
is helpful.
This patch decouples syscon object from syscon driver, so that it can
be
registered from any driver in addition to the original syscon
platform
driver.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
RFC patch [1] was posted by Tomasz Figa. This patch addresses some of
comments given by Arnd to RFC patch, and further decouples syscon from
device model. It also gives flexibility of registering with syscon at
early stage using device_node object.
It would be helpful if Arnd gave this revision his blessing (Ack).
I never saw a reason why we don't take this all the way as discussed
a few times: Completely remove the dependency of syscon on having
a platform driver for it, and make it possible to just call
syscon_regmap_lookup_by_phandle() without having to register
it first.
I think this sounds like a good end-state. Migrating over by
supporting both methods in this way does sound like the correct thing
to do though. Doing so is likely to dramatically reduce the effect on
current users.
Maybe I'm misreading the patch, but I don't see how it creates a
migration path. What I want to end up with is infrastructure that
lets anybody call syscon_regmap_lookup_by_pdevname or
syscon_regmap_lookup_by_compatible (if they really need to)
without needing the platform_driver for syscon. That should not
require any form of compatibility layer because to the driver
using it there is no API change.
Somehow I think the likelyhood is that I am misreading the patch.
I thought that before this patch drivers we had to register a syscon
device to bind to this driver, which was fine for the first use-cases
of syscon as it wasn't required too early during boot. However, now
there are use-cases where systems require access to syscon registers
eariler in boot we require a means to obtain access prior to device
probing. I thought this patch not only provides that possibilty, but
also leaves in the ability to register direct from DT.
In contrast, this patch introduces a new of_syscon_{un,}register()
interface that would get removed after the the above has
been implemented, causing extra churn for any driver that also
wants to provide a regmap-like interface.
When will we ever not have to register syscon?
--
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] mfd: syscon: Decouple syscon interface from syscon devices
On Monday 01 September 2014 17:04:26 Lee Jones wrote:
On Mon, 01 Sep 2014, Arnd Bergmann wrote:
Maybe I'm misreading the patch, but I don't see how it creates a
migration path. What I want to end up with is infrastructure that
lets anybody call syscon_regmap_lookup_by_pdevname or
syscon_regmap_lookup_by_compatible (if they really need to)
without needing the platform_driver for syscon. That should not
require any form of compatibility layer because to the driver
using it there is no API change.
Somehow I think the likelyhood is that I am misreading the patch.
I thought that before this patch drivers we had to register a syscon
device to bind to this driver, which was fine for the first use-cases
of syscon as it wasn't required too early during boot. However, now
there are use-cases where systems require access to syscon registers
eariler in boot we require a means to obtain access prior to device
probing. I thought this patch not only provides that possibilty, but
also leaves in the ability to register direct from DT.
Right, it does provide the ability to have syscon before devices
are registered, I missed that part.
In contrast, this patch introduces a new of_syscon_{un,}register()
interface that would get removed after the the above has
been implemented, causing extra churn for any driver that also
wants to provide a regmap-like interface.
When will we ever not have to register syscon?
The idea is that we implicitly register the syscon block when someone
calls syscon_regmap_lookup_by_compatible or syscon_regmap_lookup_by_phandle
and then return a reference to that new syscon. When another driver
looks up the same device node, we just pass a reference to the existing
syscon.
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 v9 1/6] clk: samsung: add infrastructure to register cpu clocks
Quoting Thomas Abraham (2014-07-30 01:07:38)
The CPU clock provider supplies the clock to the CPU clock domain. The
composition and organization of the CPU clock provider could vary among
Exynos SoCs. A CPU clock provider can be composed of clock mux, dividers
and gates. This patch defines a new clock type for CPU clock provider and
adds infrastructure to register the CPU clock providers for Samsung
platforms.
Signed-off-by: Thomas Abraham thomas...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
Acked-by: Mike Turquette mturque...@linaro.org
---
drivers/clk/samsung/Makefile |2 +-
drivers/clk/samsung/clk-cpu.c | 335
+
drivers/clk/samsung/clk-cpu.h | 91 +++
3 files changed, 427 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/samsung/clk-cpu.c
create mode 100644 drivers/clk/samsung/clk-cpu.h
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 6fb4bc6..8909c93 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -2,7 +2,7 @@
# Samsung Clock specific Makefile
#
-obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o
+obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o clk-cpu.o
obj-$(CONFIG_SOC_EXYNOS3250) += clk-exynos3250.o
obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
diff --git a/drivers/clk/samsung/clk-cpu.c b/drivers/clk/samsung/clk-cpu.c
new file mode 100644
index 000..009a21b
--- /dev/null
+++ b/drivers/clk/samsung/clk-cpu.c
@@ -0,0 +1,335 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author: Thomas Abraham thomas...@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.
+ *
+ * This file contains the utility function to register CPU clock for Samsung
+ * Exynos platforms. A CPU clock is defined as a clock supplied to a CPU or a
+ * group of CPUs. The CPU clock is typically derived from a hierarchy of
clock
+ * blocks which includes mux and divider blocks. There are a number of other
+ * auxiliary clocks supplied to the CPU domain such as the debug blocks and
AXI
+ * clock for CPU domain. The rates of these auxiliary clocks are related to
the
+ * CPU clock rate and this relation is usually specified in the hardware
manual
+ * of the SoC or supplied after the SoC characterization.
+ *
+ * The below implementation of the CPU clock allows the rate changes of the
CPU
+ * clock and the corresponding rate changes of the auxillary clocks of the
CPU
+ * domain. The platform clock driver provides a clock register configuration
+ * for each configurable rate which is then used to program the clock
hardware
+ * registers to acheive a fast co-oridinated rate change for all the CPU
domain
+ * clocks.
+ *
+ * On a rate change request for the CPU clock, the rate change is propagated
+ * upto the PLL supplying the clock to the CPU domain clock blocks. While the
+ * CPU domain PLL is reconfigured, the CPU domain clocks are driven using an
+ * alternate clock source. If required, the alternate clock source is divided
+ * down in order to keep the output clock rate within the previous OPP
limits.
+*/
+
+#include linux/errno.h
+#include clk-cpu.h
+
+#define E4210_SRC_CPU 0x0
+#define E4210_STAT_CPU 0x200
+#define E4210_DIV_CPU0 0x300
+#define E4210_DIV_CPU1 0x304
+#define E4210_DIV_STAT_CPU00x400
+#define E4210_DIV_STAT_CPU10x404
+
+#define E4210_DIV0_RATIO0_MASK 0x7
+#define E4210_DIV1_HPM_MASK(0x7 4)
+#define E4210_DIV1_COPY_MASK (0x7 0)
+#define E4210_MUX_HPM_MASK (1 20)
+#define E4210_DIV0_ATB_SHIFT 16
+#define E4210_DIV0_ATB_MASK(DIV_MASK E4210_DIV0_ATB_SHIFT)
+
+#define MAX_DIV8
+#define DIV_MASK 7
+#define DIV_MASK_ALL 0x
+#define MUX_MASK 7
+
+/*
+ * Helper function to wait until divider(s) have stabilized after the divider
+ * value has changed.
+ */
+static void wait_until_divider_stable(void __iomem *div_reg, unsigned long
mask)
+{
+ unsigned long timeout = jiffies + msecs_to_jiffies(10);
+
+ do {
+ if (!(readl(div_reg) mask))
+ return;
+ } while (time_before(jiffies, timeout));
+
+ pr_err(%s: timeout in divider stablization\n, __func__);
+}
+
+/*
+ * Helper function to wait until mux has stabilized after the mux selection
+ * value was changed.
+ */
+static void wait_until_mux_stable(void __iomem *mux_reg, u32 mux_pos,
+ unsigned long mux_value)
+{
+ unsigned long timeout = jiffies + msecs_to_jiffies(10);
+
+ do {
+ if (((readl(mux_reg) mux_pos) MUX_MASK) ==
Re: [PATCH v9 2/6] clk: samsung: add cpu clock configuration data and instantiate cpu clock
Quoting Thomas Abraham (2014-07-30 01:07:39)
With the addition of the new Samsung specific cpu-clock type, the
arm clock can be represented as a cpu-clock type. Add the CPU clock
configuration data and instantiate the CPU clock type for Exynos4210,
Exynos5250 and Exynos5420.
Cc: Tomasz Figa t.f...@samsung.com
Signed-off-by: Thomas Abraham thomas...@samsung.com
Acked-by: Mike Turquette mturque...@linaro.org
---
drivers/clk/samsung/clk-exynos4.c | 15 +++
drivers/clk/samsung/clk-exynos5250.c | 25 ++
drivers/clk/samsung/clk-exynos5420.c | 45
include/dt-bindings/clock/exynos5250.h |1 +
include/dt-bindings/clock/exynos5420.h |2 ++
5 files changed, 88 insertions(+)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index 8617f49..101f549 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -19,6 +19,7 @@
#include linux/syscore_ops.h
#include clk.h
+#include clk-cpu.h
/* Exynos4 clock controller register offsets */
#define SRC_LEFTBUS0x4200
@@ -1355,6 +1356,16 @@ static struct samsung_pll_clock
exynos4x12_plls[nr_plls] __initdata = {
VPLL_LOCK, VPLL_CON0, NULL),
};
+static const struct exynos_cpuclk_cfg_data e4210_armclk_d[] __initconst = {
+ { 120, E4210_CPU_DIV0(7, 1, 4, 3, 7, 3), E4210_CPU_DIV1(0, 5), },
+ { 100, E4210_CPU_DIV0(7, 1, 4, 3, 7, 3), E4210_CPU_DIV1(0, 4), },
+ { 80, E4210_CPU_DIV0(7, 1, 3, 3, 7, 3), E4210_CPU_DIV1(0, 3), },
+ { 50, E4210_CPU_DIV0(7, 1, 3, 3, 7, 3), E4210_CPU_DIV1(0, 3), },
+ { 40, E4210_CPU_DIV0(7, 1, 3, 3, 7, 3), E4210_CPU_DIV1(0, 3), },
+ { 20, E4210_CPU_DIV0(0, 1, 1, 1, 3, 1), E4210_CPU_DIV1(0, 3), },
+ { 0 },
+};
+
static void __init exynos4_core_down_clock(enum exynos4_soc soc)
{
unsigned int tmp;
@@ -1458,6 +1469,10 @@ static void __init exynos4_clk_init(struct device_node
*np,
samsung_clk_register_fixed_factor(ctx,
exynos4210_fixed_factor_clks,
ARRAY_SIZE(exynos4210_fixed_factor_clks));
+ exynos_register_cpu_clock(ctx, CLK_ARM_CLK, armclk,
+ mout_core_p4210[0], mout_core_p4210[1], 0x14200,
+ e4210_armclk_d, ARRAY_SIZE(e4210_armclk_d),
+ CLK_CPU_NEEDS_DEBUG_ALT_DIV | CLK_CPU_HAS_DIV1);
} else {
samsung_clk_register_mux(ctx, exynos4x12_mux_clks,
ARRAY_SIZE(exynos4x12_mux_clks));
diff --git a/drivers/clk/samsung/clk-exynos5250.c
b/drivers/clk/samsung/clk-exynos5250.c
index 70ec3d2..e19e365 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -19,6 +19,7 @@
#include linux/syscore_ops.h
#include clk.h
+#include clk-cpu.h
#define APLL_LOCK 0x0
#define APLL_CON0 0x100
@@ -748,6 +749,26 @@ static struct samsung_pll_clock exynos5250_plls[nr_plls]
__initdata = {
VPLL_LOCK, VPLL_CON0, NULL),
};
+static const struct exynos_cpuclk_cfg_data exynos5250_armclk_d[] __initconst
= {
+ { 170, E5250_CPU_DIV0(5, 3, 7, 7, 7, 3), E5250_CPU_DIV1(2, 0), },
+ { 160, E5250_CPU_DIV0(4, 1, 7, 7, 7, 3), E5250_CPU_DIV1(2, 0), },
+ { 150, E5250_CPU_DIV0(4, 1, 7, 7, 7, 2), E5250_CPU_DIV1(2, 0), },
+ { 140, E5250_CPU_DIV0(4, 1, 6, 7, 7, 2), E5250_CPU_DIV1(2, 0), },
+ { 130, E5250_CPU_DIV0(3, 1, 6, 7, 7, 2), E5250_CPU_DIV1(2, 0), },
+ { 120, E5250_CPU_DIV0(3, 1, 5, 7, 7, 2), E5250_CPU_DIV1(2, 0), },
+ { 110, E5250_CPU_DIV0(3, 1, 5, 7, 7, 3), E5250_CPU_DIV1(2, 0), },
+ { 100, E5250_CPU_DIV0(2, 1, 4, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 90, E5250_CPU_DIV0(2, 1, 4, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 80, E5250_CPU_DIV0(2, 1, 4, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 70, E5250_CPU_DIV0(1, 1, 3, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 60, E5250_CPU_DIV0(1, 1, 3, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 50, E5250_CPU_DIV0(1, 1, 2, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 40, E5250_CPU_DIV0(1, 1, 2, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 30, E5250_CPU_DIV0(1, 1, 1, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 20, E5250_CPU_DIV0(1, 1, 1, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 0 },
+};
+
static const struct of_device_id ext_clk_match[] __initconst = {
{ .compatible = samsung,clock-xxti, .data = (void *)0, },
{ },
@@ -797,6 +818,10 @@ static void __init exynos5250_clk_init(struct
device_node *np)
ARRAY_SIZE(exynos5250_div_clks));
samsung_clk_register_gate(ctx, exynos5250_gate_clks,
Re: [PATCH v9 6/6] clk: samsung: remove unused clock aliases and update clock flags
Quoting Thomas Abraham (2014-07-30 01:07:43)
With some of the Exynos SoCs switched over to use the generic CPUfreq drivers,
the unused clock aliases can be removed. In addition to this, the individual
clock blocks which are now encapsulated with the consolidate CPU clock type
can now be marked with read-only flags.
Cc: Tomasz Figa t.f...@samsung.com
Signed-off-by: Thomas Abraham thomas...@samsung.com
Acked-by: Mike Turquette mturque...@linaro.org
---
drivers/clk/samsung/clk-exynos4.c| 48
+-
drivers/clk/samsung/clk-exynos5250.c | 19 --
drivers/clk/samsung/clk-exynos5420.c | 27 ---
3 files changed, 53 insertions(+), 41 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index 101f549..04619a1 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -578,7 +578,8 @@ static struct samsung_mux_clock exynos4210_mux_clks[]
__initdata = {
MUX(0, mout_fimd1, group1_p4210, E4210_SRC_LCD1, 0, 4),
MUX(0, mout_mipi1, group1_p4210, E4210_SRC_LCD1, 12, 4),
MUX(CLK_SCLK_MPLL, sclk_mpll, mout_mpll_p, SRC_CPU, 8, 1),
- MUX(CLK_MOUT_CORE, mout_core, mout_core_p4210, SRC_CPU, 16, 1),
+ MUX_F(CLK_MOUT_CORE, mout_core, mout_core_p4210, SRC_CPU, 16, 1, 0,
+ CLK_MUX_READ_ONLY),
MUX(0, mout_hpm, mout_core_p4210, SRC_CPU, 20, 1),
MUX(CLK_SCLK_VPLL, sclk_vpll, sclk_vpll_p4210, SRC_TOP0, 8, 1),
MUX(CLK_MOUT_FIMC0, mout_fimc0, group1_p4210, SRC_CAM, 0, 4),
@@ -714,15 +715,24 @@ static struct samsung_div_clock exynos4_div_clks[]
__initdata = {
DIV(0, div_clkout_rightbus, mout_clkout_rightbus,
CLKOUT_CMU_RIGHTBUS, 8, 6),
- DIV(0, div_core, mout_core, DIV_CPU0, 0, 3),
- DIV(0, div_corem0, div_core2, DIV_CPU0, 4, 3),
- DIV(0, div_corem1, div_core2, DIV_CPU0, 8, 3),
- DIV(0, div_periph, div_core2, DIV_CPU0, 12, 3),
- DIV(0, div_atb, mout_core, DIV_CPU0, 16, 3),
- DIV(0, div_pclk_dbg, div_atb, DIV_CPU0, 20, 3),
- DIV(CLK_ARM_CLK, div_core2, div_core, DIV_CPU0, 28, 3),
- DIV(0, div_copy, mout_hpm, DIV_CPU1, 0, 3),
- DIV(0, div_hpm, div_copy, DIV_CPU1, 4, 3),
+ DIV_F(0, div_core, mout_core, DIV_CPU0, 0, 3,
+ CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
+ DIV_F(0, div_corem0, div_core2, DIV_CPU0, 4, 3,
+ CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
+ DIV_F(0, div_corem1, div_core2, DIV_CPU0, 8, 3,
+ CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
+ DIV_F(0, div_periph, div_core2, DIV_CPU0, 12, 3,
+ CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
+ DIV_F(0, div_atb, mout_core, DIV_CPU0, 16, 3,
+ CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
+ DIV_F(0, div_pclk_dbg, div_atb, DIV_CPU0, 20, 3,
+ CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
+ DIV_F(CLK_ARM_CLK, div_core2, div_core, DIV_CPU0, 28, 3,
+ CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
+ DIV_F(0, div_copy, mout_hpm, DIV_CPU1, 0, 3,
+ CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
+ DIV_F(0, div_hpm, div_copy, DIV_CPU1, 4, 3,
+ CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
DIV(0, div_clkout_cpu, mout_clkout_cpu, CLKOUT_CMU_CPU, 8, 6),
DIV(0, div_fimc0, mout_fimc0, DIV_CAM, 0, 4),
@@ -770,7 +780,8 @@ static struct samsung_div_clock exynos4_div_clks[]
__initdata = {
DIV(0, div_spi_pre2, div_spi2, DIV_PERIL2, 8, 8),
DIV(0, div_audio1, mout_audio1, DIV_PERIL4, 0, 4),
DIV(0, div_audio2, mout_audio2, DIV_PERIL4, 16, 4),
- DIV(CLK_SCLK_APLL, sclk_apll, mout_apll, DIV_CPU0, 24, 3),
+ DIV_F(CLK_SCLK_APLL, sclk_apll, mout_apll, DIV_CPU0, 24, 3,
+ CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
DIV_F(0, div_mipi_pre0, div_mipi0, DIV_LCD0, 20, 4,
CLK_SET_RATE_PARENT, 0),
DIV_F(0, div_mmc_pre0, div_mmc0, DIV_FSYS1, 8, 8,
@@ -1187,17 +1198,10 @@ static struct samsung_gate_clock
exynos4x12_gate_clks[] __initdata = {
0),
};
-static struct samsung_clock_alias exynos4_aliases[] __initdata = {
+static struct samsung_clock_alias exynos4x12_aliases[] __initdata = {
ALIAS(CLK_MOUT_CORE, NULL, moutcore),
ALIAS(CLK_ARM_CLK, NULL, armclk),
ALIAS(CLK_SCLK_APLL, NULL, mout_apll),
-};
-
-static struct samsung_clock_alias exynos4210_aliases[] __initdata = {
- ALIAS(CLK_SCLK_MPLL, NULL, mout_mpll),
-};
-
-static struct samsung_clock_alias exynos4x12_aliases[] __initdata = {
ALIAS(CLK_MOUT_MPLL_USER_C, NULL, mout_mpll),
};
@@ -1464,8 +1468,6 @@ static void __init
