Re: [RFC 02/15] drivers/base: add restrack framework
On 12/12/2014 05:52 PM, Mark Brown wrote:
On Wed, Dec 10, 2014 at 04:48:20PM +0100, Andrzej Hajda wrote:
restrack framework allows tracking presence of resources with dynamic life
time. Typical example of such resources are all resources provided by device
I don't know about anyone else but I'm having a hard time reading the
restrack name, it looks like a misspelling of restack to me.
Any alternative names?
At a high level my biggest questions here are the relationship between
this and the component code and usability. The usability concern I have
is that I see no diagnostics or trace here at all. This means that if a
user looks at their system, sees that the device model claims the driver
for a device bound to the device but can't see any sign of the device
doing anything they don't have any way of telling why that is other than
to look in the driver code, see what resources it was trying to depend
on and then go back to the running system to try to understand which of
those resources hasn't appeared.
I will move the code for provider matching to frameworks,
so it will be easy to add just dev_info after every failed attempt
of getting resource, including deferring. This is the simplest solution
and it should be similar in verbosity to deferred probing.
Maybe other solution is to provide debug_fs (or device) attribute showing
restrack status per device.
+int restrack_up(unsigned long type, const void *id, void *data)
+int restrack_down(unsigned long type, const void *id, void *data)
Again I'm not sure that the up and down naming is meaningful in the
context of this interface.
+static void restrack_itb_cb(struct track_block *itb, void *data, bool on)
+{
itb_cb?
Ups I forgot to rename few variables from my previous attempt.
itb - stayed for interface tracker block.
Regards
Andrzej
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 18/19] iommu: exynos: init from dt-specific callback instead of initcall
On Sun, Dec 14, 2014 at 02:45:36PM +0200, Laurent Pinchart wrote:
Hi Marek,
Thank you for the patch.
On Wednesday 19 November 2014 12:15:47 Marek Szyprowski wrote:
This patch introduces IOMMU_OF_DECLARE-based initialization to the
driver, which replaces subsys_initcall-based procedure.
exynos_iommu_of_setup ensures that each sysmmu controller is probed
before its master device.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/iommu/exynos-iommu.c | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index cd28dc09db39..88f9afe641a0 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
[snip]
@@ -1125,4 +1134,21 @@ err_reg_driver:
kmem_cache_destroy(lv2table_kmem_cache);
return ret;
}
-subsys_initcall(exynos_iommu_init);
+
+static int __init exynos_iommu_of_setup(struct device_node *np)
+{
+ struct platform_device *pdev;
+
+ if (!init_done)
+ exynos_iommu_init();
+
+ pdev = of_platform_device_create(np, NULL, platform_bus_type.dev_root);
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
If we end up having to create the IOMMU platform devices from within the
drivers, the introduction of IOMMU_OF_DECLARE starts to feel like a
workaround
to me. I wonder whether it wouldn't then be better to let the driver core
instantiate the IOMMU platform device from DT as for all other devices, and
use device notifiers to defer probe of the bus masters until the required
IOMMU(s) are registered.
Notifiers don't work very well for this. Notifier blocks are supposed to
return a very limited number of values, so sneaking in a -EPROBE_DEFER
isn't likely to work out very well.
This was in fact one of Hiroshi's proposals over a year ago and got
refused because of those reasons. The next solution was to introduce a
function, not very much unlike the of_iommu_configure() that would be
called in the core prior to calling into the driver's -probe() callback
so that it could handle this at probe time (as opposed to device
creation time). That way the core can easily defer probe if the IOMMU is
not there yet. At the same time it can simply use the driver model
without requiring per-architecture hacks or workarounds.
Note that there is really no need for any of this configuration or
initialization to happen at device creation time. Drivers won't be able
to use the IOMMU or DMA APIs until their .probe(), so handling this any
earlier is completely unnecessary.
Thierry
pgpi5R9GeakFb.pgp
Description: PGP signature
Re: [RFC PATCHv2 1/7] devfreq: event: Add new devfreq_event class to provide basic data for devfreq governor
On pią, 2014-12-12 at 12:42 +0900, Chanwoo Choi wrote: Hi Krzysztof, I replied again this mail because I'll use the mutex for set_event()/get_event() according to your comment. But, of_parse_phandle() seems that this function don't need the of_node_put() function. On 12/11/2014 11:13 AM, Chanwoo Choi wrote: Hi Krzysztof, First of all, thanks for your review. On 12/10/2014 06:37 PM, Krzysztof Kozlowski wrote: On wto, 2014-12-09 at 23:13 +0900, Chanwoo Choi wrote: This patch add new devfreq_event class for devfreq_event device which provide raw data (e.g., memory bus utilization/GPU utilization). This raw data from devfreq_event data would be used for the governor of devfreq subsystem. - devfreq_event device : Provide raw data for governor of existing devfreq device - devfreq device : Monitor device state and change frequency/voltage of device using the raw data from devfreq_event device The devfreq subsystem support generic DVFS(Dynamic Voltage/Frequency Scaling) for Non-CPU Devices. The devfreq device would dertermine current device state using various governor (e.g., ondemand, performance, powersave). After completed determination of system state, devfreq device would change the frequency/voltage of devfreq device according to the result of governor. But, devfreq governor must need basic data which indicates current device state. Existing devfreq subsystem only consider devfreq device which check current system state and determine proper system state using basic data. There is no subsystem for device providing basic data to devfreq device. The devfreq subsystem must need devfreq_event device(data-provider device) for existing devfreq device. So, this patch add new devfreq_event class for devfreq_event device which read various basic data(e.g, memory bus utilization, GPU utilization) and provide measured data to existing devfreq device through standard APIs of devfreq_event class. The following description explains the feature of two kind of devfreq class: - devfreq class (existing) : devfreq consumer device use raw data from devfreq_event device for determining proper current system state and change voltage/frequency dynamically using various governors. - devfreq_event class (new) : Provide measured raw data to devfreq device for governor Cc: MyungJoo Ham myungjoo@samsung.com Cc: Kyungmin Park kyungmin.p...@samsung.com Signed-off-by: Chanwoo Choi cw00.c...@samsung.com --- drivers/devfreq/Kconfig | 2 + drivers/devfreq/Makefile| 5 +- drivers/devfreq/devfreq-event.c | 302 drivers/devfreq/event/Makefile | 1 + include/linux/devfreq.h | 141 +++ 5 files changed, 450 insertions(+), 1 deletion(-) create mode 100644 drivers/devfreq/devfreq-event.c create mode 100644 drivers/devfreq/event/Makefile diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig index faf4e70..4d15b62 100644 --- a/drivers/devfreq/Kconfig +++ b/drivers/devfreq/Kconfig @@ -87,4 +87,6 @@ config ARM_EXYNOS5_BUS_DEVFREQ It reads PPMU counters of memory controllers and adjusts the operating frequencies and voltages with OPP support. +comment DEVFREQ Event Drivers + endif # PM_DEVFREQ diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile index 16138c9..a1ffabe 100644 --- a/drivers/devfreq/Makefile +++ b/drivers/devfreq/Makefile @@ -1,4 +1,4 @@ -obj-$(CONFIG_PM_DEVFREQ) += devfreq.o +obj-$(CONFIG_PM_DEVFREQ) += devfreq.o devfreq-event.o obj-$(CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND)+= governor_simpleondemand.o obj-$(CONFIG_DEVFREQ_GOV_PERFORMANCE)+= governor_performance.o obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE) += governor_powersave.o @@ -7,3 +7,6 @@ obj-$(CONFIG_DEVFREQ_GOV_USERSPACE) += governor_userspace.o # DEVFREQ Drivers obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ)+= exynos/ obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ)+= exynos/ + +# DEVFREQ Event Drivers +obj-$(CONFIG_PM_DEVFREQ) += event/ diff --git a/drivers/devfreq/devfreq-event.c b/drivers/devfreq/devfreq-event.c new file mode 100644 index 000..b47329f --- /dev/null +++ b/drivers/devfreq/devfreq-event.c @@ -0,0 +1,302 @@ +/* + * devfreq-event: Generic DEVFREQ Event class driver + * + * Copyright (C) 2014 Samsung Electronics + * Chanwoo Choi cw00.c...@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 driver is based on drivers/devfreq/devfreq.c + */ + +#include linux/kernel.h +#include linux/sched.h +#include linux/errno.h +#include linux/err.h
[PATCH 0/2] Input: atmel_mxt_ts - Add support for T100 multi-touch
Hello Dmitry, There are different multi-touch protocols used by Atmel maXTouch touchscreen chips. Old chips use the T9 multi-touch object type while newer chips use the T100 multi-touch object type. The Atmel touch driver currently only supports the former so this series add support for the later. The series is composed of the following patches: Nick Dyer (1): Input: atmel_mxt_ts - Implement support for T100 touch object Sjoerd Simons (1): Input: atmel_mxt_ts - Split out touchpad initialisation logic drivers/input/touchscreen/atmel_mxt_ts.c | 307 +++ 1 file changed, 270 insertions(+), 37 deletions(-) Patch #1 adds the support for the T100 touch object and patch #2 is a cleanup to simplify the driver's input device initialization function. The series were tested on an Exynos 5420 Peach Pit (T9) and an Exynos 5800 Peach Pi (T100) using evtest. Best regards, Javier -- 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/2] Input: atmel_mxt_ts - Implement support for T100 touch object
From: Nick Dyer nick.d...@itdev.co.uk
The T100 object replaces the old T9 multitouch touchscreen object in new
chips. This patch was cherry-picked from the Atmel touch downstream tree
The original patch had different initialization functions for the T9 and
T100 multi-touch input devices but there was a lot of code duplicated so
the code was refactored to make the T9 dev init function more generic to
support different multi-touch object types.
T9 and T100 initialization logic is kept as it was in the original patch
since there is no public documentation about the different object types.
Signed-off-by: Nick Dyer nick.d...@itdev.co.uk
Acked-by: Yufeng Shen mile...@chromium.org
[javier: Factor out T9 and T100 routines to have a common init function]
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/input/touchscreen/atmel_mxt_ts.c | 258 +--
1 file changed, 241 insertions(+), 17 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index bb07020..aaa9e07 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -79,6 +79,7 @@
#define MXT_SPT_DIGITIZER_T43 43
#define MXT_SPT_MESSAGECOUNT_T44 44
#define MXT_SPT_CTECONFIG_T46 46
+#define MXT_TOUCH_MULTITOUCHSCREEN_T100 100
/* MXT_GEN_MESSAGE_T5 object */
#define MXT_RPTID_NOMSG0xff
@@ -138,6 +139,9 @@ struct t9_range {
/* MXT_TOUCH_MULTI_T9 orient */
#define MXT_T9_ORIENT_SWITCH (1 0)
+/* T47 Stylus */
+#define MXT_TOUCH_MAJOR_T47_STYLUS 1
+
/* MXT_PROCI_GRIPFACE_T20 field */
#define MXT_GRIPFACE_CTRL 0
#define MXT_GRIPFACE_XLOGRIP 1
@@ -188,6 +192,23 @@ struct t9_range {
#define MXT_RESET_VALUE0x01
#define MXT_BACKUP_VALUE 0x55
+/* T100 Multiple Touch Touchscreen */
+#define MXT_T100_CTRL 0
+#define MXT_T100_CFG1 1
+#define MXT_T100_TCHAUX3
+#define MXT_T100_XRANGE13
+#define MXT_T100_YRANGE24
+
+#define MXT_T100_CFG_SWITCHXY (1 5)
+
+#define MXT_T100_TCHAUX_VECT (1 0)
+#define MXT_T100_TCHAUX_AMPL (1 1)
+#define MXT_T100_TCHAUX_AREA (1 2)
+
+#define MXT_T100_DETECT(1 7)
+#define MXT_T100_TYPE_MASK 0x70
+#define MXT_T100_TYPE_STYLUS 0x20
+
/* Delay times */
#define MXT_BACKUP_TIME50 /* msec */
#define MXT_RESET_TIME 200 /* msec */
@@ -247,6 +268,9 @@ struct mxt_data {
unsigned int max_y;
bool in_bootloader;
u16 mem_size;
+ u8 t100_aux_ampl;
+ u8 t100_aux_area;
+ u8 t100_aux_vect;
u8 max_reportid;
u32 config_crc;
u32 info_crc;
@@ -268,6 +292,8 @@ struct mxt_data {
u8 T9_reportid_max;
u8 T19_reportid;
u16 T44_address;
+ u8 T100_reportid_min;
+ u8 T100_reportid_max;
/* for fw update in bootloader */
struct completion bl_completion;
@@ -761,6 +787,72 @@ static void mxt_proc_t9_message(struct mxt_data *data, u8
*message)
data-update_input = true;
}
+static void mxt_proc_t100_message(struct mxt_data *data, u8 *message)
+{
+ struct device *dev = data-client-dev;
+ struct input_dev *input_dev = data-input_dev;
+ int id;
+ u8 status;
+ int x;
+ int y;
+ int tool;
+
+ id = message[0] - data-T100_reportid_min - 2;
+
+ /* ignore SCRSTATUS events */
+ if (id 0)
+ return;
+
+ status = message[1];
+ x = (message[3] 8) | message[2];
+ y = (message[5] 8) | message[4];
+
+ dev_dbg(dev,
+ [%u] status:%02X x:%u y:%u area:%02X amp:%02X vec:%02X\n,
+ id,
+ status,
+ x, y,
+ data-t100_aux_area ? message[data-t100_aux_area] : 0,
+ data-t100_aux_ampl ? message[data-t100_aux_ampl] : 0,
+ data-t100_aux_vect ? message[data-t100_aux_vect] : 0);
+
+ input_mt_slot(input_dev, id);
+
+ if (status MXT_T100_DETECT) {
+ if ((status MXT_T100_TYPE_MASK) == MXT_T100_TYPE_STYLUS)
+ tool = MT_TOOL_PEN;
+ else
+ tool = MT_TOOL_FINGER;
+
+ /* Touch active */
+ input_mt_report_slot_state(input_dev, tool, 1);
+ input_report_abs(input_dev, ABS_MT_POSITION_X, x);
+ input_report_abs(input_dev, ABS_MT_POSITION_Y, y);
+
+ if (data-t100_aux_ampl)
+ input_report_abs(input_dev, ABS_MT_PRESSURE,
+message[data-t100_aux_ampl]);
+
+ if (data-t100_aux_area) {
+ if (tool == MT_TOOL_PEN)
+ input_report_abs(input_dev, ABS_MT_TOUCH_MAJOR,
+MXT_TOUCH_MAJOR_T47_STYLUS);
+
[PATCH 2/2] Input: atmel_mxt_ts - Split out touchpad initialisation logic
From: Sjoerd Simons sjoerd.sim...@collabora.co.uk
If the linux,gpio-keymap DT property is defined, the T19 keys are configured
and the device is setup as a touchpad rather than a touchscreen. The logic is
part of the input device initialization routine but it can be factored out to
its own function to simplify the former.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
[javier: Adapt to latest driver changes and modify commit message accordingly]
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/input/touchscreen/atmel_mxt_ts.c | 48 +++-
1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index aaa9e07..01fda60 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -1756,15 +1756,40 @@ static int mxt_read_t100_config(struct mxt_data *data)
static int mxt_input_open(struct input_dev *dev);
static void mxt_input_close(struct input_dev *dev);
+static bool mxt_initialize_t19(struct input_dev *input_dev,
+ struct mxt_data *data)
+{
+ const struct mxt_platform_data *pdata = data-pdata;
+ int i;
+
+ if (pdata-t19_num_keys) {
+ __set_bit(INPUT_PROP_BUTTONPAD, input_dev-propbit);
+
+ for (i = 0; i pdata-t19_num_keys; i++)
+ if (pdata-t19_keymap[i] != KEY_RESERVED)
+ input_set_capability(input_dev, EV_KEY,
+pdata-t19_keymap[i]);
+
+ input_abs_set_res(input_dev, ABS_X, MXT_PIXELS_PER_MM);
+ input_abs_set_res(input_dev, ABS_Y, MXT_PIXELS_PER_MM);
+ input_abs_set_res(input_dev, ABS_MT_POSITION_X,
+ MXT_PIXELS_PER_MM);
+ input_abs_set_res(input_dev, ABS_MT_POSITION_Y,
+ MXT_PIXELS_PER_MM);
+
+ input_dev-name = Atmel maXTouch Touchpad;
+ return true;
+ }
+ return false;
+}
+
static int mxt_initialize_input_device(struct mxt_data *data, int multitouch)
{
struct device *dev = data-client-dev;
- const struct mxt_platform_data *pdata = data-pdata;
struct input_dev *input_dev;
int error;
unsigned int num_mt_slots;
unsigned int mt_flags = 0;
- int i;
switch (multitouch) {
case MXT_TOUCH_MULTI_T9:
@@ -1800,26 +1825,9 @@ static int mxt_initialize_input_device(struct mxt_data
*data, int multitouch)
set_bit(EV_ABS, input_dev-evbit);
input_set_capability(input_dev, EV_KEY, BTN_TOUCH);
- if (pdata-t19_num_keys) {
- __set_bit(INPUT_PROP_BUTTONPAD, input_dev-propbit);
-
- for (i = 0; i pdata-t19_num_keys; i++)
- if (pdata-t19_keymap[i] != KEY_RESERVED)
- input_set_capability(input_dev, EV_KEY,
-pdata-t19_keymap[i]);
-
+ if (mxt_initialize_t19(input_dev, data))
mt_flags |= INPUT_MT_POINTER;
- input_abs_set_res(input_dev, ABS_X, MXT_PIXELS_PER_MM);
- input_abs_set_res(input_dev, ABS_Y, MXT_PIXELS_PER_MM);
- input_abs_set_res(input_dev, ABS_MT_POSITION_X,
- MXT_PIXELS_PER_MM);
- input_abs_set_res(input_dev, ABS_MT_POSITION_Y,
- MXT_PIXELS_PER_MM);
-
- input_dev-name = Atmel maXTouch Touchpad;
- }
-
/* For single touch */
input_set_abs_params(input_dev, ABS_X,
0, data-max_x, 0, 0);
--
2.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 02/15] drivers/base: add restrack framework
On Mon, Dec 15, 2014 at 09:28:41AM +0100, Andrzej Hajda wrote: On 12/12/2014 05:52 PM, Mark Brown wrote: On Wed, Dec 10, 2014 at 04:48:20PM +0100, Andrzej Hajda wrote: I don't know about anyone else but I'm having a hard time reading the restrack name, it looks like a misspelling of restack to me. Any alternative names? Well, even just res_track would help. I will move the code for provider matching to frameworks, so it will be easy to add just dev_info after every failed attempt of getting resource, including deferring. This is the simplest solution and it should be similar in verbosity to deferred probing. Maybe other solution is to provide debug_fs (or device) attribute showing restrack status per device. I think both are useful - it's often helpful to have a listing of what resources have actually been registered, for example to help spot typos. signature.asc Description: Digital signature
Re: [RFC 01/15] drivers/base: add track framework
On Sat, Dec 13, 2014 at 12:12:19AM +0100, AH wrote: Mark Brown wrote on 12.12.2014 17:36: On Wed, Dec 10, 2014 at 04:48:19PM +0100, Andrzej Hajda wrote: + kfree(ptask); + + if (empty) + break; + + track_process_task(track, task); ...we then go and do some other stuff, including processing that task, without the lock or or any other means I can see of excluding other users before going round and removing the task. This seems to leave us vulnerable to double execution. No, if you look at track_add_task function you will see that the queue is processed only if it is initially empty, otherwise the task is only added to the queue, so it will be processed after processing earlier tasks. So the rule is that if someone add task to the queue it checks if the queue is empty, in such case it process all tasks from the queue until the queue becomes empty, even the tasks added by other processed. This way all tasks are serialized. This is all pretty fiddly and seems fragile - if nothing else the code seems undercommented since the above is only going to be apparent with following through multiple functions and we're relying on both owner and list emptiness with more than one place where a task can get processed. I'm also unclear what is supposed to happen if adding a notification races with removing the thing being watched. The sequence should be always as follows: 1. create thing, then call track_up(thing). ... 2. call track_down(thing) then remove thing. If we put 1 into probe and 2 into remove callback of the driver it will be safe - we are synchronised by device_lock. But if, for some reason, we want to create object after probe we should do own synchronization or just put device_lock around 1. The same applies if we want to remove object earlier. This is the comment above about. I will expand it to more verbose explanation. You can't rely on the device lock here since this isn't tied to kobjects or anything at all - it's a freestanding interface someone could pick up and use in another context. Besides, that isn't really my concern - my concern is what happens if something asks to wait for signature.asc Description: Digital signature
Re: [PATCH] iommu/exynos: Fix arm64 allmodconfig build
On 15.12.2014 14:00, Mark Brown wrote: The Exynos IOMMU driver uses the ARM specific dmac_flush_range() and outer_flush_range() functions. This breaks the build on arm64 allmodconfig in -next since support has been merged for some Exynos ARMv8 SoCs. Add a dependency on ARM to keep things building until either the driver has the ARM dependencies removed or the ARMv8 architecture code implements these ARM specific APIs. Hi Mark, Few days ago I posted similar patch: https://lkml.org/lkml/2014/12/5/268 but no one have picked it up. Anyway the fix of yours seems fine to me. Best regards, Krzysztof Signed-off-by: Mark Brown broo...@kernel.org --- drivers/iommu/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index 01e8bfae569b..325188eef1c1 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -187,7 +187,7 @@ config TEGRA_IOMMU_SMMU config EXYNOS_IOMMU bool Exynos IOMMU Support - depends on ARCH_EXYNOS + depends on ARCH_EXYNOS ARM select IOMMU_API select ARM_DMA_USE_IOMMU help -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 01/15] drivers/base: add track framework
On 12/15/2014 01:55 PM, Mark Brown wrote: On Sat, Dec 13, 2014 at 12:12:19AM +0100, AH wrote: Mark Brown wrote on 12.12.2014 17:36: On Wed, Dec 10, 2014 at 04:48:19PM +0100, Andrzej Hajda wrote: + kfree(ptask); + + if (empty) + break; + + track_process_task(track, task); ...we then go and do some other stuff, including processing that task, without the lock or or any other means I can see of excluding other users before going round and removing the task. This seems to leave us vulnerable to double execution. No, if you look at track_add_task function you will see that the queue is processed only if it is initially empty, otherwise the task is only added to the queue, so it will be processed after processing earlier tasks. So the rule is that if someone add task to the queue it checks if the queue is empty, in such case it process all tasks from the queue until the queue becomes empty, even the tasks added by other processed. This way all tasks are serialized. This is all pretty fiddly and seems fragile - if nothing else the code seems undercommented since the above is only going to be apparent with following through multiple functions and we're relying on both owner and list emptiness with more than one place where a task can get processed. I have changed it already to test queue owner, this way it should be more clear. I'm also unclear what is supposed to happen if adding a notification races with removing the thing being watched. The sequence should be always as follows: 1. create thing, then call track_up(thing). ... 2. call track_down(thing) then remove thing. If we put 1 into probe and 2 into remove callback of the driver it will be safe - we are synchronised by device_lock. But if, for some reason, we want to create object after probe we should do own synchronization or just put device_lock around 1. The same applies if we want to remove object earlier. This is the comment above about. I will expand it to more verbose explanation. You can't rely on the device lock here since this isn't tied to kobjects or anything at all - it's a freestanding interface someone could pick up and use in another context. Besides, that isn't really my concern - my concern is what happens if something asks to wait for But I do not rely here on device_lock, I just point out that 1 and 2 should be synchronized and as a common way is to put such things into probe and remove, device_lock can do the synchronization for us in such case, so no need for additional synchronization. And to make everything clear, track_up will not be called by the driver directly, it shall be called by respective resource framework functions, for example by regulator_register and regulator_unregister. And regarding your initial/real concern, I guess you mean this one: I'm also unclear what is supposed to happen if adding a notification races with removing the thing being watched. I guess you mean registering notifier and removal of thing it is supposed to watch. As all track tasks are serialized these two will be serialized also so we can have only two scenarios: 1. a) register notifier - thing is up, so notifier will be immediately called with info that the thing is up b) remove thing - thing will be down, so notifier will be called with info that the thing will be removed 2. a) remove thing - notifier is not yet registered, so callback will not be called, b) register notifier - thing is already removed, so callback will not be called. I hope this is what you were asking for. Regards Andrzej -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support
On 12/12/14 11:51, Javier Martinez Canillas wrote: Tomi and Laurent, You asked Ajay to change his series to use the video port and enpoints DT bindings instead of phandles, could you please review his latest version? Looking only at the binding documentation patch, looks good to me. Tomi signature.asc Description: OpenPGP digital signature
Re: [RFC PATCHv3 1/7] devfreq: event: Add new devfreq_event class to provide basic data for devfreq governor
On pią, 2014-12-12 at 17:27 +0900, Chanwoo Choi wrote:
This patch add new devfreq_event class for devfreq_event device which provide
raw data (e.g., memory bus utilization/GPU utilization). This raw data from
devfreq_event data would be used for the governor of devfreq subsystem.
- devfreq_event device : Provide raw data for governor of existing devfreq
device
- devfreq device : Monitor device state and change frequency/voltage of
device
using the raw data from devfreq_event device
The devfreq subsystem support generic DVFS(Dynamic Voltage/Frequency Scaling)
for Non-CPU Devices. The devfreq device would dertermine current device state
using various governor (e.g., ondemand, performance, powersave). After
completed
determination of system state, devfreq device would change the
frequency/voltage
of devfreq device according to the result of governor.
But, devfreq governor must need basic data which indicates current device
state.
Existing devfreq subsystem only consider devfreq device which check current
system
state and determine proper system state using basic data. There is no
subsystem
for device providing basic data to devfreq device.
The devfreq subsystem must need devfreq_event device(data-provider device) for
existing devfreq device. So, this patch add new devfreq_event class for
devfreq_event device which read various basic data(e.g, memory bus
utilization,
GPU utilization) and provide measured data to existing devfreq device through
standard APIs of devfreq_event class.
The following description explains the feature of two kind of devfreq class:
- devfreq class (existing)
: devfreq consumer device use raw data from devfreq_event device for
determining proper current system state and change voltage/frequency
dynamically using various governors.
- devfreq_event class (new)
: Provide measured raw data to devfreq device for governor
Cc: MyungJoo Ham myungjoo@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
[...]
+/**
+ * devfreq_event_get_event() - Get event and total_event from devfreq-event
dev.
+ * @edev : the devfreq-event device
+ *
+ * Note that this function get the calculated event data from devfreq-event
dev
+ * after stoping the progress of whole sequence of devfreq-event dev. Return
+ * current event data and total_event should be stored in second parameter
+ * (total_event).
+ */
+u64 devfreq_event_get_event(struct devfreq_event_dev *edev, u64 *total_event)
+{
I think this function should return int (0 for success, negative
otherwise) and store the event under pointer passed as argument.
Why? Because:
1. error conditions are indicated with 'return 0' but should be 'return
-EINVAL'
2. Exynos-ppmu driver returns -EINVAL.
Checking for error conditions is in such case more complex than it
should.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCHv3 2/7] devfreq: event: Add the list of supported devfreq-event type
On pią, 2014-12-12 at 17:27 +0900, Chanwoo Choi wrote:
This patch adds the list of supported devfreq-event type as following.
Each devfreq-event device driver would support the various devfreq-event type
for devfreq governor at the same time.
- DEVFREQ_EVENT_TYPE_RAW_DATA
- DEVFREQ_EVENT_TYPE_UTILIZATION
- DEVFREQ_EVENT_TYPE_BANDWIDTH
- DEVFREQ_EVENT_TYPE_LATENCY
Cc: MyungJoo Ham myungjoo@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
drivers/devfreq/devfreq-event.c | 44
+
include/linux/devfreq.h | 29 ++-
2 files changed, 64 insertions(+), 9 deletions(-)
diff --git a/drivers/devfreq/devfreq-event.c b/drivers/devfreq/devfreq-event.c
index eaf59c1..9444f93 100644
--- a/drivers/devfreq/devfreq-event.c
+++ b/drivers/devfreq/devfreq-event.c
@@ -29,6 +29,9 @@
#include linux/of.h
#include governor.h
+#define EVENT_TYPE_RAW_DATA_MAX U64_MAX
+#define EVENT_TYPE_UTILIZATION_MAX 100
+
static struct class *devfreq_event_class;
/* The list of all devfreq event list */
@@ -144,7 +147,8 @@ EXPORT_SYMBOL_GPL(devfreq_event_is_enabled);
* Note that this function set the event to the devfreq-event device to start
* for getting the event data which could be various event type.
*/
-int devfreq_event_set_event(struct devfreq_event_dev *edev)
+int devfreq_event_set_event(struct devfreq_event_dev *edev,
+ enum devfreq_event_type type)
{
int ret;
@@ -158,7 +162,15 @@ int devfreq_event_set_event(struct devfreq_event_dev
*edev)
return -EPERM;
mutex_lock(edev-lock);
- ret = edev-desc-ops-set_event(edev);
+
+ if ((edev-desc-type type) == 0) {
+ dev_err(edev-dev, unsupported of devfreq-event type\n);
+ mutex_unlock(edev-lock);
+ return -EINVAL;
+ }
+
+ ret = edev-desc-ops-set_event(edev, type);
+
mutex_unlock(edev-lock);
return ret;
@@ -174,7 +186,9 @@ EXPORT_SYMBOL_GPL(devfreq_event_set_event);
* current event data and total_event should be stored in second parameter
* (total_event).
*/
-u64 devfreq_event_get_event(struct devfreq_event_dev *edev, u64 *total_event)
+u64 devfreq_event_get_event(struct devfreq_event_dev *edev,
+ enum devfreq_event_type type,
+ u64 *total_event)
{
u64 event;
@@ -190,7 +204,27 @@ u64 devfreq_event_get_event(struct devfreq_event_dev
*edev, u64 *total_event)
return 0;
mutex_lock(edev-lock);
- event = edev-desc-ops-get_event(edev, total_event);
+
+ if ((edev-desc-type type) == 0) {
+ dev_err(edev-dev, unsupported of devfreq-event type\n);
+ return -EINVAL;
+ }
+
+ event = edev-desc-ops-get_event(edev, type, total_event);
+
+ switch (type) {
+ case DEVFREQ_EVENT_TYPE_RAW_DATA:
+ case DEVFREQ_EVENT_TYPE_BANDWIDTH:
+ case DEVFREQ_EVENT_TYPE_LATENCY:
+ if ((event *total_event)
+ || ((event EVENT_TYPE_RAW_DATA_MAX) ||
+ *total_event EVENT_TYPE_RAW_DATA_MAX))
+ event = 0;
missing break here.
Best regards,
Krzysztof
+ case DEVFREQ_EVENT_TYPE_UTILIZATION:
+ if (event EVENT_TYPE_UTILIZATION_MAX)
+ event = 0;
+ }
+
mutex_unlock(edev-lock);
return event;
@@ -215,8 +249,10 @@ int devfreq_event_reset_event(struct devfreq_event_dev
*edev)
return -EPERM;
mutex_lock(edev-lock);
+
if (edev-desc-ops edev-desc-ops-reset)
ret = edev-desc-ops-reset(edev);
+
mutex_unlock(edev-lock);
if (ret 0)
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index a8d2277..82da235 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -197,6 +197,14 @@ struct devfreq_event_dev {
const struct devfreq_event_desc *desc;
};
+/* The supported type by devfreq-event device */
+enum devfreq_event_type {
+ DEVFREQ_EVENT_TYPE_RAW_DATA = BIT(0),
+ DEVFREQ_EVENT_TYPE_UTILIZATION = BIT(1),
+ DEVFREQ_EVENT_TYPE_BANDWIDTH= BIT(2),
+ DEVFREQ_EVENT_TYPE_LATENCY = BIT(3),
+};
+
/**
* struct devfreq_event_ops - the operations of devfreq-event device
*
@@ -219,8 +227,10 @@ struct devfreq_event_ops {
int (*reset)(struct devfreq_event_dev *event_dev);
/* Mandatory functions */
- int (*set_event)(struct devfreq_event_dev *event_dev);
- u64 (*get_event)(struct devfreq_event_dev *event_dev, u64 *total_event);
+ int (*set_event)(struct devfreq_event_dev *event_dev,
+ enum devfreq_event_type type);
+ u64 (*get_event)(struct devfreq_event_dev *event_dev,
+
[PATCH v2 3/3] ARM: dts: Add devfreq to Exynos3250 and Rinato board
Add devfreq to Exynos3250 common file and enable it for Rinato board.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
arch/arm/boot/dts/exynos3250-rinato.dts | 12
arch/arm/boot/dts/exynos3250.dtsi | 26 ++
2 files changed, 38 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 7970b8e91ab2..6def01c61742 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -567,6 +567,18 @@
clock-frequency = 2400;
};
+busfreq_mif {
+ vdd-mif-supply = buck1_reg;
+ devfreq-events = ppmu_dmc0_3, ppmu_dmc1_3;
+ status = okay;
+};
+
+busfreq_int {
+ vdd-int-supply = buck3_reg;
+ devfreq-events = ppmu_leftbus_3, ppmu_rightbus_3;
+ status = okay;
+};
+
pinctrl_0 {
pinctrl-names = default;
pinctrl-0 = sleep0;
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 51e3e7111e59..cc0e30768ec2 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -175,6 +175,32 @@
#clock-cells = 1;
};
+ busfreq_mif: busfreq@106A {
+ compatible = samsung,exynos3250-busfreq-mif;
+ clocks = cmu_dmc CLK_DIV_DMC;
+ clock-names = dmc;
+ status = disabled;
+ };
+
+ busfreq_int: busfreq@116A {
+ compatible = samsung,exynos3250-busfreq-int;
+ clocks = cmu CLK_DIV_ACLK_400_MCUISP,
+ cmu CLK_DIV_ACLK_266,
+ cmu CLK_DIV_ACLK_200,
+ cmu CLK_DIV_ACLK_160,
+ cmu CLK_DIV_GDL,
+ cmu CLK_DIV_GDR,
+ cmu CLK_DIV_MFC;
+ clock-names = aclk_400,
+ aclk_266,
+ aclk_200,
+ aclk_160,
+ aclk_gdl,
+ aclk_gdr,
+ mfc;
+ status = disabled;
+ };
+
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
[PATCH v2 0/3] devfreq: exynos: Add driver for Exynos3250
Hi, Changes since v1 1. Patch 1/3, bindings: fixes after review from Mark Rutland. 2. Patch 2/3, driver: update perf benchmarks. 3. Rebase on Chanwoo's devfreq-event class patches v3 [1]. Description === The aim of patchset is to gather feedback about adding new devfreq driver for Exynos 3250, along with the bindings. The patchset uses devfreq-event class posted recently [1]. Chanwoo, You were the author of our initial exynos3_bus.c driver so do you want me to add your Signed-off-by? [1] [RFC PATCHv3 0/7] devfreq: Add devfreq-event class to provide raw data for devfreq device https://lkml.org/lkml/2014/12/12/219 Best regards, Krzysztof Krzysztof Kozlowski (3): devfreq: dt-bindings: Document bindings for Exynos3250 bus DVFS driver devfreq: exynos: Add driver for Exynos3250 ARM: dts: Add devfreq to Exynos3250 and Rinato board .../bindings/arm/samsung/exynos3250-devfreq.txt| 62 ++ arch/arm/boot/dts/exynos3250-rinato.dts| 12 + arch/arm/boot/dts/exynos3250.dtsi | 26 + drivers/devfreq/Kconfig| 12 + drivers/devfreq/Makefile | 1 + drivers/devfreq/exynos/Makefile| 1 + drivers/devfreq/exynos/exynos3_bus.c | 847 + 7 files changed, 961 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/samsung/exynos3250-devfreq.txt create mode 100644 drivers/devfreq/exynos/exynos3_bus.c -- 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
[PATCH v2 2/3] devfreq: exynos: Add driver for Exynos3250
Add new devfreq driver for Exynos3250. The driver utilizes devfreq event class for bus utilization data is multiplatform safe. Currently it does not support ASV (Adaptive Supply Voltage). Driver creates two devices: - Dynamic Memory Controller (DMC) and memory bus, - peripheral (left/right) buses. For memory it changes the DMC clock from 50 MHz to 400 MHz and MIF voltage regulator from 800 mV to 875 mV. As for peripheral it changes the frequencies of multiple bus clocks and INT voltage regulator from 850 mV to 950 mV. Impact on performance (Rinato/Gear 2 board) calculated with: $ perf bench mem memcpy -l 256MB -i 10 $ perf bench mem memset -l 256MB -i 10 $ dd if=/dev/mmcblk0p15 of=/opt/file iflag=direct oflag=direct count=128 bs=1M type | no devfreq [MB/s] | devfreq [MB/s] | diff = memcpy | 152.016 | 151.590| -0.3% memcpy prefault | 166.636 | 166.598| 0.0% memset | 126.832 | 112.814| -11.0% memset prefault | 168.349 | 168.287| -0.0% MMC transfer| 19.0 | 18.5 | -2.6% Impact on energy consumption, system in idle (WFI), mA: no devfreq [mA] | devfreq [mA] | diff 29.0| 19.2 | -33.8% Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com --- drivers/devfreq/Kconfig | 12 + drivers/devfreq/Makefile | 1 + drivers/devfreq/exynos/Makefile | 1 + drivers/devfreq/exynos/exynos3_bus.c | 847 +++ 4 files changed, 861 insertions(+) create mode 100644 drivers/devfreq/exynos/exynos3_bus.c diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig index d4559f7866d6..ed4718bad8c9 100644 --- a/drivers/devfreq/Kconfig +++ b/drivers/devfreq/Kconfig @@ -65,6 +65,18 @@ config DEVFREQ_GOV_USERSPACE comment DEVFREQ Drivers +config ARM_EXYNOS3_BUS_DEVFREQ + bool ARM Exynos3250 Memory and peripheral bus DEVFREQ Driver + depends on SOC_EXYNOS3250 + select DEVFREQ_GOV_SIMPLE_ONDEMAND + select PM_OPP + help + This adds the DEVFREQ driver for Exynos3250 memory interface + and peripheral bus (vdd_mif + vdd_int). + It reads PPMU counters of memory controllers and adjusts + the operating frequencies and voltages with OPP support. + This does not yet operate with optimal voltages. + config ARM_EXYNOS4_BUS_DEVFREQ bool ARM Exynos4210/4212/4412 Memory Bus DEVFREQ Driver depends on (CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412) !ARCH_MULTIPLATFORM diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile index a1ffabe90a14..780f1c4724ea 100644 --- a/drivers/devfreq/Makefile +++ b/drivers/devfreq/Makefile @@ -5,6 +5,7 @@ obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE) += governor_powersave.o obj-$(CONFIG_DEVFREQ_GOV_USERSPACE)+= governor_userspace.o # DEVFREQ Drivers +obj-$(CONFIG_ARM_EXYNOS3_BUS_DEVFREQ) += exynos/ obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ) += exynos/ obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ) += exynos/ diff --git a/drivers/devfreq/exynos/Makefile b/drivers/devfreq/exynos/Makefile index 49bc9175f923..a4aa1ed474c9 100644 --- a/drivers/devfreq/exynos/Makefile +++ b/drivers/devfreq/exynos/Makefile @@ -1,3 +1,4 @@ # Exynos DEVFREQ Drivers +obj-$(CONFIG_ARM_EXYNOS3_BUS_DEVFREQ) += exynos_ppmu.o exynos3_bus.o obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ) += exynos_ppmu.o exynos4_bus.o obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ) += exynos_ppmu.o exynos5_bus.o diff --git a/drivers/devfreq/exynos/exynos3_bus.c b/drivers/devfreq/exynos/exynos3_bus.c new file mode 100644 index ..e01c3d90d2b8 --- /dev/null +++ b/drivers/devfreq/exynos/exynos3_bus.c @@ -0,0 +1,847 @@ +/* + * drivers/devfreq/exynos/exynos3_bus.c + * + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * + * based on drivers/devfreqw/exynos/exynos4_bus.c + * Copyright (c) 2011 Samsung Electronics Co., Ltd. + * + * EXYNOS3250 - Memory/Bus clock frequency scaling support in DEVFREQ framework + * This version supports EXYNOS3250 only. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + */ + +#include linux/clk.h +#include linux/devfreq.h +#include linux/io.h +#include linux/module.h +#include linux/mutex.h +#include linux/pm_opp.h +#include linux/of_address.h +#include linux/platform_device.h +#include linux/regulator/consumer.h +#include linux/suspend.h + + +/*#include exynos_ppmu.h*/ + +/* + * Assume that the bus is saturated if the utilization is 30%. + * + * Saturation ratio is less than that in exynos4_bus.c (40%) to boost + * ondemand governor early. + * Memory tests (memcpy, memory alloc, dmatest) shown that ratio of 40% + * triggers frequency increase sporadically. + */
[PATCH v2 1/3] devfreq: dt-bindings: Document bindings for Exynos3250 bus DVFS driver
Add documentation for bindings used by Exynos3250 Dynamic Voltage
and Frequency Scaling (DVFS) driver.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
.../bindings/arm/samsung/exynos3250-devfreq.txt| 62 ++
1 file changed, 62 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/samsung/exynos3250-devfreq.txt
diff --git
a/Documentation/devicetree/bindings/arm/samsung/exynos3250-devfreq.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos3250-devfreq.txt
new file mode 100644
index ..162498ec0da8
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos3250-devfreq.txt
@@ -0,0 +1,62 @@
+Samsung Exynos3250 bus frequency scaling driver
+===
+
+The Exynos3250 SoC allows Dynamic Voltage and Frequency Scaling (DVFS)
+for certain system buses:
+ - memory controller and bus,
+ - peripheral buses (leftbus, rightbus).
+
+DVFS for memory controller and bus
+==
+Required properties:
+ - compatible : should be samsung,exynos3250-busfreq-mif
+ - clock-names : one clock of name dmc to manage frequency
+ - clocks : phandle and specifier for clock listed in clock-names property
+ - vdd-mif-supply : phandle to MIF voltage regulator
+ - devfreq-events : two phandles to devfreq event devices providing
+ raw data for bus utilization
+
+DVFS for peripheral buses
+=
+Required properties:
+ - compatible : should be samsung,exynos3250-busfreq-int
+ - clock-names : names for bus clocks to manage frequencies;
+ All following clock names (and corresponding phandles) must be
+ provided: aclk_400, aclk_266, aclk_200, aclk_160, aclk_gdl,
+ aclk_gdr, mfc;
+ - clocks : phandles and specifiers for clocks listed in clock-names property
+ - vdd-int-supply : phandle to INT voltage regulator
+ - devfreq-events : two phandles to devfreq event devices providing
+ raw data for bus utilization
+
+Example
+===
+ busfreq_mif: busfreq@106A {
+ compatible = samsung,exynos3250-busfreq-mif;
+ clocks = cmu_dmc CLK_DIV_DMC;
+ clock-names = dmc;
+ vdd-mif-supply = buck1_reg;
+ devfreq-events = ppmu_dmc0_3, ppmu_dmc1_3;
+ status = okay;
+ };
+
+ busfreq_int: busfreq@116A {
+ compatible = samsung,exynos3250-busfreq-int;
+ clocks = cmu CLK_DIV_ACLK_400_MCUISP,
+ cmu CLK_DIV_ACLK_266,
+ cmu CLK_DIV_ACLK_200,
+ cmu CLK_DIV_ACLK_160,
+ cmu CLK_DIV_GDL,
+ cmu CLK_DIV_GDR,
+ cmu CLK_DIV_MFC;
+ clock-names = aclk_400,
+ aclk_266,
+ aclk_200,
+ aclk_160,
+ aclk_gdl,
+ aclk_gdr,
+ mfc;
+ vdd-int-supply = buck3_reg;
+ devfreq-events = ppmu_leftbus_3, ppmu_rightbus_3;
+ status = okay;
+ };
--
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] iommu/exynos: Fix arm64 allmodconfig build
On Mon, Dec 15, 2014 at 02:10:37PM +0100, Krzysztof Kozłowski wrote: Hi Mark, Few days ago I posted similar patch: https://lkml.org/lkml/2014/12/5/268 but no one have picked it up. Anyway the fix of yours seems fine to me. I don't mind either way, it just seemed to be easier to report the bug with a patch. If Jeorg is busy perhaps it can go via the arm64 tree, the issue is triggered by the addition of the platform there? signature.asc Description: Digital signature
Re: [PATCH] iommu/exynos: Fix arm64 allmodconfig build
On Mon, Dec 15, 2014 at 03:35:29PM +, Mark Brown wrote: On Mon, Dec 15, 2014 at 02:10:37PM +0100, Krzysztof Kozłowski wrote: Few days ago I posted similar patch: https://lkml.org/lkml/2014/12/5/268 but no one have picked it up. Anyway the fix of yours seems fine to me. I don't mind either way, it just seemed to be easier to report the bug with a patch. If Jeorg is busy perhaps it can go via the arm64 tree, the issue is triggered by the addition of the platform there? Can I pass the buck to arm-soc, as they're handling arm64 platform code? It seems sensible to merge the fix via the same tree that introduced the breakage. Will -- 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] iommu/exynos: Fix arm64 allmodconfig build
The Exynos IOMMU driver uses the ARM specific dmac_flush_range() and outer_flush_range() functions. This breaks the build on arm64 allmodconfig in -next since support has been merged for some Exynos ARMv8 SoCs. Add a dependency on ARM to keep things building until either the driver has the ARM dependencies removed or the ARMv8 architecture code implements these ARM specific APIs. Signed-off-by: Mark Brown broo...@kernel.org --- Resending to the arm-soc people since the addition of the Exynos platform for ARMv8 went via them, Krzysztof also sent a fix for this earlier but it there's been no response. drivers/iommu/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index 01e8bfae569b..325188eef1c1 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -187,7 +187,7 @@ config TEGRA_IOMMU_SMMU config EXYNOS_IOMMU bool Exynos IOMMU Support - depends on ARCH_EXYNOS + depends on ARCH_EXYNOS ARM select IOMMU_API select ARM_DMA_USE_IOMMU help -- 2.1.3 -- 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] iommu/exynos: Fix arm64 allmodconfig build
On Mon, Dec 15, 2014 at 03:38:04PM +, Will Deacon wrote: On Mon, Dec 15, 2014 at 03:35:29PM +, Mark Brown wrote: I don't mind either way, it just seemed to be easier to report the bug with a patch. If Jeorg is busy perhaps it can go via the arm64 tree, the issue is triggered by the addition of the platform there? Can I pass the buck to arm-soc, as they're handling arm64 platform code? It seems sensible to merge the fix via the same tree that introduced the breakage. Sure, just resending to them... signature.asc Description: Digital signature
Re: [PATCH v3 18/19] iommu: exynos: init from dt-specific callback instead of initcall
On Sun, Dec 14, 2014 at 12:45:36PM +, Laurent Pinchart wrote:
On Wednesday 19 November 2014 12:15:47 Marek Szyprowski wrote:
This patch introduces IOMMU_OF_DECLARE-based initialization to the
driver, which replaces subsys_initcall-based procedure.
exynos_iommu_of_setup ensures that each sysmmu controller is probed
before its master device.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/iommu/exynos-iommu.c | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index cd28dc09db39..88f9afe641a0 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
[snip]
@@ -1125,4 +1134,21 @@ err_reg_driver:
kmem_cache_destroy(lv2table_kmem_cache);
return ret;
}
-subsys_initcall(exynos_iommu_init);
+
+static int __init exynos_iommu_of_setup(struct device_node *np)
+{
+ struct platform_device *pdev;
+
+ if (!init_done)
+ exynos_iommu_init();
+
+ pdev = of_platform_device_create(np, NULL, platform_bus_type.dev_root);
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
If we end up having to create the IOMMU platform devices from within the
drivers, the introduction of IOMMU_OF_DECLARE starts to feel like a
workaround
to me. I wonder whether it wouldn't then be better to let the driver core
instantiate the IOMMU platform device from DT as for all other devices, and
use device notifiers to defer probe of the bus masters until the required
IOMMU(s) are registered.
Will, what's your opinion on that ?
Creating the platform device manually for the IOMMU is indeed grotty, but I
don't really understand why it's needed. Interrupt controllers, for example,
seem to get by without one.
Will
--
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 18/19] iommu: exynos: init from dt-specific callback instead of initcall
Hi Will,
On Monday 15 December 2014 17:17:00 Will Deacon wrote:
On Sun, Dec 14, 2014 at 12:45:36PM +, Laurent Pinchart wrote:
On Wednesday 19 November 2014 12:15:47 Marek Szyprowski wrote:
This patch introduces IOMMU_OF_DECLARE-based initialization to the
driver, which replaces subsys_initcall-based procedure.
exynos_iommu_of_setup ensures that each sysmmu controller is probed
before its master device.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/iommu/exynos-iommu.c | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index cd28dc09db39..88f9afe641a0 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
[snip]
@@ -1125,4 +1134,21 @@ err_reg_driver:
kmem_cache_destroy(lv2table_kmem_cache);
return ret;
}
-subsys_initcall(exynos_iommu_init);
+
+static int __init exynos_iommu_of_setup(struct device_node *np)
+{
+ struct platform_device *pdev;
+
+ if (!init_done)
+ exynos_iommu_init();
+
+ pdev = of_platform_device_create(np, NULL,
platform_bus_type.dev_root);
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
If we end up having to create the IOMMU platform devices from within the
drivers, the introduction of IOMMU_OF_DECLARE starts to feel like a
workaround to me. I wonder whether it wouldn't then be better to let the
driver core instantiate the IOMMU platform device from DT as for all
other devices, and use device notifiers to defer probe of the bus masters
until the required IOMMU(s) are registered.
Will, what's your opinion on that ?
Creating the platform device manually for the IOMMU is indeed grotty, but I
don't really understand why it's needed. Interrupt controllers, for example,
seem to get by without one.
There's several reasons, one of the most compelling ones I can think of at the
moment is runtime PM. IRQ controllers close to the CPU use CPU PM notifiers
instead. Note that IRQ controllers that are further away from the CPU (such as
GPIO-based IRQ controllers) are real platform devices and use runtime PM.
IOMMUs are not as low-level as system interrupt controllers or system clocks.
I'm beginning to agree with Thierry that they should be treated as normal
platform devices as they're not required earlier than probe time of their bus
master devices.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 18/19] iommu: exynos: init from dt-specific callback instead of initcall
On Mon, Dec 15, 2014 at 05:27:30PM +, Laurent Pinchart wrote:
On Monday 15 December 2014 17:17:00 Will Deacon wrote:
On Sun, Dec 14, 2014 at 12:45:36PM +, Laurent Pinchart wrote:
On Wednesday 19 November 2014 12:15:47 Marek Szyprowski wrote:
+static int __init exynos_iommu_of_setup(struct device_node *np)
+{
+ struct platform_device *pdev;
+
+ if (!init_done)
+ exynos_iommu_init();
+
+ pdev = of_platform_device_create(np, NULL,
platform_bus_type.dev_root);
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
If we end up having to create the IOMMU platform devices from within the
drivers, the introduction of IOMMU_OF_DECLARE starts to feel like a
workaround to me. I wonder whether it wouldn't then be better to let the
driver core instantiate the IOMMU platform device from DT as for all
other devices, and use device notifiers to defer probe of the bus masters
until the required IOMMU(s) are registered.
Will, what's your opinion on that ?
Creating the platform device manually for the IOMMU is indeed grotty, but I
don't really understand why it's needed. Interrupt controllers, for example,
seem to get by without one.
There's several reasons, one of the most compelling ones I can think of at
the
moment is runtime PM. IRQ controllers close to the CPU use CPU PM notifiers
instead. Note that IRQ controllers that are further away from the CPU (such
as
GPIO-based IRQ controllers) are real platform devices and use runtime PM.
Ok, that's a good point, but the IOMMU will still probe later anyway, right?
IOMMUs are not as low-level as system interrupt controllers or system clocks.
I'm beginning to agree with Thierry that they should be treated as normal
platform devices as they're not required earlier than probe time of their bus
master devices.
Well, I think you'd have to propose patches for discussion since I'm
certainly not wed to the current approach; I just want something that
allows of_{dma,iommu}_configure to run with the information it needs.
The usual answer is `we should model buses properly', but that's really
not practical afaict.
Will
--
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 18/19] iommu: exynos: init from dt-specific callback instead of initcall
Hi Will,
On Monday 15 December 2014 17:43:02 Will Deacon wrote:
On Mon, Dec 15, 2014 at 05:27:30PM +, Laurent Pinchart wrote:
On Monday 15 December 2014 17:17:00 Will Deacon wrote:
On Sun, Dec 14, 2014 at 12:45:36PM +, Laurent Pinchart wrote:
On Wednesday 19 November 2014 12:15:47 Marek Szyprowski wrote:
+static int __init exynos_iommu_of_setup(struct device_node *np)
+{
+ struct platform_device *pdev;
+
+ if (!init_done)
+ exynos_iommu_init();
+
+ pdev = of_platform_device_create(np, NULL,
platform_bus_type.dev_root);
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
If we end up having to create the IOMMU platform devices from within
the drivers, the introduction of IOMMU_OF_DECLARE starts to feel like
a workaround to me. I wonder whether it wouldn't then be better to let
the driver core instantiate the IOMMU platform device from DT as for
all other devices, and use device notifiers to defer probe of the bus
masters until the required IOMMU(s) are registered.
Will, what's your opinion on that ?
Creating the platform device manually for the IOMMU is indeed grotty,
but I don't really understand why it's needed. Interrupt controllers,
for example, seem to get by without one.
There's several reasons, one of the most compelling ones I can think of at
the moment is runtime PM. IRQ controllers close to the CPU use CPU PM
notifiers instead. Note that IRQ controllers that are further away from
the CPU (such as GPIO-based IRQ controllers) are real platform devices
and use runtime PM.
Ok, that's a good point, but the IOMMU will still probe later anyway, right?
That depends on the driver implementation, using OF node match an IOMMU driver
doesn't have to register a struct driver. Assuming we require IOMMU drivers to
register a struct driver, a platform device should then be probed at a later
time.
However, if we wait until the IOMMU gets probed to initialize runtime PM and
make it functional, we'll be back in square one if the IOMMU gets probed after
the bus master, as the bus master could start issuing bus requests at probe
time with the IOMMU not powered yet.
IOMMUs are not as low-level as system interrupt controllers or system
clocks. I'm beginning to agree with Thierry that they should be treated
as normal platform devices as they're not required earlier than probe
time of their bus master devices.
Well, I think you'd have to propose patches for discussion since I'm
certainly not wed to the current approach; I just want something that
allows of_{dma,iommu}_configure to run with the information it needs.
Do we need of_dma_configure() to run when the device is created, or could we
postpone it to just before probe time ?
The usual answer is `we should model buses properly', but that's really
not practical afaict.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 18/19] iommu: exynos: init from dt-specific callback instead of initcall
On Mon, Dec 15, 2014 at 05:53:48PM +, Laurent Pinchart wrote:
Hi Will,
Hello again :)
On Monday 15 December 2014 17:43:02 Will Deacon wrote:
On Mon, Dec 15, 2014 at 05:27:30PM +, Laurent Pinchart wrote:
On Monday 15 December 2014 17:17:00 Will Deacon wrote:
Creating the platform device manually for the IOMMU is indeed grotty,
but I don't really understand why it's needed. Interrupt controllers,
for example, seem to get by without one.
There's several reasons, one of the most compelling ones I can think of at
the moment is runtime PM. IRQ controllers close to the CPU use CPU PM
notifiers instead. Note that IRQ controllers that are further away from
the CPU (such as GPIO-based IRQ controllers) are real platform devices
and use runtime PM.
Ok, that's a good point, but the IOMMU will still probe later anyway, right?
That depends on the driver implementation, using OF node match an IOMMU
driver
doesn't have to register a struct driver. Assuming we require IOMMU drivers
to
register a struct driver, a platform device should then be probed at a later
time.
However, if we wait until the IOMMU gets probed to initialize runtime PM and
make it functional, we'll be back in square one if the IOMMU gets probed
after
the bus master, as the bus master could start issuing bus requests at probe
time with the IOMMU not powered yet.
True, but couldn't the early init code do enough to get the thing
functional? That said, I'm showing my ignorance here as I'm not familiar
with the PM code (and the software models I have for the SMMU clearly don't
implement anything in this regard).
IOMMUs are not as low-level as system interrupt controllers or system
clocks. I'm beginning to agree with Thierry that they should be treated
as normal platform devices as they're not required earlier than probe
time of their bus master devices.
Well, I think you'd have to propose patches for discussion since I'm
certainly not wed to the current approach; I just want something that
allows of_{dma,iommu}_configure to run with the information it needs.
Do we need of_dma_configure() to run when the device is created, or could we
postpone it to just before probe time ?
I'm not sure I can answer that one... Arnd?
Will
--
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 18/19] iommu: exynos: init from dt-specific callback instead of initcall
On Monday 15 December 2014 18:13:23 Will Deacon wrote:
On Mon, Dec 15, 2014 at 05:53:48PM +, Laurent Pinchart wrote:
Hi Will,
Hello again :)
On Monday 15 December 2014 17:43:02 Will Deacon wrote:
On Mon, Dec 15, 2014 at 05:27:30PM +, Laurent Pinchart wrote:
On Monday 15 December 2014 17:17:00 Will Deacon wrote:
Creating the platform device manually for the IOMMU is indeed
grotty, but I don't really understand why it's needed. Interrupt
controllers, for example, seem to get by without one.
There's several reasons, one of the most compelling ones I can think
of at the moment is runtime PM. IRQ controllers close to the CPU use
CPU PM notifiers instead. Note that IRQ controllers that are further
away from the CPU (such as GPIO-based IRQ controllers) are real
platform devices and use runtime PM.
Ok, that's a good point, but the IOMMU will still probe later anyway,
right?
That depends on the driver implementation, using OF node match an IOMMU
driver doesn't have to register a struct driver. Assuming we require
IOMMU drivers to register a struct driver, a platform device should then
be probed at a later time.
However, if we wait until the IOMMU gets probed to initialize runtime PM
and make it functional, we'll be back in square one if the IOMMU gets
probed after the bus master, as the bus master could start issuing bus
requests at probe time with the IOMMU not powered yet.
True, but couldn't the early init code do enough to get the thing
functional? That said, I'm showing my ignorance here as I'm not familiar
with the PM code (and the software models I have for the SMMU clearly don't
implement anything in this regard).
We're reaching the limits of my knowledge as well. If the IOMMU is in a power
domain different than the bus masters the driver would at least need to ensure
that the power domain is turned on, which might be a bit hackish without
runtime PM.
IOMMUs are not as low-level as system interrupt controllers or system
clocks. I'm beginning to agree with Thierry that they should be
treated as normal platform devices as they're not required earlier
than probe time of their bus master devices.
Well, I think you'd have to propose patches for discussion since I'm
certainly not wed to the current approach; I just want something that
allows of_{dma,iommu}_configure to run with the information it needs.
Do we need of_dma_configure() to run when the device is created, or could
we postpone it to just before probe time ?
I'm not sure I can answer that one... Arnd?
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk: samsung: Fix Exynos 5420 pinctrl setup and clock disable failure due to domain being gated
Kevin Hilman khil...@kernel.org writes: Sylwester Nawrocki s.nawro...@samsung.com writes: On 09/12/14 13:59, Krzysztof Kozlowski wrote: On pią, 2014-12-05 at 15:15 +0100, Krzysztof Kozlowski wrote: Audio subsystem clocks are located in separate block. On Exynos 5420 if clock for this block (from main clock domain) 'mau_epll' is gated then any read or write to audss registers will block. This kind of boot hang was observed on Arndale Octa and Peach Pi/Pit after introducing runtime PM to pl330 DMA driver. After that commit the 'mau_epll' was gated, because the amba clock was disabled and there were no more users of mau_epll. The system hang on one of steps: 1. Disabling unused clocks from audss block. 2. During audss GPIO setup (just before probing i2s0 because samsung_pinmux_setup() tried to access memory from audss block which was gated. Add a workaround for this by enabling the 'mau_epll' clock in probe. Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com --- drivers/clk/samsung/clk-exynos-audss.c | 29 - 1 file changed, 28 insertions(+), 1 deletion(-) Sorry for pinging so quick but merge window is open and it looks like booting Exynos542x boards will be broken (because pl330 will no longer hold adma clock enabled so whole audss domain will be gated). This is a non-intrusive workaround for that issue, as wanted by Sylwester: https://lkml.org/lkml/2014/12/5/223 Any comments on this? The patch looks OK to me, it would be good though if someone else has confirmed it fixes the bug. I don't have any clock patches queued at the moment. Perhaps you could apply it directly, Mike ? I confirm it fixes the boot hang in linux-next (next-20141210) on my exynos5800-peach-pi and exynos5420-arndale-octa. Tested both exynos_defconfig and multi_v7_defconfig. Tested-by: Kevin Hilman khil...@linaro.org What's the status of this patch? linux-next is still broken for several Exynos5 platforms without this fix. 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 V8 00/14] drm/exynos: few patches to enhance bridge chip support
Hi Javier, On Friday 12 December 2014 10:51:50 Javier Martinez Canillas wrote: Hello, On 11/18/2014 07:20 AM, Ajay kumar wrote: On Sat, Nov 15, 2014 at 3:24 PM, Ajay Kumar wrote: This series is based on master branch of Linus tree at: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git This series has been in the mailing lists for months and have been tested by many people. What else is missing before it can be merged? It would be great to have proper display support on platforms that have a eDP to LVDS bridge chip (e.g: Snow, Peach Pit and Spring Chromebooks) and everything is in place but this series which had been missing many kernel releases already. Changes since V7: -- Address comments from Tomi and Laurent: -- Use videoports and endpoints to represent the connection between encoder, bridge and the panel, instead of using phandles. -- Address comments from Daniel: -- Make the patch description more descriptive. -- remove device pointer from drm_bridge, and just use device_node instead. -- don't pass encoder pointer to bridge_attach. -- Address comments from Sean Paul: -- Remove bridge from mode_config, and pull out drm_bridge functions from drm_crtc.c to drm_bridge.c Tomi and Laurent, You asked Ajay to change his series to use the video port and enpoints DT bindings instead of phandles, could you please review his latest version? I guess is now too late for 3.19 since we are in the middle of the merge window but it would be great if this series can at least made it to 3.20. I don't have time to review the series in details right now, but I'm happy with the DT bindings, and have no big issue with the rest of the patches. I don't really like the of_drm_find_bridge() concept introduced in 03/14 but I won't nack it given lack of time to implement an alternative proposal. It's an internal API, it can always be reworked later anyway. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] serial: samsung: Add support for early console
On 10/20/2014 08:28 PM, Marek Szyprowski wrote:
From: Tomasz Figa t.f...@samsung.com
This patch adds support for early console initialized from device tree
and kernel command line to all variants of Samsung serial driver.
Signed-off-by: Tomasz Figa t.f...@samsung.com
[mszyprow: added support for command line based initialization,
fixed comments, added documentation]
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Reviewed-by: Alim Akhtar alim.akh...@samsung.com
Tested-by: Alim Akhtar alim.akh...@samsung.com
I tested this patchset with Exynos5 SoC.
Tested-by: Chanwoo Choi cw00.c...@samsung.com
Thanks,
Chanwoo Choi
---
Documentation/kernel-parameters.txt | 12 +
drivers/tty/serial/Kconfig | 1 +
drivers/tty/serial/samsung.c| 103
3 files changed, 116 insertions(+)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 7dbe5ec9d9cd..24f363108ab3 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -961,6 +961,18 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
smh Use ARM semihosting calls for early console.
+ s3c2410,addr
+ s3c2412,addr
+ s3c2440,addr
+ s3c6400,addr
+ s5pv210,addr
+ exynos4210,addr
+ Use early console provided by serial driver available
+ on Samsung SoCs, requires selecting proper type and
+ a correct base address of the selected UART port. The
+ serial port must already be setup and configured.
+ Options are not yet supported.
+
earlyprintk=[X86,SH,BLACKFIN,ARM,M68k]
earlyprintk=vga
earlyprintk=efi
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 649b784081c7..50997be6cf6d 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -241,6 +241,7 @@ config SERIAL_SAMSUNG
tristate Samsung SoC serial support
depends on PLAT_SAMSUNG || ARCH_EXYNOS
select SERIAL_CORE
+ select SERIAL_EARLYCON
help
Support for the on-chip UARTs on the Samsung S3C24XX series CPUs,
providing /dev/ttySAC0, 1 and 2 (note, some machines may not
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index c78f43a481ce..8ad453a5d845 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -1856,6 +1856,109 @@ static struct platform_driver samsung_serial_driver =
{
module_platform_driver(samsung_serial_driver);
+/*
+ * Early console.
+ */
+
+struct samsung_early_console_data {
+ u32 txfull_mask;
+};
+
+static void samsung_early_busyuart(struct uart_port *port)
+{
+ while (!(readl(port-membase + S3C2410_UTRSTAT) S3C2410_UTRSTAT_TXFE))
+ ;
+}
+
+static void samsung_early_busyuart_fifo(struct uart_port *port)
+{
+ struct samsung_early_console_data *data = port-private_data;
+
+ while (readl(port-membase + S3C2410_UFSTAT) data-txfull_mask)
+ ;
+}
+
+static void samsung_early_putc(struct uart_port *port, int c)
+{
+ if (readl(port-membase + S3C2410_UFCON) S3C2410_UFCON_FIFOMODE)
+ samsung_early_busyuart_fifo(port);
+ else
+ samsung_early_busyuart(port);
+
+ writeb(c, port-membase + S3C2410_UTXH);
+}
+
+static void samsung_early_write(struct console *con, const char *s, unsigned
n)
+{
+ struct earlycon_device *dev = con-data;
+
+ uart_console_write(dev-port, s, n, samsung_early_putc);
+}
+
+static int __init samsung_early_console_setup(struct earlycon_device *device,
+ const char *opt)
+{
+ if (!device-port.membase)
+ return -ENODEV;
+
+ device-con-write = samsung_early_write;
+ return 0;
+}
+
+/* S3C2410 */
+static struct samsung_early_console_data s3c2410_early_console_data = {
+ .txfull_mask = S3C2410_UFSTAT_TXFULL,
+};
+
+static int __init s3c2410_early_console_setup(struct earlycon_device *device,
+ const char *opt)
+{
+ device-port.private_data = s3c2410_early_console_data;
+ return samsung_early_console_setup(device, opt);
+}
+OF_EARLYCON_DECLARE(s3c2410, samsung,s3c2410-uart,
+ s3c2410_early_console_setup);
+EARLYCON_DECLARE(s3c2410, s3c2410_early_console_setup);
+
+/* S3C2412, S3C2440, S3C64xx */
+static struct samsung_early_console_data s3c2440_early_console_data = {
+ .txfull_mask = S3C2440_UFSTAT_TXFULL,
+};
+
+static int __init s3c2440_early_console_setup(struct earlycon_device *device,
+ const char *opt)
+{
+ device-port.private_data =
[PATCH] cpufreq: exynos5440: protect call to dev_pm_opp_get_opp_count with RCU lock
dev_pm_opp_get_opp_count() must be called with RCU lock held. Signed-off-by: Dmitry Torokhov d...@chromium.org --- Again, not tested... drivers/cpufreq/exynos5440-cpufreq.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/cpufreq/exynos5440-cpufreq.c b/drivers/cpufreq/exynos5440-cpufreq.c index 21a90ed..588b9ee 100644 --- a/drivers/cpufreq/exynos5440-cpufreq.c +++ b/drivers/cpufreq/exynos5440-cpufreq.c @@ -373,7 +373,11 @@ static int exynos_cpufreq_probe(struct platform_device *pdev) failed to init cpufreq table: %d\n, ret); goto err_free_opp; } + + rcu_read_lock(); dvfs_info-freq_count = dev_pm_opp_get_opp_count(dvfs_info-dev); + rcu_read_unlock(); + exynos_sort_descend_freq_table(); if (of_property_read_u32(np, clock-latency, dvfs_info-latency)) -- 2.2.0.rc0.207.ga3a616c -- Dmitry -- 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 v6 1/2] Input: add regulator haptic driver
Hi Dmitry,
2014년 12월 14일 04:56에 Dmitry Torokhov 이(가) 쓴 글:
Hi Jaewon,
On Fri, Dec 12, 2014 at 07:32:28PM +0900, Jaewon Kim wrote:
This patch adds support for haptic driver controlled by
voltage of regulator. And this driver support for
Force Feedback interface from input framework
Signed-off-by: Jaewon Kim jaewon02@samsung.com
Signed-off-by: Hyunhee Kim hyunhee@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Tested-by: Chanwoo Choi cw00.c...@samsung.com
Reviewed-by: Chanwoo Choi cw00.c...@samsung.com
Reviewed-by: Pankaj Dubey pankaj.du...@samsung.com
---
.../devicetree/bindings/input/regulator-haptic.txt | 21 ++
drivers/input/misc/Kconfig | 11 +
drivers/input/misc/Makefile|1 +
drivers/input/misc/regulator-haptic.c | 259
include/linux/input/regulator-haptic.h | 31 +++
5 files changed, 323 insertions(+)
create mode 100644
Documentation/devicetree/bindings/input/regulator-haptic.txt
create mode 100644 drivers/input/misc/regulator-haptic.c
create mode 100644 include/linux/input/regulator-haptic.h
diff --git a/Documentation/devicetree/bindings/input/regulator-haptic.txt
b/Documentation/devicetree/bindings/input/regulator-haptic.txt
new file mode 100644
index 000..3ed1c7e
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/regulator-haptic.txt
@@ -0,0 +1,21 @@
+* Regulator Haptic Device Tree Bindings
+
+Required Properties:
+ - compatible : Should be regulator-haptic
+ - haptic-supply : Power supply to the haptic motor.
+ [*] refer Documentation/devicetree/bindings/regulator/regulator.txt
+
+ - max-microvolt : The maximum voltage value supplied to the haptic motor.
+ [The unit of the voltage is a micro]
+
+ - min-microvolt : The minimum voltage value supplied to the haptic motor.
+ [The unit of the voltage is a micro]
+
+Example:
+
+ haptics {
+ compatible = regulator-haptic;
+ haptic-supply = motor_regulator;
+ max-microvolt = 270;
+ min-microvolt = 110;
+ };
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 23297ab..e5e556d 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -394,6 +394,17 @@ config INPUT_CM109
To compile this driver as a module, choose M here: the module will be
called cm109.
+config INPUT_REGULATOR_HAPTIC
+ tristate regulator haptics support
+ select INPUT_FF_MEMLESS
+ help
+ This option enables device driver support for the haptic controlled
+ by regulator. This driver supports ff-memless interface
+ from input framework.
+
+ To compile this driver as a module, choose M here: the
+ module will be called regulator-haptic.
+
config INPUT_RETU_PWRBUTTON
tristate Retu Power button Driver
depends on MFD_RETU
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 19c7603..1f135af 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY) += pmic8xxx-pwrkey.o
obj-$(CONFIG_INPUT_POWERMATE) += powermate.o
obj-$(CONFIG_INPUT_PWM_BEEPER)+= pwm-beeper.o
obj-$(CONFIG_INPUT_RB532_BUTTON) += rb532_button.o
+obj-$(CONFIG_INPUT_REGULATOR_HAPTIC) += regulator-haptic.o
obj-$(CONFIG_INPUT_RETU_PWRBUTTON)+= retu-pwrbutton.o
obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER) += rotary_encoder.o
obj-$(CONFIG_INPUT_SGI_BTNS) += sgi_btns.o
diff --git a/drivers/input/misc/regulator-haptic.c
b/drivers/input/misc/regulator-haptic.c
new file mode 100644
index 000..2fa94bc
--- /dev/null
+++ b/drivers/input/misc/regulator-haptic.c
@@ -0,0 +1,259 @@
+/*
+ * Regulator haptic driver
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author: Jaewon Kim jaewon02@samsung.com
+ * Author: Hyunhee Kim hyunhee@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/input.h
+#include linux/input/regulator-haptic.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/regulator/consumer.h
+#include linux/slab.h
+
+#define MAX_MAGNITUDE_SHIFT16
+
+struct regulator_haptic {
+ struct device *dev;
+ struct input_dev *input_dev;
+ struct regulator *regulator;
+
+ struct work_struct work;
+ struct mutex mutex;
+
+ bool enabled;
+ bool suspend_state;
+ unsigned int max_volt;
+ unsigned int min_volt;
+ unsigned int intensity;
+ unsigned int magnitude;
+};
+
+static void regulator_haptic_enable(struct regulator_haptic *haptic, bool
state)
+{
+ int error;
+
+ if
Re: [RFC PATCHv3 2/7] devfreq: event: Add the list of supported devfreq-event type
Hi Krzysztof,
On 12/15/2014 11:53 PM, Krzysztof Kozlowski wrote:
On pią, 2014-12-12 at 17:27 +0900, Chanwoo Choi wrote:
This patch adds the list of supported devfreq-event type as following.
Each devfreq-event device driver would support the various devfreq-event type
for devfreq governor at the same time.
- DEVFREQ_EVENT_TYPE_RAW_DATA
- DEVFREQ_EVENT_TYPE_UTILIZATION
- DEVFREQ_EVENT_TYPE_BANDWIDTH
- DEVFREQ_EVENT_TYPE_LATENCY
Cc: MyungJoo Ham myungjoo@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
drivers/devfreq/devfreq-event.c | 44
+
include/linux/devfreq.h | 29 ++-
2 files changed, 64 insertions(+), 9 deletions(-)
diff --git a/drivers/devfreq/devfreq-event.c
b/drivers/devfreq/devfreq-event.c
index eaf59c1..9444f93 100644
--- a/drivers/devfreq/devfreq-event.c
+++ b/drivers/devfreq/devfreq-event.c
@@ -29,6 +29,9 @@
#include linux/of.h
#include governor.h
+#define EVENT_TYPE_RAW_DATA_MAX U64_MAX
+#define EVENT_TYPE_UTILIZATION_MAX 100
+
static struct class *devfreq_event_class;
/* The list of all devfreq event list */
@@ -144,7 +147,8 @@ EXPORT_SYMBOL_GPL(devfreq_event_is_enabled);
* Note that this function set the event to the devfreq-event device to
start
* for getting the event data which could be various event type.
*/
-int devfreq_event_set_event(struct devfreq_event_dev *edev)
+int devfreq_event_set_event(struct devfreq_event_dev *edev,
+enum devfreq_event_type type)
{
int ret;
@@ -158,7 +162,15 @@ int devfreq_event_set_event(struct devfreq_event_dev
*edev)
return -EPERM;
mutex_lock(edev-lock);
-ret = edev-desc-ops-set_event(edev);
+
+if ((edev-desc-type type) == 0) {
+dev_err(edev-dev, unsupported of devfreq-event type\n);
+mutex_unlock(edev-lock);
+return -EINVAL;
+}
+
+ret = edev-desc-ops-set_event(edev, type);
+
mutex_unlock(edev-lock);
return ret;
@@ -174,7 +186,9 @@ EXPORT_SYMBOL_GPL(devfreq_event_set_event);
* current event data and total_event should be stored in second parameter
* (total_event).
*/
-u64 devfreq_event_get_event(struct devfreq_event_dev *edev, u64
*total_event)
+u64 devfreq_event_get_event(struct devfreq_event_dev *edev,
+enum devfreq_event_type type,
+u64 *total_event)
{
u64 event;
@@ -190,7 +204,27 @@ u64 devfreq_event_get_event(struct devfreq_event_dev
*edev, u64 *total_event)
return 0;
mutex_lock(edev-lock);
-event = edev-desc-ops-get_event(edev, total_event);
+
+if ((edev-desc-type type) == 0) {
+dev_err(edev-dev, unsupported of devfreq-event type\n);
+return -EINVAL;
+}
+
+event = edev-desc-ops-get_event(edev, type, total_event);
+
+switch (type) {
+case DEVFREQ_EVENT_TYPE_RAW_DATA:
+case DEVFREQ_EVENT_TYPE_BANDWIDTH:
+case DEVFREQ_EVENT_TYPE_LATENCY:
+if ((event *total_event)
+|| ((event EVENT_TYPE_RAW_DATA_MAX) ||
+*total_event EVENT_TYPE_RAW_DATA_MAX))
+event = 0;
missing break here.
My mistake. I'll add it and 'default' case statement.
Best Regards,
Chanwoo Choi
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCHv3 1/7] devfreq: event: Add new devfreq_event class to provide basic data for devfreq governor
Hi Krzysztof,
On 12/15/2014 11:53 PM, Krzysztof Kozlowski wrote:
On pią, 2014-12-12 at 17:27 +0900, Chanwoo Choi wrote:
This patch add new devfreq_event class for devfreq_event device which provide
raw data (e.g., memory bus utilization/GPU utilization). This raw data from
devfreq_event data would be used for the governor of devfreq subsystem.
- devfreq_event device : Provide raw data for governor of existing devfreq
device
- devfreq device : Monitor device state and change frequency/voltage
of device
using the raw data from devfreq_event device
The devfreq subsystem support generic DVFS(Dynamic Voltage/Frequency Scaling)
for Non-CPU Devices. The devfreq device would dertermine current device state
using various governor (e.g., ondemand, performance, powersave). After
completed
determination of system state, devfreq device would change the
frequency/voltage
of devfreq device according to the result of governor.
But, devfreq governor must need basic data which indicates current device
state.
Existing devfreq subsystem only consider devfreq device which check current
system
state and determine proper system state using basic data. There is no
subsystem
for device providing basic data to devfreq device.
The devfreq subsystem must need devfreq_event device(data-provider device)
for
existing devfreq device. So, this patch add new devfreq_event class for
devfreq_event device which read various basic data(e.g, memory bus
utilization,
GPU utilization) and provide measured data to existing devfreq device through
standard APIs of devfreq_event class.
The following description explains the feature of two kind of devfreq class:
- devfreq class (existing)
: devfreq consumer device use raw data from devfreq_event device for
determining proper current system state and change voltage/frequency
dynamically using various governors.
- devfreq_event class (new)
: Provide measured raw data to devfreq device for governor
Cc: MyungJoo Ham myungjoo@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
[...]
+/**
+ * devfreq_event_get_event() - Get event and total_event from devfreq-event
dev.
+ * @edev: the devfreq-event device
+ *
+ * Note that this function get the calculated event data from devfreq-event
dev
+ * after stoping the progress of whole sequence of devfreq-event dev. Return
+ * current event data and total_event should be stored in second parameter
+ * (total_event).
+ */
+u64 devfreq_event_get_event(struct devfreq_event_dev *edev, u64
*total_event)
+{
I think this function should return int (0 for success, negative
otherwise) and store the event under pointer passed as argument.
Why? Because:
1. error conditions are indicated with 'return 0' but should be 'return
-EINVAL'
2. Exynos-ppmu driver returns -EINVAL.
Checking for error conditions is in such case more complex than it
should.
In this patchset,
the return value (event) and *total_event of devfreq_event_get_event() should
be used for busy_time/total_time of struct devfreq_dev_status
(include/linux/devfreq.h).
The busy_time/total_time is 'unsigned long' type.
So, I'll modify the prototype of devfreq_event_get_event() as following by
adding
new 'devfreq_event_data' structure.
struct devfreq_event_data {
u64 event;
u64 total_event;
};
int devfreq_event_get_event(struct devfreq_event_edev *edev, struct
devfreq_event_data *edata);
Best Regards,
Chanwoo Choi
--
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 v6 1/2] Input: add regulator haptic driver
On Tue, Dec 16, 2014 at 10:09:25AM +0900, Jaewon Kim wrote:
Hi Dmitry,
2014년 12월 14일 04:56에 Dmitry Torokhov 이(가) 쓴 글:
Hi Jaewon,
On Fri, Dec 12, 2014 at 07:32:28PM +0900, Jaewon Kim wrote:
...
+static int __maybe_unused regulator_haptic_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct regulator_haptic *haptic = platform_get_drvdata(pdev);
+
+ mutex_lock(haptic-mutex);
+ if (haptic-enabled) {
+ regulator_haptic_enable(haptic, false);
+ haptic-suspend_state = true;
Why do we only set suspend_state if an effect was playing? I think we
should always indicate that the device is suspended so that we do not
try to start playing another effect - while it is true that normally
effects are played by request from userspace which should be frozen by
now, it is theoretically possible to trigger an effect from kernel as
well.
This variable name seems to make you confuse.
I used this variable to restore the old state.
When kernel is entering suspend state while the motor is vibrating,
I store vibrating state for vibrate again after escape suspend state.
I will change variable name to suspend_restore.
And prevent to start playing effect when kernel entering suspend state.
You do not need to save if haptic was playing or not - on resume, if
haptic-magnitude != 0 you need to restart playing, otherwise leave it
off.
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCHv2 1/7] devfreq: event: Add new devfreq_event class to provide basic data for devfreq governor
Hi Krzysztof, On 12/15/2014 07:30 PM, Krzysztof Kozlowski wrote: On pią, 2014-12-12 at 12:42 +0900, Chanwoo Choi wrote: Hi Krzysztof, I replied again this mail because I'll use the mutex for set_event()/get_event() according to your comment. But, of_parse_phandle() seems that this function don't need the of_node_put() function. On 12/11/2014 11:13 AM, Chanwoo Choi wrote: Hi Krzysztof, First of all, thanks for your review. On 12/10/2014 06:37 PM, Krzysztof Kozlowski wrote: On wto, 2014-12-09 at 23:13 +0900, Chanwoo Choi wrote: This patch add new devfreq_event class for devfreq_event device which provide raw data (e.g., memory bus utilization/GPU utilization). This raw data from devfreq_event data would be used for the governor of devfreq subsystem. - devfreq_event device : Provide raw data for governor of existing devfreq device - devfreq device : Monitor device state and change frequency/voltage of device using the raw data from devfreq_event device The devfreq subsystem support generic DVFS(Dynamic Voltage/Frequency Scaling) for Non-CPU Devices. The devfreq device would dertermine current device state using various governor (e.g., ondemand, performance, powersave). After completed determination of system state, devfreq device would change the frequency/voltage of devfreq device according to the result of governor. But, devfreq governor must need basic data which indicates current device state. Existing devfreq subsystem only consider devfreq device which check current system state and determine proper system state using basic data. There is no subsystem for device providing basic data to devfreq device. The devfreq subsystem must need devfreq_event device(data-provider device) for existing devfreq device. So, this patch add new devfreq_event class for devfreq_event device which read various basic data(e.g, memory bus utilization, GPU utilization) and provide measured data to existing devfreq device through standard APIs of devfreq_event class. The following description explains the feature of two kind of devfreq class: - devfreq class (existing) : devfreq consumer device use raw data from devfreq_event device for determining proper current system state and change voltage/frequency dynamically using various governors. - devfreq_event class (new) : Provide measured raw data to devfreq device for governor Cc: MyungJoo Ham myungjoo@samsung.com Cc: Kyungmin Park kyungmin.p...@samsung.com Signed-off-by: Chanwoo Choi cw00.c...@samsung.com --- drivers/devfreq/Kconfig | 2 + drivers/devfreq/Makefile| 5 +- drivers/devfreq/devfreq-event.c | 302 drivers/devfreq/event/Makefile | 1 + include/linux/devfreq.h | 141 +++ 5 files changed, 450 insertions(+), 1 deletion(-) create mode 100644 drivers/devfreq/devfreq-event.c create mode 100644 drivers/devfreq/event/Makefile diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig index faf4e70..4d15b62 100644 --- a/drivers/devfreq/Kconfig +++ b/drivers/devfreq/Kconfig @@ -87,4 +87,6 @@ config ARM_EXYNOS5_BUS_DEVFREQ It reads PPMU counters of memory controllers and adjusts the operating frequencies and voltages with OPP support. +comment DEVFREQ Event Drivers + endif # PM_DEVFREQ diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile index 16138c9..a1ffabe 100644 --- a/drivers/devfreq/Makefile +++ b/drivers/devfreq/Makefile @@ -1,4 +1,4 @@ -obj-$(CONFIG_PM_DEVFREQ) += devfreq.o +obj-$(CONFIG_PM_DEVFREQ) += devfreq.o devfreq-event.o obj-$(CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND)+= governor_simpleondemand.o obj-$(CONFIG_DEVFREQ_GOV_PERFORMANCE)+= governor_performance.o obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE) += governor_powersave.o @@ -7,3 +7,6 @@ obj-$(CONFIG_DEVFREQ_GOV_USERSPACE) += governor_userspace.o # DEVFREQ Drivers obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ)+= exynos/ obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ)+= exynos/ + +# DEVFREQ Event Drivers +obj-$(CONFIG_PM_DEVFREQ) += event/ diff --git a/drivers/devfreq/devfreq-event.c b/drivers/devfreq/devfreq-event.c new file mode 100644 index 000..b47329f --- /dev/null +++ b/drivers/devfreq/devfreq-event.c @@ -0,0 +1,302 @@ +/* + * devfreq-event: Generic DEVFREQ Event class driver + * + * Copyright (C) 2014 Samsung Electronics + * Chanwoo Choi cw00.c...@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 driver is based on drivers/devfreq/devfreq.c + */ + +#include linux/kernel.h +#include linux/sched.h +#include linux/errno.h +#include linux/err.h +#include linux/init.h +#include linux/module.h +#include
Re: [alsa-devel] [PATCH/RFC 00/14] ASoC: samsung: Add clk provider for I2S internal clocks
Hi Sylwester, I need some more thought about interaction between the clk API calls on the clocks being exposed and the ASoC calls into sound/soc/samsung/i2s.c. I'm sending teh patches for review though to avoid any waste of time should it turn out the direction taken is wrong. This whole series definitely needs more testing, so far I only tested it on Odroid X2, with the I2S working in slave mode. your patches looks good to me. I did basic playback and capture test of your patches with i2s in master mode on exynos7. I also added secondary dai for testing and verified playback. But I think some more testing required to check the serialization of registers. Tried aplay with front dai in background and with secondary dai in the foreground. But due to one issue on my system backend playback not working. Thanks Padma [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2014-September/081753.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
