[PATCH] drm/exynos: Avoid NULL pointer dereference in resume if bind failed
If binding failed calling exynos_dp_enable in exynos_dp_resume will
result in several NULL pointer dereferences. It is much better to
simply skip suspend/resume handling if bind has failed, do so by
checking if a drm_dev exists.
Signed-off-by: Charles Keepax <ckee...@opensource.wolfsonmicro.com>
---
drivers/gpu/drm/exynos/exynos_dp_core.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index d66ade0..48baf07 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1388,6 +1388,9 @@ static int exynos_dp_suspend(struct device *dev)
{
struct exynos_dp_device *dp = dev_get_drvdata(dev);
+ if (!dp->drm_dev)
+ return 0;
+
exynos_dp_disable(>encoder);
return 0;
}
@@ -1396,6 +1399,9 @@ static int exynos_dp_resume(struct device *dev)
{
struct exynos_dp_device *dp = dev_get_drvdata(dev);
+ if (!dp->drm_dev)
+ return 0;
+
exynos_dp_enable(>encoder);
return 0;
}
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3] Watchdog: Fix parent of watchdog_devices
On Wed, Aug 19, 2015 at 08:58:24AM +0530, Pratyush Anand wrote: > /sys/class/watchdog/watchdogn/device/modalias can help to identify the > driver/module for a given watchdog node. However, many wdt devices does not > set > its parent and so, we do not see an entry for device in sysfs for such > devices. > > This patch fixes parent of watchdog_device so that > /sys/class/watchdog/watchdogn/device is populated. > > Exceptions: booke, diag288, mpc8xxx, octeon, softdog and w83627hf -- They do > not > have any parent. Not sure, how we can we identify driver for these devices. > > Signed-off-by: Pratyush Anand <pan...@redhat.com> > --- For the Wolfson parts: Acked-by: Charles Keepax <ckee...@opensource.wolfsonmicro.com> Thanks, Charles -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] i2c: s3c2410: Don't enable PM runtime on the adapter device
Commit 523c5b89640e (i2c: Remove support for legacy PM) removed the PM
ops from the bus type, which causes the pm operations on the s3c2410
adapter device to fail (-ENOSUPP in rpm_callback). The adapter device
doesn't get bound to a driver and as such can't have its own pm_runtime
callbacks. Previously this was fine as the bus callbacks would have been
used, but now this can cause devices which use PM runtime and are
attached over I2C to fail to resume.
This commit fixes this issue by just doing the PM operations directly on
the I2C device, rather than the adapter device in the driver and adding
some stub callbacks for runtime suspend and resume.
Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com
---
drivers/i2c/busses/i2c-s3c2410.c | 21 -
1 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index 958c8db..4e6a724 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -784,7 +784,7 @@ static int s3c24xx_i2c_xfer(struct i2c_adapter *adap,
int retry;
int ret;
- pm_runtime_get_sync(adap-dev);
+ pm_runtime_get_sync(i2c-dev);
ret = clk_enable(i2c-clk);
if (ret)
return ret;
@@ -795,7 +795,7 @@ static int s3c24xx_i2c_xfer(struct i2c_adapter *adap,
if (ret != -EAGAIN) {
clk_disable(i2c-clk);
- pm_runtime_put(adap-dev);
+ pm_runtime_put(i2c-dev);
return ret;
}
@@ -805,7 +805,7 @@ static int s3c24xx_i2c_xfer(struct i2c_adapter *adap,
}
clk_disable(i2c-clk);
- pm_runtime_put(adap-dev);
+ pm_runtime_put(i2c-dev);
return -EREMOTEIO;
}
@@ -1253,7 +1253,6 @@ static int s3c24xx_i2c_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, i2c);
pm_runtime_enable(pdev-dev);
- pm_runtime_enable(i2c-adap.dev);
dev_info(pdev-dev, %s: S3C I2C adapter\n, dev_name(i2c-adap.dev));
return 0;
@@ -1270,7 +1269,6 @@ static int s3c24xx_i2c_remove(struct platform_device
*pdev)
clk_unprepare(i2c-clk);
- pm_runtime_disable(i2c-adap.dev);
pm_runtime_disable(pdev-dev);
s3c24xx_i2c_deregister_cpufreq(i2c);
@@ -1318,6 +1316,16 @@ static int s3c24xx_i2c_resume_noirq(struct device *dev)
#endif
#ifdef CONFIG_PM
+static int s3c24xx_runtime_resume(struct device *dev)
+{
+ return 0;
+}
+
+static int s3c24xx_runtime_suspend(struct device *dev)
+{
+ return 0;
+}
+
static const struct dev_pm_ops s3c24xx_i2c_dev_pm_ops = {
#ifdef CONFIG_PM_SLEEP
.suspend_noirq = s3c24xx_i2c_suspend_noirq,
@@ -1327,6 +1335,9 @@ static const struct dev_pm_ops s3c24xx_i2c_dev_pm_ops = {
.poweroff_noirq = s3c24xx_i2c_suspend_noirq,
.restore_noirq = s3c24xx_i2c_resume_noirq,
#endif
+ SET_RUNTIME_PM_OPS(s3c24xx_runtime_suspend,
+ s3c24xx_runtime_resume,
+ NULL)
};
#define S3C24XX_DEV_PM_OPS (s3c24xx_i2c_dev_pm_ops)
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: s3c2410: Don't enable PM runtime on the adapter device
On Thu, Apr 16, 2015 at 12:39:43PM +0200, Lars-Peter Clausen wrote: On 04/16/2015 12:33 PM, Sylwester Nawrocki wrote: On 16/04/15 12:10, Charles Keepax wrote: Commit 523c5b89640e (i2c: Remove support for legacy PM) removed the PM ops from the bus type, which causes the pm operations on the s3c2410 adapter device to fail (-ENOSUPP in rpm_callback). The adapter device doesn't get bound to a driver and as such can't have its own pm_runtime callbacks. Previously this was fine as the bus callbacks would have been used, but now this can cause devices which use PM runtime and are attached over I2C to fail to resume. This commit fixes this issue by just doing the PM operations directly on the I2C device, rather than the adapter device in the driver and adding some stub callbacks for runtime suspend and resume. Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com --- drivers/i2c/busses/i2c-s3c2410.c | 21 - 1 files changed, 16 insertions(+), 5 deletions(-) @@ -1253,7 +1253,6 @@ static int s3c24xx_i2c_probe(struct platform_device *pdev) platform_set_drvdata(pdev, i2c); Wouldn't adding pm_runtime_no_callbacks(pdev-dev); here let us avoid the runtime resume/suspend stubs? Or just do pm_runtime_no_callbacks on the adapter device. Preferably in the I2C core. That should solve the issue without requiring any other changes. - Lars Ooops... missed that function, yeah that looks like a much better option. Thanks, Charles -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] i2c: Mark adapter devices with pm_runtime_no_callbacks
Commit 523c5b89640e (i2c: Remove support for legacy PM) removed the PM ops from the bus type, which causes the pm operations on the s3c2410 adapter device to fail (-ENOSUPP in rpm_callback). The adapter device doesn't get bound to a driver and as such can't have its own pm_runtime callbacks. Previously this was fine as the bus callbacks would have been used, but now this can cause devices which use PM runtime and are attached over I2C to fail to resume. This commit fixes this issue by marking all adapter devices with pm_runtime_no_callbacks, since they can't have any. Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com --- Changes since v1: - Simple mark all adapter devices with pm_runtime_no_callbacks in the i2c core Thanks, Charles drivers/i2c/i2c-core.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c index 1672e6b..eac3331 100644 --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -1410,6 +1410,8 @@ static int i2c_register_adapter(struct i2c_adapter *adap) dev_dbg(adap-dev, adapter [%s] registered\n, adap-name); + pm_runtime_no_callbacks(adap-dev); + #ifdef CONFIG_I2C_COMPAT res = class_compat_create_link(i2c_adapter_compat_class, adap-dev, adap-dev.parent); -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: S3C64XX: Use fixed IRQ bases to avoid conflicts on Cragganmore
There are two PMICs on Cragganmore, currently one dynamically assign
its IRQ base and the other uses a fixed base. It is possible for the
statically assigned PMIC to fail if its IRQ is taken by the dynamically
assigned one. Fix this by statically assigning both the IRQ bases.
Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com
---
arch/arm/mach-s3c64xx/crag6410.h |1 +
arch/arm/mach-s3c64xx/mach-crag6410.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/crag6410.h b/arch/arm/mach-s3c64xx/crag6410.h
index 7bc6668..dcbe17f 100644
--- a/arch/arm/mach-s3c64xx/crag6410.h
+++ b/arch/arm/mach-s3c64xx/crag6410.h
@@ -14,6 +14,7 @@
#include mach/gpio-samsung.h
#define GLENFARCLAS_PMIC_IRQ_BASE IRQ_BOARD_START
+#define BANFF_PMIC_IRQ_BASE(IRQ_BOARD_START + 64)
#define PCA935X_GPIO_BASE GPIO_BOARD_START
#define CODEC_GPIO_BASE(GPIO_BOARD_START + 8)
diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c
b/arch/arm/mach-s3c64xx/mach-crag6410.c
index 10b913b..65c426b 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
@@ -554,6 +554,7 @@ static struct wm831x_touch_pdata touch_pdata = {
static struct wm831x_pdata crag_pmic_pdata = {
.wm831x_num = 1,
+ .irq_base = BANFF_PMIC_IRQ_BASE,
.gpio_base = BANFF_PMIC_GPIO_BASE,
.soft_shutdown = true,
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/10] ARM: s3c64xx: enable sparse IRQ support
On Wed, Mar 18, 2015 at 12:02:34AM +, Mark Brown wrote: On Sun, Mar 08, 2015 at 10:42:59PM +0100, Arnd Bergmann wrote: On Friday 06 March 2015 17:43:16 Charles Keepax wrote: diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c b/arch/arm/mach-s3c64xx/mach-crag6410.c index f395a5617142..cbe353a5450e 100644 --- a/arch/arm/mach-s3c64xx/mach-crag6410.c +++ b/arch/arm/mach-s3c64xx/mach-crag6410.c @@ -855,7 +855,7 @@ static void __init crag6410_machine_init(void) MACHINE_START(WLF_CRAGG_6410, Wolfson Cragganmore 6410) /* Maintainer: Mark Brown broo...@opensource.wolfsonmicro.com */ .atag_offset= 0x100, - .nr_irqs= S3C64XX_NR_IRQS + 160, + .nr_irqs= S3C64XX_NR_IRQS, .init_irq = s3c6410_init_irq, .map_io = crag6410_map_io, .init_machine = crag6410_machine_init, The samsung-gpio driver does not allocate irq descriptors for itself though, otherwise we could make the S3C64XX_NR_IRQS number smaller. That's not the only thing, I'm still seeing an issue even with the change above. The VICs are also complaining about preallocated descriptors, but they just assume the descriptors were preallocated and carry on happily. I'd also expect this to be affecting both wm831xs but it's only affecting the WM8311 on the base board, not the primary WM8312, so this seems to be a red herring. I rather suspect that the issue is at least partly that the interrupt numbering is off - the CODEC has 24 interrupts allocated to it in crag6410.h which is nowhere near enough and the PMICs have 32 each rather than the 58 they need. This is broken for the existing code too so we should get a fix to make that right in before anything else. A trivial change to fix that doesn't seem to have helped though but I probably just miscounted or something. Ok guys very sorry about the massive delay in looking at this again, I have been a bit swamped lately. I think I see what is going on here. The fix from Arnd there definitely helped, but still doesn't quite work and those defines you are talking about there are actually for the GPIOs so they are a bit of a red herring. There are two PMICs as you mention one of which is given a fixed IRQ base and the other which allocates it own. The problem appears to be that the one which allocates its own IRQ base takes the space that is specified as the fixed base for the other PMIC. Which then fails to allocate its IRQs. So adding a bit of an offset into the PMIC with the fixed IRQ base fixes the problem. Although I am not sure if it would be better to move both PMICs onto a fixed IRQ base so there is no chance of the clashing. Any thoughts? Thanks, Charles Applying this diff, on top of Arnd's fixup, gets everything working for me: diff --git a/arch/arm/mach-s3c64xx/crag6410.h b/arch/arm/mach-s3c64xx/crag6410.h index 7bc6668..59c5f44 100644 --- a/arch/arm/mach-s3c64xx/crag6410.h +++ b/arch/arm/mach-s3c64xx/crag6410.h @@ -13,7 +13,7 @@ #include mach/gpio-samsung.h -#define GLENFARCLAS_PMIC_IRQ_BASE IRQ_BOARD_START +#define GLENFARCLAS_PMIC_IRQ_BASE IRQ_BOARD_START + 256 -- 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/10] ARM: s3c64xx: allow building without board support
On Mon, Mar 02, 2015 at 01:36:03PM +0100, Arnd Bergmann wrote: Most of the code for the s3c64xx platform is only used when booting with ATAGS based board files, but not when using device-tree. This tries to identify all the s3c64xx specific code that is unneeded when CONFIG_ATAGS is not set, so we can build a smaller DT-only kernel if configured that way. All board support is still left intact but now depends on the CONFIG_ATAGS symbol that users may intentionally disable. Signed-off-by: Arnd Bergmann a...@arndb.de --- Rest of this series doesn't seem to cause me any problems on Cragganmore. Thanks, Charles -- 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] drm/exynos: Check for NULL dereference of crtc
On Fri, Mar 06, 2015 at 10:13:42PM +0900, Inki Dae wrote: On 2015년 02월 18일 02:14, Charles Keepax wrote: The commit drm/exynos: remove exynos_plane_dpms (d9ea6256) removed the use of the enabled flag, which means that the code may attempt to call win_enable on a NULL crtc. This results in the following oops on Hmm... it's strange. plane-funcs-destroy() is called prior to crtc-funcs-destroy() so it should be exynos_crtc is not NULL. However, it seems there is any corner case we didn't catch up. Applied. Thanks, it seems the offending path in an error path, looks like Arndale is missing some required DT setting which causes exynos_drm_load to fail: [1.638109] of_graph_get_next_endpoint(): no port node found in /dp-controller@145B [1.646424] exynos-drm exynos-drm: bound 1440.fimd (ops fimd_component_ops) [1.652704] /dp-controller@145B: could not find display-timings node [1.659323] /dp-controller@145B: no timings specified [1.664709] [drm:exynos_dp_bind] *ERROR* failed: of_get_videomode() : -22 [1.671485] exynos-drm exynos-drm: failed to bind 145b.dp-controller (ops exynos_dp_ops): -22 Which ends up calling exynos_plane_destroy as part of the clean up: [1.698655] [c0015db4] (unwind_backtrace) from [c00121cc] (show_stack+0x20/0x24) [1.706385] [c00121cc] (show_stack) from [c0528230] (dump_stack+0x78/0xc4) [1.713588] [c0528230] (dump_stack) from [c02f72ec] (exynos_disable_plane+0x2c/0x60) [1.721660] [c02f72ec] (exynos_disable_plane) from [c02f733c] (exynos_plane_destroy+0x1c/0x30) [1.730605] [c02f733c] (exynos_plane_destroy) from [c02e37c4] (drm_mode_config_cleanup+0x168/0x20c) [1.739982] [c02e37c4] (drm_mode_config_cleanup) from [c02f3d18] (exynos_drm_load+0xac/0x12c) [1.748832] [c02f3d18] (exynos_drm_load) from [c02dc074] (drm_dev_register+0xb0/0x110) [1.757075] [c02dc074] (drm_dev_register) from [c02ddc88] (drm_platform_init+0x50/0xe0) [1.765405] [c02ddc88] (drm_platform_init) from [c02f3a08] (exynos_drm_bind+0x20/0x28) [1.773655] [c02f3a08] (exynos_drm_bind) from [c02fe664] (try_to_bring_up_master.part.1+0xd8/0x114) [1.783027] [c02fe664] (try_to_bring_up_master.part.1) from [c02fe754] (component_master_add_with_match+0xb4/0x134) [1.793792] [c02fe754] (component_master_add_with_match) from [c02f3e94] (exynos_drm_platform_probe+0xfc/0x124) [1.804207] [c02f3e94] (exynos_drm_platform_probe) from [c0304a44] (platform_drv_probe+0x58/0xb4) [1.813411] [c0304a44] (platform_drv_probe) from [c0302fa8] (driver_probe_device+0x11c/0x23c) [1.822261] [c0302fa8] (driver_probe_device) from [c0303164] (__driver_attach+0x9c/0xa0) [1.830679] [c0303164] (__driver_attach) from [c03014a0] (bus_for_each_dev+0x64/0x98) [1.838838] [c03014a0] (bus_for_each_dev) from [c0302a4c] (driver_attach+0x2c/0x30) [1.846824] [c0302a4c] (driver_attach) from [c030269c] (bus_add_driver+0xe8/0x1e4) [1.854722] [c030269c] (bus_add_driver) from [c0303ad8] (driver_register+0x88/0x104) [1.862794] [c0303ad8] (driver_register) from [c03048ac] (__platform_driver_register+0x58/0x6c) [1.871827] [c03048ac] (__platform_driver_register) from [c02f3f84] (exynos_drm_init+0xc8/0x124) [1.880936] [c02f3f84] (exynos_drm_init) from [c00089f4] (do_one_initcall+0x90/0x1e0) [1.889096] [c00089f4] (do_one_initcall) from [c08b2e24] (kernel_init_freeable+0x114/0x1e0) [1.897779] [c08b2e24] (kernel_init_freeable) from [c05235ac] (kernel_init+0x18/0xfc) [1.905934] [c05235ac] (kernel_init) from [c000efa0] (ret_from_fork+0x14/0x34) Hope that helps some, afraid I am not really familiar enough with the graphics stack to chase that down much more though. Thanks, Charles -- 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 05/10] ARM: s3c64xx: enable sparse IRQ support
On Mon, Mar 02, 2015 at 01:35:58PM +0100, Arnd Bergmann wrote: This is another prerequisite for enabling multiplatform support, and it is the part I am least certain about. I assume it will cause the extra boot message Cannot allocate irq_descs @ IRQ%d, assuming pre-allocated to be printed, but otherwise work ok. This definitely needs to be tested on real hardware to see if it works. Signed-off-by: Arnd Bergmann a...@arndb.de --- This one appears to cause some problems with the IRQs on Cragganmore, I need to look into it a bit more but it looks like one of the PMICs can't allocate its IRQs: [0.961455] wm831x 1-0034: WM8311 revision C [0.965066] wm831x 1-0034: Failed to allocate IRQs: -17 And the CODEC can't request its IRQ: [4.252735] arizona spi0.1: WM5102 revision C [4.269763] arizona spi0.1: Failed to request primary IRQ 263: -22 Hopefully I can look into this a little more next week. Thanks, Charles -- 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 00/10] ARM: s3c64xx multiplatform, help needed
On Mon, Mar 02, 2015 at 04:17:12PM +, Mark Brown wrote: On Mon, Mar 02, 2015 at 01:35:53PM +0100, Arnd Bergmann wrote: Does anyone still have access to the hardware? I'm particularly interested in seeing this patch set get tested on smartq and on smdk6410, which have the majority of the hardware. I and a bunch of other people still have Cragganmore, the ex-Wolfson (added Charles here) people may also be able to locate a smdk6410. may also be a Certainly we have Cragganmores here, I think I have seen an smdk6410 kicking about the office unloved somewhere. I will have a look to see if I can unearth it somewhere. Thanks, Charles -- 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] Revert drm/exynos: IOMMU support should not be selectable by user
This reverts commit 8dcc14f82f06fce997e35f4c77ced9d4ed192f31. This patch causes this error on Arndale: [1.643800] kernel BUG at drivers/iommu/exynos-iommu.c:481! [1.649355] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM [1.655170] Modules linked in: [1.658203] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.19.0-07543-g3ec3f38 #1904 [1.665683] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [1.671750] task: ee0f4000 ti: ee0f2000 task.ti: ee0f2000 [1.677138] PC is at __exynos_sysmmu_enable+0x190/0x19c [1.682341] LR is at exynos_iommu_attach_device+0x54/0xc0 I am afraid I am not very familiar with either IOMMU or DRM, so apologies if I am missing anything and fixing the underlying problem in exynos-iommu.c is beyond my knowledge. That said this appears to be related to the the fact archdata.iommu is never set to anything in drivers/iommu/exynos-iommu.c. It looks to me like the exynos-iommu driver is broken as nothing initialises the exynos_iommu_owner structure, this doesn't look to be the result of recent changes either so I assume it has been broken for some time. If I had to guess I would suggest this driver works in some out of tree implementation, but not in mainline. Simplest solution seems to be to revert this patch such that the IOMMU driver is not built in on Arndale until it is fixed. Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com --- drivers/gpu/drm/exynos/Kconfig |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig index a5e7461..3fe02ca 100644 --- a/drivers/gpu/drm/exynos/Kconfig +++ b/drivers/gpu/drm/exynos/Kconfig @@ -12,9 +12,10 @@ config DRM_EXYNOS If M is selected the module will be called exynosdrm. config DRM_EXYNOS_IOMMU - bool + bool EXYNOS DRM IOMMU Support depends on DRM_EXYNOS EXYNOS_IOMMU ARM_DMA_USE_IOMMU - default y + help + Choose this option if you want to use IOMMU feature for DRM. config DRM_EXYNOS_FIMD bool Exynos DRM FIMD -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm/exynos: Check for NULL dereference of crtc
The commit drm/exynos: remove exynos_plane_dpms (d9ea6256) removed the use of the enabled flag, which means that the code may attempt to call win_enable on a NULL crtc. This results in the following oops on Arndale: [1.673479] Unable to handle kernel NULL pointer dereference at virtual address 0368 [1.681500] pgd = c0004000 [1.684154] [0368] *pgd= [1.687713] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [1.693012] Modules linked in: [1.696045] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.19.0-07545-g57485fa #1907 [1.703524] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) () [2.014803] [c02f9cfc] (exynos_plane_destroy) from [c02e61b4] (drm_mode_config_cleanup+0x168/0x20c) [2.024178] [c02e61b4] (drm_mode_config_cleanup) from [c02f66fc] (exynos_drm_load+0xac/0x12c) This patch adds in a check to ensure exynos_crtc is not NULL before it is dereferenced. Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com --- drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c b/drivers/gpu/drm/exynos/exynos_drm_plane.c index 2dfb847..78fc0a1 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c @@ -176,7 +176,7 @@ static int exynos_disable_plane(struct drm_plane *plane) struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane); struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(plane-crtc); - if (exynos_crtc-ops-win_disable) + if (exynos_crtc exynos_crtc-ops-win_disable) exynos_crtc-ops-win_disable(exynos_crtc, exynos_plane-zpos); -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert drm/exynos: IOMMU support should not be selectable by user
On Tue, Feb 17, 2015 at 09:18:28PM +0100, Javier Martinez Canillas wrote: Hello Charles, On Tue, Feb 17, 2015 at 5:58 PM, Charles Keepax ckee...@opensource.wolfsonmicro.com wrote: This reverts commit 8dcc14f82f06fce997e35f4c77ced9d4ed192f31. This patch causes this error on Arndale: IMHO the commit you are referring is correct so it should not be reverted but I also had the same error on different boards (Exynos5250 Snow, Exynos5420 Peach Pit and Exynos5800 Peach Pi). So I posted a patch [0] today to disable Exnos IOMMU support in exynos_defconfig until these issues gets fixed. Best regards, Javier [0]: https://lkml.org/lkml/2015/2/17/163 I agree your patch is the better fix. Thanks, Charles -- 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: asix: Don't reset PHY on if_up for ASIX 88772 breaks net on arndale platform
On Thu, Nov 06, 2014 at 11:06:51AM +0200, Riku Voipio wrote: On Wed, Nov 05, 2014 at 03:02:58PM +, Charles Keepax wrote: On Wed, Nov 05, 2014 at 01:04:37PM +0100, Stam, Michel [FINT] wrote: Hello Charles, After looking around I found the reset value for the 8772 chip, which seems to be 0x1E1 (ANAR register). This equates to (according to include/uapi/linux/mii.h) ADVERTISE_ALL | ADVERTISE_CSMA. The register only seems to become 0 if the software reset fails. Odd it definitely reads back as zero on Arndale. I am guessing that the root of the problem here is that for some reason Arndale POR of the ethernet is pants and it needs a full software reset before it will work and the patch removes the full reset callback. The asix on arndale comes semi-configured from u-boot, which I guess is not the state kernel expects it to come in. At least in my case where I use tftp from u-boot to load my kernel. So probably the full reset is needed here to make the asix chip come to a truly pristine state. The commit that Michel partially reverted (by returning to use ax88772_link_reset instead of ax88772_reset), indicates that a strong reset is needed for suspend/resume as well: Ok I think I have cracked this one. I am pretty sure you are right that the USB comes to us in a strange state and needs a full reset, but that only needs to happen once when the driver is bound in. So there is some code in ax88772_bind that appears to try to reset the device but does a lot less than ax88772_reset and I think that must be the problem. Applying the following on top of the patch we have been debating I think will make everything work for all of us: --- a/drivers/net/usb/asix_devices.c +++ b/drivers/net/usb/asix_devices.c @@ -465,19 +465,7 @@ static int ax88772_bind(struct usbnet *dev, struct usb_interface *in return ret; } - ret = asix_sw_reset(dev, AX_SWRESET_IPPD | AX_SWRESET_PRL); - if (ret 0) - return ret; - - msleep(150); - - ret = asix_sw_reset(dev, AX_SWRESET_CLEAR); - if (ret 0) - return ret; - - msleep(150); - - ret = asix_sw_reset(dev, embd_phy ? AX_SWRESET_IPRL : AX_SWRESET_PRTE); + ax88772_reset(dev); If you guys could test that and let me know how you get on I will send in a proper patch if it looks good. Thanks, Charles -- 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: asix: Don't reset PHY on if_up for ASIX 88772 breaks net on arndale platform
On Thu, Nov 06, 2014 at 01:39:07PM +0100, Stam, Michel [FINT] wrote: Hello Riku and Charles, I tried this with my original patch and the suggested patch applied, this seems to work for me too. One thing that bothers me, is the suspend / resume situation; usbnet.c seems to call the bind( ) on probe( ). Suspend / resume do not seem to call bind( ) directly. As Riku pointed out, the original patch I reverted was because of suspend/resume issues. I wonder if this will still work? I seem to remember I had a few issues with Arndale suspend and resume last time I tried it anyways, so not sure I will be able to test for that. But I will have a go. But in either case I guess a fix for that is probably orthogonal to my suggested fix here, as it looks pretty clear we intended to fully reset the device in bind and were appartently not doing that. So this patch is probably a needed fix anyway. Even if there are seperate issues relating to suspend and resume. Thanks, Charles -- 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: asix: Don't reset PHY on if_up for ASIX 88772 breaks net onarndale platform
On Thu, Nov 06, 2014 at 03:01:56PM +0100, Stam, Michel [FINT] wrote: Hello Charles and Riku, I've quickly tested this on a 3.10 kernel i had around; I enabled CONFIG_PM, CONFIG_PM_RUNTIME, CONFIG_PM_AUTOSLEEP, CONFIG_SUSPEND, CONFIG_SUSPEND_FREEZER, CONFIG_FREEZER in the kernel (by default they are disabled for our setup, I enabled anything regarded to runtime powermanagement to be sure I would trigger suspend/resume). Then: cd /sys/bus/usb/devices/1-2/power echo auto control echo 1 autosuspend echo 0 autosuspend_delay_ms echo enabled wakeup # make sure there's no processes routing traffic over the eth1 interface ifconfig eth1 down sleep 4 # sleep some arbitrary long time ifconfig eth1 up check dmesg; it will reset back to 100 Mbps/full duplex. This confirms that the suspend / resume does not work well. So long as the suspend is not triggered, it does seem to work, though. I cannot say whether the original issue that triggered this is still around; the ASIX chip setup we use is soldered to the PCB and hooked up to a fixed device on-board. I also tried to ping the device on the other side of the ASIX chip after the suspend/resume cycle, I could not ping it. I cannot conclusively say that this is due to the ASIX driver, as the device on the other side does not like switching PHY speeds (it may go into a non-responsive state). It is for this reason that we run it at half duplex/ 10Mbps at all times. As said; we are not using this kind of power management, so it does not raise any issues for us. I am merely pointing out that this may need work (in the future?). Cool thanks for checking this I will make a note in the commit message that suspend/resume might need some more work. Thanks, Charles -- 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: asix: Don't reset PHY on if_up for ASIX 88772 breaks net onarndale platform
On Wed, Nov 05, 2014 at 01:04:37PM +0100, Stam, Michel [FINT] wrote:
Hello Charles,
After looking around I found the reset value for the 8772 chip, which
seems to be 0x1E1 (ANAR register).
This equates to (according to include/uapi/linux/mii.h)
ADVERTISE_ALL | ADVERTISE_CSMA.
The register only seems to become 0 if the software reset fails.
Odd it definitely reads back as zero on Arndale. I am guessing
that the root of the problem here is that for some reason Arndale
POR of the ethernet is pants and it needs a full software reset
before it will work and the patch removes the full reset
callback.
Unfortunately, this is exactly what I get when the patch is applied;
asix 1-2:1.0 eth1: Failed to send software reset: ffb5
asix 1-2:1.0 eth1: link reset failed (-75) usbnet usb-:00:1d.0-2,
ASIX AX88772 USB 2.0 Ethernet
asix 1-2:1.0 eth1: Failed to send software reset: ffb5
asix 1-2:1.0 eth1: link reset failed (-75) usbnet usb-:00:1d.0-2,
ASIX AX88772 USB 2.0 Ethernet
Ok so I am guessing you have a value in the register which is
neither the reset value or 0 and this causing problems later in
the reset/on the next reset. I do find the naming confusing in
the error message there as it says link reset failed but the
link_reset callback can't fail in the driver and I modified the
reset callback. But I guess that is just oddities of the network
stack I am not familiar with.
The other thing that feels odd is (and again apologies as I know
next to nothing about the networking stack) how come it is
unexpected that the reset callback destroys the state of the
device. Naively I would have expected that a reset callback would
reset the device back to its default state. Here we seem to be
trying to avoid that happening.
A little while after this its 'Failed to enable software MII access'.
The ethernet device fails to see any link or accept any ethtool -s
command.
My device has vid:devid 0b95:772a (ASIX Elec. Corp.).
Can you tell me what device is on the Andale platform, Charles? Same
vendor/device id?
Yeah mine also idVendor=0b95, idProduct=772a
Thanks,
Charles
Another thing that bothers me is that dev-mii.advertising seems to
contain the same value, so maybe that can be used instead of a call to
asix_mdio_read(). Can anyone comment on its purpose? Should it be a
shadow copy of the real register or something?
Riku, can you test Charles' patch as well?
Kind regards,
Michel Stam
-Original Message-
From: Charles Keepax [mailto:ckee...@opensource.wolfsonmicro.com]
Sent: Tuesday, November 04, 2014 21:09 PM
To: Stam, Michel [FINT]
Cc: Riku Voipio; da...@davemloft.net; linux-...@vger.kernel.org;
net...@vger.kernel.org; linux-ker...@vger.kernel.org;
linux-samsung-soc@vger.kernel.org
Subject: Re: asix: Don't reset PHY on if_up for ASIX 88772 breaks net
onarndale platform
On Tue, Nov 04, 2014 at 11:23:06AM +0100, Stam, Michel [FINT] wrote:
Hello Riku,
Fixing a bug (ethtool support) must not cause breakage elsewhere (in
this case on arndale). This is now a regression of functionality from
3.17.
I think it would better to revert the change now and with less hurry
introduce a ethtool fix that doesn't break arndale.
I don't fully agree here;
I would like to point out that this commit is a revert itself. Fixing
the armdale will then cause breakage in other implementations, such as
ours. Blankly reverting breaks other peoples' implementations.
The PHY reset is the thing that breaks ethtool support, so any fix
that appeases all would have to take existing PHY state into account.
I'm not an expert on the ASIX driver, nor the MII, but I think this is
the cause;
drivers/net/usb/asix_devices.c:
361 asix_mdio_write(dev-net, dev-mii.phy_id, MII_BMCR,
BMCR_RESET);
362 asix_mdio_write(dev-net, dev-mii.phy_id, MII_ADVERTISE,
363 ADVERTISE_ALL | ADVERTISE_CSMA);
364 mii_nway_restart(dev-mii);
I would think that the ADVERTISE_ALL is the cause here, as it will
reset the MII back to default, thus overriding ethtool settings.
Would an:
Int reg;
reg = asix_mdio_read(dev-net,dev-mii.phy_id,MII_ADVERTISE);
prior to the offending lines, and then;
362 asix_mdio_write(dev-net, dev-mii.phy_id, MII_ADVERTISE,
363 reg);
solve the problem for you guys?
If I revert the patch in question and add this in:
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -299,6 +299,7 @@ static int ax88772_reset(struct usbnet *dev) {
struct asix_data *data = (struct asix_data *)dev-data;
int ret, embd_phy;
+ int reg;
u16 rx_ctl;
ret = asix_write_gpio(dev,
@@ -359,8 +360,10 @@ static int ax88772_reset(struct usbnet *dev)
msleep(150);
asix_mdio_write(dev-net, dev-mii.phy_id, MII_BMCR,
BMCR_RESET);
- asix_mdio_write(dev-net, dev
Re: asix: Don't reset PHY on if_up for ASIX 88772 breaks net on arndale platform
On Tue, Nov 04, 2014 at 11:23:06AM +0100, Stam, Michel [FINT] wrote:
Hello Riku,
Fixing a bug (ethtool support) must not cause breakage elsewhere (in
this case on arndale). This is now a regression of functionality from
3.17.
I think it would better to revert the change now and with less hurry
introduce a ethtool fix that doesn't break arndale.
I don't fully agree here;
I would like to point out that this commit is a revert itself. Fixing
the armdale will then cause breakage in other implementations, such as
ours. Blankly reverting breaks other peoples' implementations.
The PHY reset is the thing that breaks ethtool support, so any fix that
appeases all would have to take existing PHY state into account.
I'm not an expert on the ASIX driver, nor the MII, but I think this is
the cause;
drivers/net/usb/asix_devices.c:
361 asix_mdio_write(dev-net, dev-mii.phy_id, MII_BMCR,
BMCR_RESET);
362 asix_mdio_write(dev-net, dev-mii.phy_id, MII_ADVERTISE,
363 ADVERTISE_ALL | ADVERTISE_CSMA);
364 mii_nway_restart(dev-mii);
I would think that the ADVERTISE_ALL is the cause here, as it will reset
the MII back to default, thus overriding ethtool settings.
Would an:
Int reg;
reg = asix_mdio_read(dev-net,dev-mii.phy_id,MII_ADVERTISE);
prior to the offending lines, and then;
362 asix_mdio_write(dev-net, dev-mii.phy_id, MII_ADVERTISE,
363 reg);
solve the problem for you guys?
If I revert the patch in question and add this in:
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -299,6 +299,7 @@ static int ax88772_reset(struct usbnet *dev)
{
struct asix_data *data = (struct asix_data *)dev-data;
int ret, embd_phy;
+ int reg;
u16 rx_ctl;
ret = asix_write_gpio(dev,
@@ -359,8 +360,10 @@ static int ax88772_reset(struct usbnet *dev)
msleep(150);
asix_mdio_write(dev-net, dev-mii.phy_id, MII_BMCR, BMCR_RESET);
- asix_mdio_write(dev-net, dev-mii.phy_id, MII_ADVERTISE,
- ADVERTISE_ALL | ADVERTISE_CSMA);
+ reg = asix_mdio_read(dev-net, dev-mii.phy_id, MII_ADVERTISE);
+ if (!reg)
+ reg = ADVERTISE_ALL | ADVERTISE_CSMA;
+ asix_mdio_write(dev-net, dev-mii.phy_id, MII_ADVERTISE, reg);
mii_nway_restart(dev-mii);
ret = asix_write_medium_mode(dev, AX88772_MEDIUM_DEFAULT);
Then things work on Arndale for me. Does that work for you?
Whether that is a sensible fix I don't know however.
Mind, maybe the read function should take into account the reset value
of the MII, and set it to ADVERTISE_ALL | ADVERTISE_CSMA. I don't have
any documention here at the moment.
Yeah I also have no documentation.
Thanks,
Charles
Is anyone able to confirm my suspicions?
Kind regards,
Michel Stam
-Original Message-
From: Riku Voipio [mailto:riku.voi...@iki.fi]
Sent: Tuesday, November 04, 2014 10:44 AM
To: Stam, Michel [FINT]
Cc: Riku Voipio; da...@davemloft.net; linux-...@vger.kernel.org;
net...@vger.kernel.org; linux-ker...@vger.kernel.org;
linux-samsung-soc@vger.kernel.org; ckee...@opensource.wolfsonmicro.com
Subject: Re: asix: Don't reset PHY on if_up for ASIX 88772 breaks net
on arndale platform
On Tue, Nov 04, 2014 at 09:19:26AM +0100, Stam, Michel [FINT] wrote:
Interesting, as the commit itself is a revert from a kernel back to
2.6 somewhere. The problem I had is related to the PHY being reset on
interface-up, can you confirm that you require this?
I can't confirm what exactly is needed on arndale. I'm neither expert in
USB or ethernet. However, I can confirm that without the PHY reset,
networking doesn't work on arndale.
I now see someone else has the same problem, adding Charles to CC.
http://www.spinics.net/lists/linux-usb/msg116656.html
Reverting this
breaks ethtool support in turn.
Fixing a bug (ethtool support) must not cause breakage elsewhere (in
this case on arndale). This is now a regression of functionality from
3.17.
I think it would better to revert the change now and with less hurry
introduce a ethtool fix that doesn't break arndale.
Kind regards,
Michel Stam
-Original Message-
From: Riku Voipio [mailto:riku.voi...@iki.fi]
Sent: Tuesday, November 04, 2014 8:23 AM
To: da...@davemloft.net; Stam, Michel [FINT]
Cc: linux-...@vger.kernel.org; net...@vger.kernel.org;
linux-ker...@vger.kernel.org; linux-samsung-soc@vger.kernel.org
Subject: asix: Don't reset PHY on if_up for ASIX 88772 breaks net on
arndale platform
Hi,
With 3.18-rc3, asix on arndale (samsung exynos 5250 based board),
fails to work. Interface is initialized but network traffic seem not
to pass through. With kernel IP config the result looks like:
[3.323275] usb 3-3.2.4: new high-speed USB device number 4 using
exynos-ehci
[3.419151] usb 3-3.2.4: New USB device found,
[PATCH] ASoC: samsung-i2s: Check secondary DAI exists before referencing
In a couple of places the driver is missing a check to ensure there is a
secondary DAI before it de-references the pointer to it, causing a null
pointer de-reference. This patch adds a check to avoid this.
Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com
---
sound/soc/samsung/i2s.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index 03eec22..9d51347 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -462,7 +462,7 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai,
if (dir == SND_SOC_CLOCK_IN)
rfs = 0;
- if ((rfs other-rfs (other-rfs != rfs)) ||
+ if ((rfs other other-rfs (other-rfs != rfs)) ||
(any_active(i2s)
(((dir == SND_SOC_CLOCK_IN)
!(mod MOD_CDCLKCON)) ||
@@ -762,7 +762,8 @@ static void i2s_shutdown(struct snd_pcm_substream
*substream,
} else {
u32 mod = readl(i2s-addr + I2SMOD);
i2s-cdclk_out = !(mod MOD_CDCLKCON);
- other-cdclk_out = i2s-cdclk_out;
+ if (other)
+ other-cdclk_out = i2s-cdclk_out;
}
/* Reset any constraint on RFS and BFS */
i2s-rfs = 0;
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] clk: s3c64xx: Hookup SPI clocks correctly
In the move to this clock driver the hookups for the SPI clocks were
dropped, which causes my system Cragganmore (s3c6410 based) to be unable
to locate any spibus clocks. This patch adds them back in.
When taking the clock from the epll clock (SCLK) the rates on the SPI
bus are incorrect, this needs further debugging but the hookup here
should be correct and the problem should be else where.
The USBCLK case has been dropped because this requires the USB PHY to be
enabled.
Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com
---
drivers/clk/samsung/clk-s3c64xx.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/samsung/clk-s3c64xx.c
b/drivers/clk/samsung/clk-s3c64xx.c
index efa16ee..8889ff1c 100644
--- a/drivers/clk/samsung/clk-s3c64xx.c
+++ b/drivers/clk/samsung/clk-s3c64xx.c
@@ -418,8 +418,10 @@ static struct samsung_clock_alias s3c64xx_clock_aliases[]
= {
ALIAS(SCLK_MMC2, s3c-sdhci.2, mmc_busclk.2),
ALIAS(SCLK_MMC1, s3c-sdhci.1, mmc_busclk.2),
ALIAS(SCLK_MMC0, s3c-sdhci.0, mmc_busclk.2),
- ALIAS(SCLK_SPI1, s3c6410-spi.1, spi-bus),
- ALIAS(SCLK_SPI0, s3c6410-spi.0, spi-bus),
+ ALIAS(PCLK_SPI1, s3c6410-spi.1, spi_busclk0),
+ ALIAS(SCLK_SPI1, s3c6410-spi.1, spi_busclk2),
+ ALIAS(PCLK_SPI0, s3c6410-spi.0, spi_busclk0),
+ ALIAS(SCLK_SPI0, s3c6410-spi.0, spi_busclk2),
ALIAS(SCLK_AUDIO1, samsung-pcm.1, audio-bus),
ALIAS(SCLK_AUDIO1, samsung-i2s.1, audio-bus),
ALIAS(SCLK_AUDIO0, samsung-pcm.0, audio-bus),
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH CRITICAL] ARM: s3c64xx: dt: Fix boot failure due to double clock initialization
On Mon, Dec 16, 2013 at 09:09:15PM +, Mark Brown wrote: On Sat, Dec 14, 2013 at 04:41:06AM -0800, Tomasz Figa wrote: - Wolfson Cragganmore 6410 - Mark Brown (copied) is using it for some testing of audio codec AFAIK, but I'm not sure if you can get that anywhere. Essentially no, though you could try asking nicely. It's not suitable for a test farm anyway without a SD mux as the only bootloader supported is Qi which only boots from flash. Yeah, we don't have that many spare at the moment and whilst we do use them fairly regularly we are not produce new boards anymore. Thanks, Charles -- 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] clk: s3c64xx: Correct spi bus clock hookups
+ samsung soc mailing list On Wed, Oct 16, 2013 at 12:52:42AM +0200, Tomasz Figa wrote: Hi Charles, On Tuesday 15 of October 2013 13:26:22 Charles Keepax wrote: ALIAS(SCLK_MMC1, s3c-sdhci.1, mmc_busclk.2), ALIAS(SCLK_MMC0, s3c-sdhci.0, mmc_busclk.2), - ALIAS(SCLK_SPI1, s3c6410-spi.1, spi-bus), - ALIAS(SCLK_SPI0, s3c6410-spi.0, spi-bus), + ALIAS(PCLK_SPI1, s3c6410-spi.1, spi_busclk0), + ALIAS(SCLK_SPI1, s3c6410-spi.1, spi_busclk1), + ALIAS(SCLK_SPI1_48, s3c6410-spi.1, spi_busclk2), ...according to the documentation, the order is different. The SPI_CLKSEL field of CLK_CFG register of the SPI block can have following values: 0 - PCLK (aka PCLK_SPIx) 1 - USBCLK (aka SCLK_SPIx_48) 2 - Epll clock (aka SCLK_SPIx) The index after spi_busclk corresponds to the value written to SPI_CLKSEL field, so your patch should be adjusted accordingly. Hmm... will probably need to test this to see what happens the old clock setup was this: CLKDEV_INIT(NULL, spi_busclk0, clk_p), CLKDEV_INIT(s3c6410-spi.0, spi_busclk1, clk_sclk_spi0.clk), CLKDEV_INIT(s3c6410-spi.0, spi_busclk2, clk_48m_spi0), CLKDEV_INIT(s3c6410-spi.1, spi_busclk1, clk_sclk_spi1.clk), CLKDEV_INIT(s3c6410-spi.1, spi_busclk2, clk_48m_spi1), Which appears to differ from the documentation, that said though I would wager that only the first of those has really had much testing. By the way, the USBCLK case is a bit strange, because it requires USB signal mask to be unmasked, which in turn needs USB PHY to be enabled, as otherwise some unwanted leakage can occur. Having to enable USB just to use SPI seems rather inconvenient (especially in terms of power consumption), so the usability of this clock is rather limited and it might be better not to let the driver know about it. Seems reasonable to drop this for now and it could be added back in if someone specifically needed to use it. Thanks, Charles -- 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] clk: s3c64xx: Correct spi bus clock hookups
On Wed, Oct 16, 2013 at 11:10:59AM +0200, Tomasz Figa wrote: If you have hardware to test this, especially with possibility of checking the SPI frequency I would really appreciate this, as I unfortunately don't have such. I might not be able to get around to it this week, but I certainly should be able to test this on the hardware I have and measure the SPI speed. Thanks, Charles -- 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] ASoC: SAMSUNG: Allow mono in i2s driver
Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com --- I can't see any reason to not allow mono playback in the i2s driver and indeed it seems to work well on our test system here. However, I am fairly unfamilar with the code in this part of the tree so apologies if I am missing some constraint. Thanks, Charles sound/soc/samsung/i2s.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c index 959c702..70d08d7 100644 --- a/sound/soc/samsung/i2s.c +++ b/sound/soc/samsung/i2s.c @@ -991,7 +991,7 @@ static struct i2s_dai *i2s_alloc_dai(struct platform_device *pdev, bool sec) i2s-i2s_dai_drv.ops = samsung_i2s_dai_ops; i2s-i2s_dai_drv.suspend = i2s_suspend; i2s-i2s_dai_drv.resume = i2s_resume; - i2s-i2s_dai_drv.playback.channels_min = 2; + i2s-i2s_dai_drv.playback.channels_min = 1; i2s-i2s_dai_drv.playback.channels_max = 2; i2s-i2s_dai_drv.playback.rates = SAMSUNG_I2S_RATES; i2s-i2s_dai_drv.playback.formats = SAMSUNG_I2S_FMTS; -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ASoC: bells: Hookup DMICs for Bells
Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com
---
sound/soc/samsung/bells.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/sound/soc/samsung/bells.c b/sound/soc/samsung/bells.c
index ceed466..29e2468 100644
--- a/sound/soc/samsung/bells.c
+++ b/sound/soc/samsung/bells.c
@@ -350,8 +350,16 @@ static struct snd_soc_codec_conf bells_codec_conf[] = {
},
};
+static struct snd_soc_dapm_widget bells_widgets[] = {
+ SND_SOC_DAPM_MIC(DMIC, NULL),
+};
+
static struct snd_soc_dapm_route bells_routes[] = {
{ Sub CLK_SYS, NULL, OPCLK },
+
+ { DMIC, NULL, MICBIAS2 },
+ { IN2L, NULL, DMIC },
+ { IN2R, NULL, DMIC },
};
static struct snd_soc_card bells_cards[] = {
@@ -365,6 +373,8 @@ static struct snd_soc_card bells_cards[] = {
.late_probe = bells_late_probe,
+ .dapm_widgets = bells_widgets,
+ .num_dapm_widgets = ARRAY_SIZE(bells_widgets),
.dapm_routes = bells_routes,
.num_dapm_routes = ARRAY_SIZE(bells_routes),
@@ -383,6 +393,8 @@ static struct snd_soc_card bells_cards[] = {
.late_probe = bells_late_probe,
+ .dapm_widgets = bells_widgets,
+ .num_dapm_widgets = ARRAY_SIZE(bells_widgets),
.dapm_routes = bells_routes,
.num_dapm_routes = ARRAY_SIZE(bells_routes),
@@ -401,6 +413,8 @@ static struct snd_soc_card bells_cards[] = {
.late_probe = bells_late_probe,
+ .dapm_widgets = bells_widgets,
+ .num_dapm_widgets = ARRAY_SIZE(bells_widgets),
.dapm_routes = bells_routes,
.num_dapm_routes = ARRAY_SIZE(bells_routes),
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
