Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms
Hello,
On 2015-01-20 00:03, Tobias Jakobi wrote:
Hello!
Marek Szyprowski wrote:
Thanks for you tests and pointing this issue. I turned out that the
initial fix proposed
by Andrzej Hajda
(http://www.spinics.net/lists/linux-samsung-soc/msg38915.html) worked
fine, while the final version merged to clock fixes ('clk: samsung:
exynos4: set parent
of sclk_hdmiphy to hdmi' - commit
df019a5c0f7083001cb694f44821ca506425bda2) doesn't work
properly.
I should thank you for pushing all this code to mainline. It's really
nice to see how all the pieces now come together.
Please check the following kernel tree - instead of hacking around hdmi
clock I've added
handling of it directly to drm mixer driver:
https://git.linaro.org/people/marek.szyprowski/linux-srpol.git/shortlog/refs/heads/v3.19-odroid-hdmi
I hope that this will finally solve all mixer initialization related
issues (also for
Odroid XU3, discussed recently in the other thread). If it works fine, I
will resend
exynos4 hdmi patches to include this change.
I have picked the additional patches to my tree, which currently has a
bunch of other stuff in it, in particular v4 of the IOMMU series.
This is a known issue. When Exynos IOMMU DRM driver is enabled, you need
also
to enabled CONFIG_DRM_EXYNOS_IOMMU, otherwise the driver will crash on init.
This also need to be fixed, but for the time being I focused on other
issues...
Anyway, now the 'modetest' application immediately crashes the system,
but I get a least something on the serial console:
http://www.math.uni-bielefeld.de/~tjakobi/archive/odroid_modetest_crash_sysmmu.txt
So this is probably due to the IOMMU. Please note that DRM IOMMU support
(CONFIG_DRM_EXYNOS_IOMMU) was disabled (!) in my config.
CONFIG_EXYNOS_IOMMU however was on.
I'm going to retest with the IOMMU series removed and
CONFIG_EXYNOS_IOMMU disabled as well.
Just posting this already since you're probably interested in these
'side-issues' as well.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 02/21] irqchip: tegra: add DT-based support for legacy interrupt controller
On Mon, Jan 19, 2015 at 09:43:56AM +, Marc Zyngier wrote: > Tegra's LIC (Legacy Interrupt Controller) has been so far only > supported as a weird extension of the GIC, which is not exactly > pretty. > > The stacked IRQ domain framework fits this pretty well, and allows > the LIC code to be turned into a standalone irqchip. In the process, > make the driver DT aware, something that was sorely missing from > the mach-tegra implementation. > Note that the GIC isn't really stacked on top of the LIC. Each IRQ is presented to both the LIC and the GIC (as an SPI). The LIC is only used to wakeup the CPU in case the GIC is not powered. The LIC can also generate interrupts towards the AVP/ARM7, but that's outside the scope of Linux ofcourse. The LIC can also be used to force an IRQ and that forced IRQ will be propagated to the GIC. (see also figure 2, page 36 of the Tegra K1 TRM) Cheers, Peter. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND v2 2/7] mfd: cros_ec: Add char dev and virtual dev pointers
On Fri, 02 Jan 2015, Javier Martinez Canillas wrote:
> The ChromeOS Embedded Controller has to be accessed by applications.
> A virtual character device is used as an interface with user-space.
>
> Extend the struct cros_ec_device with the fields needed by the driver
> of this virtual character device.
>
> Signed-off-by: Javier Martinez Canillas
> ---
>
> Changes since v1: None, new patch.
>
> include/linux/mfd/cros_ec.h | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index 71675b1..324a346 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -16,6 +16,7 @@
> #ifndef __LINUX_MFD_CROS_EC_H
> #define __LINUX_MFD_CROS_EC_H
>
> +#include
> #include
> #include
> #include
> @@ -59,9 +60,17 @@ struct cros_ec_command {
> *
> * @ec_name: name of EC device (e.g. 'chromeos-ec')
> * @phys_name: name of physical comms layer (e.g. 'i2c-4')
> - * @dev: Device pointer
> + * @dev: Device pointer for physical comms device
> + * @vdev: Device pointer for virtual comms device
> + * @cdev: Character device structure for virtual comms device
> * @was_wake_device: true if this device was set to wake the system from
> * sleep at the last suspend
> + * @cmd_readmem: direct read of the EC memory-mapped region, if supported
> + * @offset is within EC_LPC_ADDR_MEMMAP region.
> + * @bytes: number of bytes to read. zero means "read a string" (including
> + * the trailing '\0'). At most only EC_MEMMAP_SIZE bytes can be read.
> + * Caller must ensure that the buffer is large enough for the result when
> + * reading a string.
> *
> * @priv: Private data
> * @irq: Interrupt to use
> @@ -90,8 +99,12 @@ struct cros_ec_device {
> const char *ec_name;
> const char *phys_name;
> struct device *dev;
> + struct device *vdev;
> + struct cdev cdev;
> bool was_wake_device;
> struct class *cros_class;
> + int (*cmd_readmem)(struct cros_ec_device *ec, unsigned int offset,
> +unsigned int bytes, void *dest);
Is this safe? Are you sure it's okay to provide an interface from
userspace to read (kernel?) memory?
> /* These are used to implement the platform-specific interface */
> void *priv;
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND v2 1/7] mfd: cros_ec: Use fixed size arrays to transfer data with the EC
On Fri, 02 Jan 2015, Javier Martinez Canillas wrote:
> The struct cros_ec_command will be used as an ioctl() argument for the
> API to control the ChromeOS EC from user-space. So the data structure
> has to be 64-bit safe to make it compatible between 32 and 64 avoiding
> the need for a compat ioctl interface. Since pointers are self-aligned
> to different byte boundaries, use fixed size arrays instead of pointers
> for transferring ingoing and outgoing data with the Embedded Controller.
>
> Also, re-arrange struct members by decreasing alignment requirements to
> reduce the needing padding size.
>
> Signed-off-by: Javier Martinez Canillas
> ---
>
> Hello,
>
> I choose EC_PROTO2_MAX_PARAM_SIZE as the maximum length for the input and
> output buffers since I see that is what is assumed in the cros_ec driver
> that is the maximum lengths. But the downstream kernel has also suppport
> for the EC host command protocol v3 even though there is currently no bus
> specific code to handle v3 packets. So I wonder if this is a good max len
> or if a different size should be used instead.
>
> Best regards,
> Javier
>
> Changes since v1: None, new patch
>
> drivers/i2c/busses/i2c-cros-ec-tunnel.c | 51
> +++--
> drivers/input/keyboard/cros_ec_keyb.c | 13 +
> drivers/mfd/cros_ec.c | 15 +-
> include/linux/mfd/cros_ec.h | 8 +++---
> 4 files changed, 29 insertions(+), 58 deletions(-)
Looks okay to me, but I'd be happy with some more reviews from the
Chrome guys. I would especially like some knowledgeable type to
answer your EC_PROTO2_MAX_PARAM_SIZE question. If no one does, I
guess it can always be changed later.
Acked-by: Lee Jones
> diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> index 875c22a..fa8dedd 100644
> --- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> +++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> @@ -182,72 +182,41 @@ static int ec_i2c_xfer(struct i2c_adapter *adap, struct
> i2c_msg i2c_msgs[],
> const u16 bus_num = bus->remote_bus;
> int request_len;
> int response_len;
> - u8 *request = NULL;
> - u8 *response = NULL;
> int result;
> - struct cros_ec_command msg;
> + struct cros_ec_command msg = { };
>
> request_len = ec_i2c_count_message(i2c_msgs, num);
> if (request_len < 0) {
> dev_warn(dev, "Error constructing message %d\n", request_len);
> - result = request_len;
> - goto exit;
> + return request_len;
> }
> +
> response_len = ec_i2c_count_response(i2c_msgs, num);
> if (response_len < 0) {
> /* Unexpected; no errors should come when NULL response */
> dev_warn(dev, "Error preparing response %d\n", response_len);
> - result = response_len;
> - goto exit;
> - }
> -
> - if (request_len <= ARRAY_SIZE(bus->request_buf)) {
> - request = bus->request_buf;
> - } else {
> - request = kzalloc(request_len, GFP_KERNEL);
> - if (request == NULL) {
> - result = -ENOMEM;
> - goto exit;
> - }
> - }
> - if (response_len <= ARRAY_SIZE(bus->response_buf)) {
> - response = bus->response_buf;
> - } else {
> - response = kzalloc(response_len, GFP_KERNEL);
> - if (response == NULL) {
> - result = -ENOMEM;
> - goto exit;
> - }
> + return response_len;
> }
>
> - result = ec_i2c_construct_message(request, i2c_msgs, num, bus_num);
> + result = ec_i2c_construct_message(msg.outdata, i2c_msgs, num, bus_num);
> if (result)
> - goto exit;
> + return result;
>
> msg.version = 0;
> msg.command = EC_CMD_I2C_PASSTHRU;
> - msg.outdata = request;
> msg.outsize = request_len;
> - msg.indata = response;
> msg.insize = response_len;
>
> result = cros_ec_cmd_xfer(bus->ec, &msg);
> if (result < 0)
> - goto exit;
> + return result;
>
> - result = ec_i2c_parse_response(response, i2c_msgs, &num);
> + result = ec_i2c_parse_response(msg.indata, i2c_msgs, &num);
> if (result < 0)
> - goto exit;
> + return result;
>
> /* Indicate success by saying how many messages were sent */
> - result = num;
> -exit:
> - if (request != bus->request_buf)
> - kfree(request);
> - if (response != bus->response_buf)
> - kfree(response);
> -
> - return result;
> + return num;
> }
>
> static u32 ec_i2c_functionality(struct i2c_adapter *adap)
> diff --git a/drivers/input/keyboard/cros_ec_keyb.c
> b/drivers/input/keyboard/cros_ec_keyb.c
> index ffa989f..769f8f7 100644
> --- a/drivers/input/keyboard/cros_ec_keyb.c
> +++ b/drivers/input/keyboa
Re: [PATCH v4 16/21] DT: exynos: update PMU binding
Hi Marc,
On Monday 19 January 2015 03:14 PM, Marc Zyngier wrote:
Document the fact that some Exynos PMUs are capable of acting as
an interrupt controller.
Signed-off-by: Marc Zyngier
---
Documentation/devicetree/bindings/arm/samsung/pmu.txt | 13 +
1 file changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
index 1e1979b..d698e74 100644
--- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
@@ -28,10 +28,23 @@ Properties:
- clocks : list of phandles and specifiers to all input clocks listed in
clock-names property.
+Optional properties:
+
+Some PMUs are capable of behaving as an interrupt controller (mostly
+to wake up a suspended PMU). In which case, they can have the
+following properties:
+
+- interrupt-controller: indicate that said PMU is an interrupt controller
+
Need to add #interrupt-cells property here.
+- interrupt-parent: a phandle indicating which interrupt controller
+ this PMU signals interrupts to.
+
Example :
pmu_system_controller: system-controller@1004 {
compatible = "samsung,exynos5250-pmu", "syscon";
reg = <0x1004 0x5000>;
+ interrupt-controller;
+ interrupt-parent = <&gic>;
#clock-cells = <1>;
clock-names = "clkout0", "clkout1", "clkout2", "clkout3",
"clkout4", "clkout8", "clkout9";
Thanks,
Pankaj Dubey
--
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 v4 15/21] ARM: exynos4/5: convert pmu wakeup to stacked domains
Hi Marc,
On Monday 19 January 2015 03:14 PM, Marc Zyngier wrote:
Exynos has been (ab)using the gic_arch_extn to provide
wakeup from suspend, and it makes a lot of sense to convert
this code to use stacked domains instead.
This patch does just this, updating the DT files to actually
reflect what the HW provides.
BIG FAT WARNING: because the DTs were so far lying by not
exposing the fact that the PMU block is actually the first
interrupt controller in the chain for RTC, kernels with this patch
applied wont have any suspend-resume facility when booted
with old DTs, and old kernels with updated DTs may not even boot.
Also, I stronly suspect that there is more than two wake-up
interrupts on these platforms, but I leave it to the maintainers
to fix their mess.
Signed-off-by: Marc Zyngier
---
I tested this patch series on SMDK5250 board.
With the addition of "#interrupt-cells = <3>;"in PMU device node S2R is
working on Exynos5250 based SMDK board.
arch/arm/boot/dts/exynos4.dtsi| 4 ++
arch/arm/boot/dts/exynos5250.dtsi | 4 ++
arch/arm/boot/dts/exynos5420.dtsi | 4 ++
arch/arm/mach-exynos/exynos.c | 14 ++---
arch/arm/mach-exynos/suspend.c| 122 ++
5 files changed, 129 insertions(+), 19 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index b8168f1..0e7d74e 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -141,6 +141,9 @@
pmu_system_controller: system-controller@1002 {
compatible = "samsung,exynos4210-pmu", "syscon";
reg = <0x1002 0x4000>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ interrupt-parent = <&gic>;
};
dsi_0: dsi@11C8 {
@@ -253,6 +256,7 @@
rtc@1007 {
compatible = "samsung,s3c6410-rtc";
reg = <0x1007 0x100>;
+ interrupt-parent = <&pmu_system_controller>;
interrupts = <0 44 0>, <0 45 0>;
clocks = <&clock CLK_RTC>;
clock-names = "rtc";
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 0a229fc..1dc5f6b 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -194,6 +194,9 @@
clock-names = "clkout16";
clocks = <&clock CLK_FIN_PLL>;
#clock-cells = <1>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ interrupt-parent = <&gic>;
};
sysreg_system_controller: syscon@1005 {
@@ -230,6 +233,7 @@
rtc: rtc@101E {
clocks = <&clock CLK_RTC>;
clock-names = "rtc";
+ interrupt-parent = <&pmu_system_controller>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 517e50f..35ecd36 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -309,6 +309,7 @@
rtc: rtc@101E {
clocks = <&clock CLK_RTC>;
clock-names = "rtc";
+ interrupt-parent = <&pmu_system_controller>;
status = "disabled";
};
@@ -748,6 +749,9 @@
clock-names = "clkout16";
clocks = <&clock CLK_FIN_PLL>;
#clock-cells = <1>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ interrupt-parent = <&gic>;
};
sysreg_system_controller: syscon@1005 {
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index c13d083..e417fdc 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -175,16 +175,15 @@ static void __init exynos_init_io(void)
exynos_map_io();
}
+/*
+ * Apparently, these SoCs are not able to wake-up from suspend using
+ * the PMU. Too bad. Should they suddenly become capable of such a
+ * feat, the matches below should be moved to suspend.c.
+ */
static const struct of_device_id exynos_dt_pmu_match[] = {
{ .compatible = "samsung,exynos3250-pmu" },
As I know Exynos3250, S2R support has been added in kgene/for-next and
should work as expected so we may need to do update "exynos_wkup_irq"
for exynos3250 and remove it from this list, so that it's S2R should not
break. I am adding concern engineer (+cc: Chanwoo Choi) in the loop.
- { .compatible = "samsung,exynos4210-pmu" },
- { .compatible = "samsung,exynos4212-pmu" },
- { .compatible = "samsung,exynos4412-pmu" },
- { .compatible = "samsung,exynos4415-pmu" },
- { .compatible = "samsung,exynos5250-pmu" },
{ .compatible = "samsung,exynos5260-pmu" },
{ .compatible = "samsung,exynos5410-pmu" },
- { .compatible = "samsung,exynos5420-pmu" },
{ /*sentinel*/ },
};
Re: [PATCHv8 1/9] devfreq: event: Add new devfreq_event class to provide basic data for devfreq governor
Dear Myungjoo,
On 01/20/2015 03:59 PM, MyungJoo Ham wrote:
>>
>> Dear Myungjoo,
>>
>> On 01/20/2015 01:34 PM, MyungJoo Ham wrote:
> []
+
+ mutex_lock(&edev->lock);
+ if (edev->desc->ops && edev->desc->ops->enable) {
+ ret = edev->desc->ops->enable(edev);
+ if (ret < 0)
+ goto err;
+ }
>>>
>>> Is there any reason to call enable(edev) even when enable_count is already
>>> > 0
>>> while you do not call disable(edev) while enable_count > 0?
>>>
>>> I think this may incur errors in the related device drivers.
>>> (e.g., incorrect pairing of clk/runtime-pm/regulator enable/disable
>>> at the device driver side)
>>
>> You're right. This part has potential errors. I'll fix it as following:
>> If edev is already enabled, devfreq_event_enable_edev() will just return
>> without any operation because devfreq-event(edev) can handle only one event
>> at the same time.
>>
>> mutex_lock(&edev->lock);
>> if (edev->enable_count)
>> dev_warn(&edev->dev, "%s is already enabled\n",
>> edev->desc->name);
>> ret = -EINVAL;
>> goto err;
>> }
>>
>> if (edev->desc->ops && edev->desc->ops->enable) {
>> ret = edev->desc->ops->enable(edev);
>> if (ret < 0)
>> goto err;
>> }
>> edev->enable_count++;
>
> No, your suggested modification creates another bug.
>
> It should not emit "warn" when enable_count > 0 at enable().
> It is a natural behavior from drivers.
> - You may have multiple drivers using edev.
> - You may have multiple threads using edev.
The devfreq-event cannot be used in multiple drivers in current version
If multiple driver set the event to devfreq-event device by using
devfreq_event_set_event() at the same time, previous event will be ignored.
If multiple drivers want to use devfreq-event device at the same time,
I have to implement additional feature.
>
> Thus, the above 12 lines should be replaced with:
>
> if (edev->desc->ops && edev->desc->ops->enable &&
> edev->enable_count == 0) {
> ret = edev->desc->ops->enable(edev);
> if (ret < 0)
> goto err;
> }
> edev->enable_count++;
>
>>
>>
>>>
+ edev->enable_count++;
+err:
+ mutex_unlock(&edev->lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(devfreq_event_enable_edev);
+
+/**
+ * devfreq_event_disable_edev() - Disable the devfreq-event dev and
decrease
+ * the enable_count of the devfreq-event
dev.
+ * @edev : the devfreq-event device
+ *
+ * Note that this function decrease the enable_count and disable the
+ * devfreq-event device. After the devfreq-event device is disabled,
+ * devfreq device can't use the devfreq-event device for get/set/reset
+ * operations.
+ */
+int devfreq_event_disable_edev(struct devfreq_event_dev *edev)
+{
+ int ret = 0;
+
+ if (!edev || !edev->desc)
+ return -EINVAL;
+
+ mutex_lock(&edev->lock);
+ if (edev->enable_count > 0) {
+ edev->enable_count--;
+ } else {
+ dev_warn(&edev->dev, "unbalanced enable_count\n");
+ ret = -EINVAL;
+ goto err;
+ }
+
+ if (edev->desc->ops && edev->desc->ops->disable) {
+ ret = edev->desc->ops->disable(edev);
+ if (ret < 0) {
+ edev->enable_count++;
+ goto err;
+ }
>
> Anyway, have you seen other subsystems doing fall-back operations as you've
> done by "edev->enable_count++" here? Or is this your own idea on falling back
> from errors with a disable callback?
I removed "edev->enable_count++" when fail to diable devfreq-event
and modify it as following:
+int devfreq_event_disable_edev(struct devfreq_event_dev *edev)
+{
+ int ret = 0;
+
+ if (!edev || !edev->desc)
+ return -EINVAL;
+
+ mutex_lock(&edev->lock);
+ if (!edev->enable_count) {
+ dev_warn(&edev->dev,
+ "%s is already disabled\n", edev->desc->name);
+ goto err;
+ }
+
+ if (edev->desc->ops && edev->desc->ops->disable) {
+ ret = edev->desc->ops->disable(edev);
+ if (ret < 0)
+ goto err;
+ }
+ edev->enable_count--;
+err:
+ mutex_unlock(&edev->lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(devfreq_event_disable_edev);
>
+ }
>>>
>>> You did it correctly with disable here;
>>> not calling it when it is not required.
[PATCH v9 1/7] devfreq: event: Add new devfreq_event class to provide basic data for devfreq governor
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 Cc: Kyungmin Park Signed-off-by: Chanwoo Choi --- drivers/devfreq/Kconfig | 2 + drivers/devfreq/Makefile| 6 +- drivers/devfreq/devfreq-event.c | 498 drivers/devfreq/event/Kconfig | 16 ++ drivers/devfreq/event/Makefile | 1 + include/linux/devfreq-event.h | 196 6 files changed, 718 insertions(+), 1 deletion(-) create mode 100644 drivers/devfreq/devfreq-event.c create mode 100644 drivers/devfreq/event/Kconfig create mode 100644 drivers/devfreq/event/Makefile create mode 100644 include/linux/devfreq-event.h diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig index faf4e70..21f8f17 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. +source "drivers/devfreq/event/Kconfig" + endif # PM_DEVFREQ diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile index 16138c9..c449336 100644 --- a/drivers/devfreq/Makefile +++ b/drivers/devfreq/Makefile @@ -1,4 +1,5 @@ -obj-$(CONFIG_PM_DEVFREQ) += devfreq.o +obj-$(CONFIG_PM_DEVFREQ) += devfreq.o +obj-$(CONFIG_PM_DEVFREQ_EVENT) += 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 +8,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) += event/ diff --git a/drivers/devfreq/devfreq-event.c b/drivers/devfreq/devfreq-event.c new file mode 100644 index 000..1a480c0 --- /dev/null +++ b/drivers/devfreq/devfreq-event.c @@ -0,0 +1,498 @@ +/* + * devfreq-event: a framework to provide raw data and events of devfreq devices + * + * Copyright (C) 2015 Samsung Electronics + * Author: Chanwoo Choi + * + * 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 +#include +#include +#include +#include +#include +#include +#include + +static struct class *devfreq_event_class; + +/* The list of all devfreq event list */ +static LIST_HEAD(devfreq_event_list); +static DEFINE_MUTEX(devfreq_event_list_lock); + +#define to_devfreq_event(DEV) container_of(DEV, struct devfreq_event_dev, dev) + +/** + * devfreq_event_enable_edev() - Enable the devfreq-event dev and increase + * the enable_count of devfreq-event dev. + * @edev : the devfreq-event device + * + * Note that this function increase the enable_count and enable the + * devfreq-event device. The devfreq-event device should be enabled
Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
On 9 January 2015 at 02:48, Rob Herring wrote:
> Adding Viresh.
Sorry for being too late, I was very busy with other cpufreq stuff I was doing
and saved this thread for later as it required me to understand it properly..
>> +Required properties for memory bus block:
>> +- clock-names : the name of clock used by the memory bus, "memory-bus".
>> +- clocks : phandles for clock specified in "clock-names" property.
>> +- #clock-cells: should be 1.
>> +- frequency: the frequency table to support DVFS feature.
>
> So you have just defined a new OPP table format. We already have one
> and Viresh is working to create a more extendable one. He asked about
> what's needed in devfreq, so Viresh here you go. :)
I failed to understand what's new here, probably I need more clarity on
what we are doing here..
So, this is what I see from OPPs point of view, everything else stripped out.
>> + memory_bus_int: memory_bus@1 {
>> + operating-points = <
>> + 40 95
>> + 20 95
>> + 133000 925000
>> + 10 85
>> + 8 85
>> + 5 85>;
So these are the OPPs your "groups" support and below ones are
the frequencies that each block will support. Right ?
>> + blocks {
>> + frequency = <
>> + 10
>> + 10
>> + 10
>> + 10
Why this replication here ?
>> + 5
>> + 5>;
>> + };
How are the above two tables (operating-points and frequency) related
here? What about the voltages at which these frequencies are possible ?
>> + display_block: memory_bus_block2 {
>> + frequency = <
>> + 20
>> + 16
>> + 10
>> + 8
>> + 8
>> + 5>;
>> + };
>> + isp_block: memory_bus_block3 {
>> + frequency = <
>> + 20
>> + 20
>> + 10
>> + 8
>> + 5
>> + 5>;
>> + };
>> + gps_block: memory_bus_block4 {
>> + frequency = <
>> + 30
>> + 20
>> + 133000
>> + 10
>> + 5
>> + 5>;
>> + };
same for others as well..
--
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 v9 3/7] devfreq: event: Add documentation for exynos-ppmu devfreq-event driver
This patch adds the documentation for Exynos PPMU (Platform Performance
Monitoring Unit) devfreq-event driver.
Cc: MyungJoo Ham
Cc: Kyungmin Park
Signed-off-by: Chanwoo Choi
Acked-by: MyungJoo Ham
---
.../bindings/devfreq/event/exynos-ppmu.txt | 110 +
1 file changed, 110 insertions(+)
create mode 100644
Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
diff --git a/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
b/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
new file mode 100644
index 000..b54bf3a
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
@@ -0,0 +1,110 @@
+
+* Samsung Exynos PPMU (Platform Performance Monitoring Unit) device
+
+The Samsung Exynos SoC has PPMU (Platform Performance Monitoring Unit) for
+each IP. PPMU provides the primitive values to get performance data. These
+PPMU events provide information of the SoC's behaviors so that you may
+use to analyze system performance, to make behaviors visible and to count
+usages of each IP (DMC, CPU, RIGHTBUS, LEFTBUS, CAM interface, LCD, G3D, MFC).
+The Exynos PPMU driver uses the devfreq-event class to provide event data
+to various devfreq devices. The devfreq devices would use the event data when
+derterming the current state of each IP.
+
+Required properties:
+- compatible: Should be "samsung,exynos-ppmu".
+- reg: physical base address of each PPMU and length of memory mapped region.
+
+Optional properties:
+- clock-names : the name of clock used by the PPMU, "ppmu"
+- clocks : phandles for clock specified in "clock-names" property
+- #clock-cells: should be 1.
+
+Example1 : PPMU nodes in exynos3250.dtsi are listed below.
+
+ ppmu_dmc0: ppmu_dmc0@106a {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x106a 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_dmc1: ppmu_dmc1@106b {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x106b 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_cpu: ppmu_cpu@106c {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x106c 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_rightbus: ppmu_rightbus@112a {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x112a 0x2000>;
+ clocks = <&cmu CLK_PPMURIGHT>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_leftbus: ppmu_leftbus0@116a {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x116a 0x2000>;
+ clocks = <&cmu CLK_PPMULEFT>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+Example2 : Events of each PPMU node in exynos3250-rinato.dts are listed below.
+
+ &ppmu_dmc0 {
+ status = "okay";
+
+ events {
+ ppmu_dmc0_3: ppmu-event3-dmc0 {
+ event-name = "ppmu-event3-dmc0";
+ };
+
+ ppmu_dmc0_2: ppmu-event2-dmc0 {
+ event-name = "ppmu-event2-dmc0";
+ };
+
+ ppmu_dmc0_1: ppmu-event1-dmc0 {
+ event-name = "ppmu-event1-dmc0";
+ };
+
+ ppmu_dmc0_0: ppmu-event0-dmc0 {
+ event-name = "ppmu-event0-dmc0";
+ };
+ };
+ };
+
+ &ppmu_dmc1 {
+ status = "okay";
+
+ events {
+ ppmu_dmc1_3: ppmu-event3-dmc1 {
+ event-name = "ppmu-event3-dmc1";
+ };
+ };
+ };
+
+ &ppmu_leftbus {
+ status = "okay";
+
+ events {
+ ppmu_leftbus_3: ppmu-event3-leftbus {
+ event-name = "ppmu-event3-leftbus";
+ };
+ };
+ };
+
+ &ppmu_rightbus {
+ status = "okay";
+
+ events {
+ ppmu_rightbus_3: ppmu-event3-rightbus {
+ event-name = "ppmu-event3-rightbus";
+ };
+ };
+ };
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 2/7] devfreq: event: Add exynos-ppmu devfreq-event driver
This patch adds exynos-ppmu devfreq-event driver to get performance data
of each IP for Samsung Exynos SoC. These event from Exynos PPMU provide
useful information about the behavior of the SoC that you can use when
analyzing system performance, and made visible and can be counted using
logic in each IP.
This patch is based on existing drivers/devfreq/exynos/exynos-ppmu.c
Cc: MyungJoo Ham
Cc: Kyungmin Park
Signed-off-by: Chanwoo Choi
Acked-by: MyungJoo Ham
---
drivers/devfreq/event/Kconfig | 9 +
drivers/devfreq/event/Makefile | 1 +
drivers/devfreq/event/exynos-ppmu.c | 374
drivers/devfreq/event/exynos-ppmu.h | 93 +
4 files changed, 477 insertions(+)
create mode 100644 drivers/devfreq/event/exynos-ppmu.c
create mode 100644 drivers/devfreq/event/exynos-ppmu.h
diff --git a/drivers/devfreq/event/Kconfig b/drivers/devfreq/event/Kconfig
index 1ced42c..a11720a 100644
--- a/drivers/devfreq/event/Kconfig
+++ b/drivers/devfreq/event/Kconfig
@@ -13,4 +13,13 @@ menuconfig PM_DEVFREQ_EVENT
if PM_DEVFREQ_EVENT
+config DEVFREQ_EVENT_EXYNOS_PPMU
+ bool "EXYNOS PPMU (Platform Performance Monitoring Unit) DEVFREQ event
Driver"
+ depends on ARCH_EXYNOS
+ select PM_OPP
+ help
+ This add the devfreq-event driver for Exynos SoC. It provides PPMU
+ (Platform Performance Monitoring Unit) counters to estimate the
+ utilization of each module.
+
endif # PM_DEVFREQ_EVENT
diff --git a/drivers/devfreq/event/Makefile b/drivers/devfreq/event/Makefile
index dc56005..be146ea 100644
--- a/drivers/devfreq/event/Makefile
+++ b/drivers/devfreq/event/Makefile
@@ -1 +1,2 @@
# Exynos DEVFREQ Event Drivers
+obj-$(CONFIG_DEVFREQ_EVENT_EXYNOS_PPMU) += exynos-ppmu.o
diff --git a/drivers/devfreq/event/exynos-ppmu.c
b/drivers/devfreq/event/exynos-ppmu.c
new file mode 100644
index 000..135be0a
--- /dev/null
+++ b/drivers/devfreq/event/exynos-ppmu.c
@@ -0,0 +1,374 @@
+/*
+ * exynos_ppmu.c - EXYNOS PPMU (Platform Performance Monitoring Unit) support
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author : Chanwoo Choi
+ *
+ * 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/exynos/exynos_ppmu.c
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "exynos-ppmu.h"
+
+struct exynos_ppmu_data {
+ void __iomem *base;
+ struct clk *clk;
+};
+
+struct exynos_ppmu {
+ struct devfreq_event_dev **edev;
+ struct devfreq_event_desc *desc;
+ unsigned int num_events;
+
+ struct device *dev;
+ struct mutex lock;
+
+ struct exynos_ppmu_data ppmu;
+};
+
+#define PPMU_EVENT(name) \
+ { "ppmu-event0-"#name, PPMU_PMNCNT0 }, \
+ { "ppmu-event1-"#name, PPMU_PMNCNT1 }, \
+ { "ppmu-event2-"#name, PPMU_PMNCNT2 }, \
+ { "ppmu-event3-"#name, PPMU_PMNCNT3 }
+
+struct __exynos_ppmu_events {
+ char *name;
+ int id;
+} ppmu_events[] = {
+ /* For Exynos3250, Exynos4 and Exynos5260 */
+ PPMU_EVENT(g3d),
+ PPMU_EVENT(fsys),
+
+ /* For Exynos4 SoCs and Exynos3250 */
+ PPMU_EVENT(dmc0),
+ PPMU_EVENT(dmc1),
+ PPMU_EVENT(cpu),
+ PPMU_EVENT(rightbus),
+ PPMU_EVENT(leftbus),
+ PPMU_EVENT(lcd0),
+ PPMU_EVENT(camif),
+
+ /* Only for Exynos3250 and Exynos5260 */
+ PPMU_EVENT(mfc),
+
+ /* Only for Exynos4 SoCs */
+ PPMU_EVENT(mfc-left),
+ PPMU_EVENT(mfc-right),
+
+ /* Only for Exynos5260 SoCs */
+ PPMU_EVENT(drex0-s0),
+ PPMU_EVENT(drex0-s1),
+ PPMU_EVENT(drex1-s0),
+ PPMU_EVENT(drex1-s1),
+ PPMU_EVENT(eagle),
+ PPMU_EVENT(kfc),
+ PPMU_EVENT(isp),
+ PPMU_EVENT(fimc),
+ PPMU_EVENT(gscl),
+ PPMU_EVENT(mscl),
+ PPMU_EVENT(fimd0x),
+ PPMU_EVENT(fimd1x),
+ { /* sentinel */ },
+};
+
+static int exynos_ppmu_find_ppmu_id(struct devfreq_event_dev *edev)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(ppmu_events); i++)
+ if (!strcmp(edev->desc->name, ppmu_events[i].name))
+ return ppmu_events[i].id;
+
+ return -EINVAL;
+}
+
+static int exynos_ppmu_disable(struct devfreq_event_dev *edev)
+{
+ struct exynos_ppmu *info = devfreq_event_get_drvdata(edev);
+ u32 pmnc;
+
+ /* Disable all counters */
+ __raw_writel(PPMU_CCNT_MASK |
+PPMU_PMCNT0_MASK |
+PPMU_PMCNT1_MASK |
+PPMU_PMCNT2_MASK |
+PPMU_PMCNT3_MASK,
+info->ppmu.base + PPMU_CNTENC);
+
+ /* Disable PPMU */
+ pmnc = __raw_readl(info->ppmu.base + PPMU_PMNC);
+ pmnc &= ~PPMU_PMNC_ENABLE_MASK;
+
[PATCH v9 5/7] ARM: dts: Add PPMU dt node for Exynos4 SoCs
This patch add PPMU (Platform Performance Monitoring Unit) dt node for Exynos4
(Exynos4210/4212/4412) SoC. PPMU dt node is used to monitor the utilization of
each IP.
The Exynos4210/Exynos4212/Exynos4412 SoC includes following PPMUs:
- PPMU_DMC0 0x106A_
- PPMU_DMC1 0x106B_
- PPMU_CPU 0x106C_
- PPMU_ACP 0x10AE_
- PPMU_RIGHT_BUS 0x112A_
- PPMU_LEFT_BUS 0x116A_
- PPMU_FSYS 0x1263_
- PPMU_LCD0 0x11E4_
- PPMU_CAMIF 0x11AC_
- PPMU_IMAGE 0x12AA_
- PPMU_TV0x12E4_
- PPMU_3D0x1322_
- PPMU_MFC_LEFT 0x1366_
- PPMU_MFC_RIGHT 0x1367_
Additionally, the Exynos4210 SoC includes following PPMUs:
- PPMU_LCD1 0x1224_
Cc: Kukjin Kim
Signed-off-by: Chanwoo Choi
Acked-by: MyungJoo Ham
---
arch/arm/boot/dts/exynos4.dtsi| 108 ++
arch/arm/boot/dts/exynos4210.dtsi | 8 +++
2 files changed, 116 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index b8168f1..70064dc 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -645,4 +645,112 @@
samsung,sysreg = <&sys_reg>;
status = "disabled";
};
+
+ ppmu_dmc0: ppmu_dmc0@106a {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x106a 0x2000>;
+ clocks = <&clock CLK_PPMUDMC0>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_dmc1: ppmu_dmc1@106b {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x106b 0x2000>;
+ clocks = <&clock CLK_PPMUDMC1>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_cpu: ppmu_cpu@106c {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x106c 0x2000>;
+ clocks = <&clock CLK_PPMUCPU>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_acp: ppmu_acp@10ae {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x106e 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_rightbus: ppmu_rightbus@112a {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x112a 0x2000>;
+ clocks = <&clock CLK_PPMURIGHT>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_leftbus: ppmu_leftbus0@116a {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x116a 0x2000>;
+ clocks = <&clock CLK_PPMULEFT>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_camif: ppmu_camif@11ac {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x11ac 0x2000>;
+ clocks = <&clock CLK_PPMUCAMIF>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_lcd0: ppmu_lcd0@11e4 {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x11e4 0x2000>;
+ clocks = <&clock CLK_PPMULCD0>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_fsys: ppmu_g3d@1263 {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x1263 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_image: ppmu_image@12aa {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x12aa 0x2000>;
+ clocks = <&clock CLK_PPMUIMAGE>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_tv: ppmu_tv@12e4 {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x12e4 0x2000>;
+ clocks = <&clock CLK_PPMUTV>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_g3d: ppmu_g3d@1322 {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x1322 0x2000>;
+ clocks = <&clock CLK_PPMUG3D>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_mfc_left: ppmu_mfc_left@1366 {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x1366 0x2000>;
+ clocks = <&clock CLK_PPMUMFC_L>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_mfc_right: ppmu_mfc_right@1367 {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x1367 0x2000>;
+ clocks = <&clock CLK_PPMUMFC_R>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
};
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
[PATCH v9 0/7] devfreq: Add devfreq-event class to provide raw data for devfreq device
This patchset add new devfreq_event class to provide raw data to determine
current utilization of device which is used for devfreq governor.
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
Changelog:
Changes from v8:
(https://lkml.org/lkml/2015/1/12/299)
- Fix issue of devfreq-event.c driver by Myunjoo's comment
: Merge patch2 (resource-managed function) with patch1
: Fix bug in devfreq_event_{enable|disable}_edev() about enable_count
operation
: Simplify error checking code in devfreq_event_get_event()
: Define devfreq_event_get_drvdata() as static inline function type
: Reduce the time of critical section scope in devfreq_event_remove_edev()
: Rename field name of devfreq_event_data structure
(total_event / event -> total_count / load_count)
- Drop following patch[1] because Exynos5260 cannot be tested for exynos-ppmu.c
driver
[1] [PATCHv8 7/9] ARM: dts: Add PPMU dt node for Exynos5260 SoC
- https://lkml.org/lkml/2015/1/12/301
- Clean-up exynos-ppmu.c without update
Changes from v7:
(https://lkml.org/lkml/2015/1/7/795)
- Use EXPORT_SYMBOL_GPL macro instead of EXPORT_SYMBOL
- Fix the binding document of exynos-ppmu.c driver
- Drop the devfreq-event type patch because it isnt' clear
- Fix bug of devfreq_event_add_edev() when fail to execute device_register()
- Modify resource free operation on following functions:
: devfreq_event_remove_edev()
: devfreq_event_release_edev()
Changes from v6:
(https://lkml.org/lkml/2014/12/28/139)
- This patchset is based on v3.19-rc3.
1. devfreq-event class driver
- Fix build break if devfreq-event framework is off
- Add resource-managed function for devfreq-event device
: devm_devfreq_event_add_edev()
: devm_devfreq_event_remove_edev()
Changes from v5:
(https://lkml.org/lkml/2014/12/22/527)
- Rebase these patch-set on v3.19-rc1 and Test it.
1. exynos-ppmu.c
- Change the error value when of_iomap() fail to map the memory
- Remove owner setting of platform_driver
- Add exynos_ppmu_disable() function
2. exynos dts file
- Add PPMU node to Exynos3250-based Monk board
- Remove ppmu_cpu node on Exynos4412-based TRATS2 board and add
ppmu_leftbus/rightbus node
Changes from v4:
(https://lkml.org/lkml/2014/12/16/511)
1. devfreq-event class driver
- Add devfreq_event_get_edev_count() function
- Modify the simple description of devfreq-event framework in devfreq-event.c
- Minimize the usage range of global lock usage in devfreq_event_add_edev()
- Remove '_is_enabled()' function pointer in devfreq_event_ops structure
- Add separte CONFIG_PM_DEVFREQ_EVENT configuration
- Add new devfreq-event.h header file including devfreq-event helper functions
2. exynos dts file
- Add new patch to support PPMU with DEVFREQ-event on Exynos4412-based TRATS2
Changes from v3:
(https://lkml.org/lkml/2014/12/12/219)
1. devfreq-event class driver
- Fix return value of devfreq_event_get_event()
- Add new structure devfreq_event_data for devfreq_event_get_event()
- Modify the prototype of devfreq_event_get_event() function
- Call of_node_put after calling of_parse_phandle() to decrement refcount
2. exynos-ppmu driver
- Modify usage of devfreq_event_get_event() function
according to new prototype of this funciton
- Add the additional description to exynos-ppmu.txt how to add PPMU node
in board dts file
- Use 'PPMU_EVENT' macro to remove duplicate codes
- Add the support of PPMU for Exynos5260
3. exynos dts file
- Add missing PPMU_FSYS node to exynos3250.dtsi
- Fix 'ppmu_mfc_l' node name as 'ppmu_mfc' because exynos3250 has only one MFC
IP.
- Add missing PPMU_ACP/G3D to exynos4.dtsi
4. etc
- Fix wrong abbreviation of PPMU (PPMU :Platform Performance Monitoring Unit)
- Add new patch to support the PPMU of Exynos5260 SoC
Changes from v2:
(https://lkml.org/lkml/2014/12/9/304)
1. devfreq-event class driver
- Rename all the helper functions of devfreq-event device
- Add devfreq_event_remove_edev() instead of devfreq_put_event_dev()
- Add devfreq_event_release_edev() to initialize it before put device
- Add the detailed description of devfreq-event API
- Add the attributes of devfreq-event class (enable_count)
- Check the overflow about event/total_event data in devfreq_event_get_event()
- Remove the 'exclusive flag' feature
- Set set_event()/get_event() functions as mandary
- Add missing of_node_put() call
- Change variable type of 'get_event()' funciton from 'int' to 'u64'
2. exynos-ppmu driver
- Remove un-used field (struct devfreq)
- Use 'of_get_child_by_name()' instead of 'of_find_node_by_name()'
- Add missing of_node_put() call
- Fix wrong clock control
- Use devfreq_event_remove_edev() instead of devfreq_remove_device()
- Add the documentation fo
[PATCH v9 6/7] ARM: dts: exynos: Add PPMU node for Exynos3250-based Rinato/Monk board
This patch add PPMU dt node to Exynos3250-base Rinato/Monk board. The PPMU node
is used to get the utilization of DMC0/DMC1/LEFTBUS/RIGHTBUS Block.
Cc: Kukjin Kim
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
arch/arm/boot/dts/exynos3250-monk.dts | 40 +
arch/arm/boot/dts/exynos3250-rinato.dts | 40 +
2 files changed, 80 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250-monk.dts
b/arch/arm/boot/dts/exynos3250-monk.dts
index 24822aa..fcceb59 100644
--- a/arch/arm/boot/dts/exynos3250-monk.dts
+++ b/arch/arm/boot/dts/exynos3250-monk.dts
@@ -420,6 +420,46 @@
status = "okay";
};
+&ppmu_dmc0 {
+ status = "okay";
+
+ events {
+ ppmu_dmc0_3: ppmu-event3-dmc0 {
+ event-name = "ppmu-event3-dmc0";
+ };
+ };
+};
+
+&ppmu_dmc1 {
+ status = "okay";
+
+ events {
+ ppmu_dmc1_3: ppmu-event3-dmc1 {
+ event-name = "ppmu-event3-dmc1";
+ };
+ };
+};
+
+&ppmu_leftbus {
+ status = "okay";
+
+ events {
+ ppmu_leftbus_3: ppmu-event3-leftbus {
+ event-name = "ppmu-event3-leftbus";
+ };
+ };
+};
+
+&ppmu_rightbus {
+ status = "okay";
+
+ events {
+ ppmu_rightbus_3: ppmu-event3-rightbus {
+ event-name = "ppmu-event3-rightbus";
+ };
+ };
+};
+
&xusbxti {
clock-frequency = <2400>;
};
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 7cc52b5..9dd1ce1 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -595,6 +595,46 @@
status = "okay";
};
+&ppmu_dmc0 {
+ status = "okay";
+
+ events {
+ ppmu_dmc0_3: ppmu-event3-dmc0 {
+ event-name = "ppmu-event3-dmc0";
+ };
+ };
+};
+
+&ppmu_dmc1 {
+ status = "okay";
+
+ events {
+ ppmu_dmc1_3: ppmu-event3-dmc1 {
+ event-name = "ppmu-event3-dmc1";
+ };
+ };
+};
+
+&ppmu_leftbus {
+ status = "okay";
+
+ events {
+ ppmu_leftbus_3: ppmu-event3-leftbus {
+ event-name = "ppmu-event3-leftbus";
+ };
+ };
+};
+
+&ppmu_rightbus {
+ status = "okay";
+
+ events {
+ ppmu_rightbus_3: ppmu-event3-rightbus {
+ event-name = "ppmu-event3-rightbus";
+ };
+ };
+};
+
&xusbxti {
clock-frequency = <2400>;
};
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 4/7] ARM: dts: Add PPMU dt node for Exynos3250 SoC
This patch add PPMU (Platform Performance Monitoring Unit) dt node
to estimate the utilization of each IP in Exynos SoC throught DEVFREQ Event
subsystem.
This patch adds following PPMU dt nodes:
- PPMU_DMC0 0x106a
- PPMU_DMC1 0x106b
- PPMU_RIGHTBUS 0x112A
- PPMU_LEFTBUS 0x116A
- PPMU_CAMIF0x11AC
- PPMU_LCD0 0x11E4
- PPMU_FSYS 0x1263
- PPMU_3D 0x1322
- PPMU_MFC 0x1366
- PPMU_CPU 0x106c
Cc: Kukjin Kim
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
Acked-by: MyungJoo Ham
---
arch/arm/boot/dts/exynos3250.dtsi | 74 +++
1 file changed, 74 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index d89fdf5..45513ed 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -530,6 +530,80 @@
compatible = "arm,cortex-a7-pmu";
interrupts = <0 18 0>, <0 19 0>;
};
+
+ ppmu_dmc0: ppmu_dmc0@106a {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x106a 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_dmc1: ppmu_dmc1@106b {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x106b 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_cpu: ppmu_cpu@106c {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x106c 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_rightbus: ppmu_rightbus@112a {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x112a 0x2000>;
+ clocks = <&cmu CLK_PPMURIGHT>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_leftbus: ppmu_leftbus0@116a {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x116a 0x2000>;
+ clocks = <&cmu CLK_PPMULEFT>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_camif: ppmu_camif@11ac {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x11ac 0x2000>;
+ clocks = <&cmu CLK_PPMUCAMIF>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_lcd0: ppmu_lcd0@11e4 {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x11e4 0x2000>;
+ clocks = <&cmu CLK_PPMULCD0>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_fsys: ppmu_fsys@1263 {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x1263 0x2000>;
+ clocks = <&cmu CLK_PPMUFILE>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_g3d: ppmu_g3d@1322 {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x1322 0x2000>;
+ clocks = <&cmu CLK_PPMUG3D>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_mfc: ppmu_mfc@1366 {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x1366 0x2000>;
+ clocks = <&cmu CLK_PPMUMFC_L>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
};
};
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 7/7] ARM: dts: exynos: Add PPMU node for Exynos4412-based TRATS2 board
This patch add dt node for PPMU_{DMC0|DMC1|LEFTBUS|RIGHTBUS} for
exynos4412-trats2 board. Each PPMU dt node includes one event of 'PPMU Count3'.
Cc: Kukjin Kim
Cc: Myungjoo Ham
Cc: Kyungmin Park
Signed-off-by: Chanwoo Choi
Acked-by: MyungJoo Ham
---
arch/arm/boot/dts/exynos4412-trats2.dts | 40 +
1 file changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 29231b4..70eac85 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -865,6 +865,46 @@
};
};
+&ppmu_dmc0 {
+ status = "okay";
+
+ events {
+ ppmu_dmc0_3: ppmu-event3-dmc0 {
+ event-name = "ppmu-event3-dmc0";
+ };
+ };
+};
+
+&ppmu_dmc1 {
+ status = "okay";
+
+ events {
+ ppmu_dmc1_3: ppmu-event3-dmc1 {
+ event-name = "ppmu-event3-dmc1";
+ };
+ };
+};
+
+&ppmu_leftbus {
+ status = "okay";
+
+ events {
+ ppmu_leftbus_3: ppmu-event3-leftbus {
+ event-name = "ppmu-event3-leftbus";
+ };
+ };
+};
+
+&ppmu_rightbus {
+ status = "okay";
+
+ events {
+ ppmu_rightbus_3: ppmu-event3-rightbus {
+ event-name = "ppmu-event3-rightbus";
+ };
+ };
+};
+
&pinctrl_0 {
pinctrl-names = "default";
pinctrl-0 = <&sleep0>;
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [PATCHv8 1/9] devfreq: event: Add new devfreq_event class to provide basic data for devfreq governor
>
> Dear Myungjoo,
>
>On 01/20/2015 01:34 PM, MyungJoo Ham wrote:
>>>
[]
>>> +
>>> + mutex_lock(&edev->lock);
>>> + if (edev->desc->ops && edev->desc->ops->enable) {
>>> + ret = edev->desc->ops->enable(edev);
>>> + if (ret < 0)
>>> + goto err;
>>> + }
>>
>> Is there any reason to call enable(edev) even when enable_count is already >
>> 0
>> while you do not call disable(edev) while enable_count > 0?
>>
>> I think this may incur errors in the related device drivers.
>> (e.g., incorrect pairing of clk/runtime-pm/regulator enable/disable
>> at the device driver side)
>
>You're right. This part has potential errors. I'll fix it as following:
>If edev is already enabled, devfreq_event_enable_edev() will just return
>without any operation because devfreq-event(edev) can handle only one event
>at the same time.
>
> mutex_lock(&edev->lock);
> if (edev->enable_count)
> dev_warn(&edev->dev, "%s is already enabled\n",
> edev->desc->name);
> ret = -EINVAL;
> goto err;
> }
>
> if (edev->desc->ops && edev->desc->ops->enable) {
> ret = edev->desc->ops->enable(edev);
> if (ret < 0)
> goto err;
> }
> edev->enable_count++;
No, your suggested modification creates another bug.
It should not emit "warn" when enable_count > 0 at enable().
It is a natural behavior from drivers.
- You may have multiple drivers using edev.
- You may have multiple threads using edev.
Thus, the above 12 lines should be replaced with:
if (edev->desc->ops && edev->desc->ops->enable &&
edev->enable_count == 0) {
ret = edev->desc->ops->enable(edev);
if (ret < 0)
goto err;
}
edev->enable_count++;
>
>
>>
>>> + edev->enable_count++;
>>> +err:
>>> + mutex_unlock(&edev->lock);
>>> +
>>> + return ret;
>>> +}
>>> +EXPORT_SYMBOL_GPL(devfreq_event_enable_edev);
>>> +
>>> +/**
>>> + * devfreq_event_disable_edev() - Disable the devfreq-event dev and
>>> decrease
>>> + * the enable_count of the devfreq-event dev.
>>> + * @edev : the devfreq-event device
>>> + *
>>> + * Note that this function decrease the enable_count and disable the
>>> + * devfreq-event device. After the devfreq-event device is disabled,
>>> + * devfreq device can't use the devfreq-event device for get/set/reset
>>> + * operations.
>>> + */
>>> +int devfreq_event_disable_edev(struct devfreq_event_dev *edev)
>>> +{
>>> + int ret = 0;
>>> +
>>> + if (!edev || !edev->desc)
>>> + return -EINVAL;
>>> +
>>> + mutex_lock(&edev->lock);
>>> + if (edev->enable_count > 0) {
>>> + edev->enable_count--;
>>> + } else {
>>> + dev_warn(&edev->dev, "unbalanced enable_count\n");
>>> + ret = -EINVAL;
>>> + goto err;
>>> + }
>>> +
>>> + if (edev->desc->ops && edev->desc->ops->disable) {
>>> + ret = edev->desc->ops->disable(edev);
>>> + if (ret < 0) {
>>> + edev->enable_count++;
>>> + goto err;
>>> + }
Anyway, have you seen other subsystems doing fall-back operations as you've
done by "edev->enable_count++" here? Or is this your own idea on falling back
from errors with a disable callback?
>>> + }
>>
>> You did it correctly with disable here;
>> not calling it when it is not required.
Uh..yeah.. the original patch was incorrect..
>
>As I explained, I'll fix it as following:
>
> mutex_lock(&edev->lock);
> if (!edev->enable_count) {
> dev_warn(&edev->dev, "%s is already disabled\n",
> edev->desc->name);
> ret = -EINVAL;
> goto err;
> }
>
> if (edev->desc->ops && edev->desc->ops->disable) {
> ret = edev->desc->ops->disable(edev);
> if (ret < 0)
> goto err;
> }
> edev->enable_count--;
Uh I'd say it is still incorrect.
mutex_lock(&edev->lock);
if (!edev->enable_count) {
dev_warn(&edev->dev, "%s is already disabled\n",
edev->desc->name);
ret = -EINVAL;
goto err;
}
edev->enable_count--;
if (edev->desc->ops && edev->desc->ops->disable &&
!edev->enable_count) {
ret = edev->desc->ops->disable(edev);
if (ret < 0)
goto err;
}
>
>>
>>> +err:
>>> + mutex_unlock(&edev->lock);
>>> +
>>> + return ret;
>>> +}
>>> +EXPORT_SYMBOL_GPL(devfreq_event_disable_edev);
>>> +
>>
>> []
>>> +EXPORT_SYMBOL_GPL(devfreq_event_is_enabled);
>> []
>>
>>> +EXPORT_SYMBOL_GPL(devfreq_event_set_event);
>> []
>>
[]
>>> +int devfreq_event_reset_event(struct devfreq_event_dev *edev)
>>> +{
>>> + int ret = 0;
>>> +
>>> + if (!edev || !edev->desc)
>>> +
[PATCH] video: treat signal like timeout as failure
if(!wait_for_completion_interruptible_timeout(...))
only handles the timeout case - this patch adds handling the
signal case the same as timeout and cleans up.
Signed-off-by: Nicholas Mc Guire
---
Only the timeout case was being handled, return of 0 in
wait_for_completion_interruptible_timeout, the signal case (-ERESTARTSYS)
was treated just like the case of successful completion, which is most
likely not reasonable.
Note that exynos_mipi_dsi_wr_data/exynos_mipi_dsi_rd_data return values
are not checked at the call sites in s6e8ax0.c (cmd_read/cmd_write)!
This patch simply treats the signal case the same way as the timeout case,
by releasing locks and returning 0 - which might not be the right thing to
do - this needs a review by someone knowing the details of this driver.
Patch is against 3.19.0-rc5 -next-20150119
Patch was only compile-tested with exynos_defconfig
drivers/video/fbdev/exynos/exynos_mipi_dsi_common.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/exynos/exynos_mipi_dsi_common.c
b/drivers/video/fbdev/exynos/exynos_mipi_dsi_common.c
index 2358a2f..55a7a45 100644
--- a/drivers/video/fbdev/exynos/exynos_mipi_dsi_common.c
+++ b/drivers/video/fbdev/exynos/exynos_mipi_dsi_common.c
@@ -157,6 +157,7 @@ int exynos_mipi_dsi_wr_data(struct mipi_dsim_device *dsim,
unsigned int data_id,
const unsigned char *data0, unsigned int data_size)
{
unsigned int check_rx_ack = 0;
+ long timeout;
if (dsim->state == DSIM_STATE_ULPS) {
dev_err(dsim->dev, "state is ULPS.\n");
@@ -244,9 +245,11 @@ int exynos_mipi_dsi_wr_data(struct mipi_dsim_device *dsim,
unsigned int data_id,
exynos_mipi_dsi_wr_tx_header(dsim, data_id, data_size & 0xff,
(data_size & 0xff00) >> 8);
- if (!wait_for_completion_interruptible_timeout(&dsim_wr_comp,
- MIPI_FIFO_TIMEOUT)) {
- dev_warn(dsim->dev, "command write timeout.\n");
+ timeout = wait_for_completion_interruptible_timeout(
+ &dsim_wr_comp, MIPI_FIFO_TIMEOUT);
+ if (timeout <= 0) {
+ dev_warn(dsim->dev,
+ "command write timed-out/interrupted.\n");
mutex_unlock(&dsim->lock);
return -EAGAIN;
}
@@ -345,6 +348,7 @@ int exynos_mipi_dsi_rd_data(struct mipi_dsim_device *dsim,
unsigned int data_id,
unsigned int rx_data, rcv_pkt, i;
u8 response = 0;
u16 rxsize;
+ long timeout;
if (dsim->state == DSIM_STATE_ULPS) {
dev_err(dsim->dev, "state is ULPS.\n");
@@ -380,9 +384,10 @@ int exynos_mipi_dsi_rd_data(struct mipi_dsim_device *dsim,
unsigned int data_id,
return -EINVAL;
}
- if (!wait_for_completion_interruptible_timeout(&dsim_rd_comp,
- MIPI_FIFO_TIMEOUT)) {
- pr_err("RX done interrupt timeout\n");
+ timeout = wait_for_completion_interruptible_timeout(&dsim_rd_comp,
+ MIPI_FIFO_TIMEOUT);
+ if (timeout <= 0) {
+ pr_err("RX done interrupt timeout/interrupted\n");
mutex_unlock(&dsim->lock);
return 0;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv8 1/9] devfreq: event: Add new devfreq_event class to provide basic data for devfreq governor
Dear Myungjoo,
On 01/20/2015 01:34 PM, MyungJoo Ham 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
>> Cc: Kyungmin Park
>> Signed-off-by: Chanwoo Choi
>> ---
>
> []
>
>> +/**
>> + * devfreq_event_enable_edev() - Enable the devfreq-event dev and increase
>> + * the enable_count of devfreq-event dev.
>> + * @edev: the devfreq-event device
>> + *
>> + * Note that this function increase the enable_count and enable the
>> + * devfreq-event device. The devfreq-event device should be enabled before
>> + * using it by devfreq device.
>> + */
>> +int devfreq_event_enable_edev(struct devfreq_event_dev *edev)
>> +{
>> +int ret = 0;
>> +
>> +if (!edev || !edev->desc)
>> +return -EINVAL;
>> +
>> +mutex_lock(&edev->lock);
>> +if (edev->desc->ops && edev->desc->ops->enable) {
>> +ret = edev->desc->ops->enable(edev);
>> +if (ret < 0)
>> +goto err;
>> +}
>
> Is there any reason to call enable(edev) even when enable_count is already >
> 0
> while you do not call disable(edev) while enable_count > 0?
>
> I think this may incur errors in the related device drivers.
> (e.g., incorrect pairing of clk/runtime-pm/regulator enable/disable
> at the device driver side)
You're right. This part has potential errors. I'll fix it as following:
If edev is already enabled, devfreq_event_enable_edev() will just return
without any operation because devfreq-event(edev) can handle only one event
at the same time.
mutex_lock(&edev->lock);
if (edev->enable_count)
dev_warn(&edev->dev, "%s is already enabled\n",
edev->desc->name);
ret = -EINVAL;
goto err;
}
if (edev->desc->ops && edev->desc->ops->enable) {
ret = edev->desc->ops->enable(edev);
if (ret < 0)
goto err;
}
edev->enable_count++;
>
>> +edev->enable_count++;
>> +err:
>> +mutex_unlock(&edev->lock);
>> +
>> +return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(devfreq_event_enable_edev);
>> +
>> +/**
>> + * devfreq_event_disable_edev() - Disable the devfreq-event dev and decrease
>> + *the enable_count of the devfreq-event dev.
>> + * @edev: the devfreq-event device
>> + *
>> + * Note that this function decrease the enable_count and disable the
>> + * devfreq-event device. After the devfreq-event device is disabled,
>> + * devfreq device can't use the devfreq-event device for get/set/reset
>> + * operations.
>> + */
>> +int devfreq_event_disable_edev(struct devfreq_event_dev *edev)
>> +{
>> +int ret = 0;
>> +
>> +if (!edev || !edev->desc)
>> +return -EINVAL;
>> +
>> +mutex_lock(&edev->lock);
>> +if (edev->enable_count > 0) {
>> +edev->enable_count--;
>> +} else {
>> +dev_warn(&edev->dev, "unbalanced enable_count\n");
>> +ret = -EINVAL;
>> +goto err;
Re: [PATCHv8 2/9] devfreq: event: Add resource-managed function for devfreq-event device
On 01/20/2015 01:46 PM, MyungJoo Ham wrote: >> >> This patch add the resource-managed function for devfreq-event device as >> following functions. The devm_devfreq_event_add_edev() manages automatically >> the memory of devfreq-event device using resource management. >> - devm_devfreq_event_add_edev() >> - devm_devfreq_event_remove_edev() >> >> Cc: Myungjoo Ham >> Cc: Kyungmin Park >> Signed-off-by: Chanwoo Choi > Reviewed-by: MyungJoo Ham > > You may merge this patch with 1/9 as well. > I don't think this is a major change the requires a seperated patch. OK. I'll merge it. on patch1. 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: [PATCHv8 2/9] devfreq: event: Add resource-managed function for devfreq-event device
>
> This patch add the resource-managed function for devfreq-event device as
> following functions. The devm_devfreq_event_add_edev() manages automatically
> the memory of devfreq-event device using resource management.
> - devm_devfreq_event_add_edev()
> - devm_devfreq_event_remove_edev()
>
> Cc: Myungjoo Ham
> Cc: Kyungmin Park
> Signed-off-by: Chanwoo Choi
You may merge this patch with 1/9 as well.
I don't think this is a major change the requires a seperated patch.
Cheers,
MyungJoo
N�r��yb�X��ǧv�^�){.n�+{�x,�ȧ���ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf
Re: [PATCHv8 1/9] devfreq: event: Add new devfreq_event class to provide basic data for devfreq governor
>
> 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
> Cc: Kyungmin Park
> Signed-off-by: Chanwoo Choi
> ---
[]
> +/**
> + * devfreq_event_enable_edev() - Enable the devfreq-event dev and increase
> + *the enable_count of devfreq-event dev.
> + * @edev : the devfreq-event device
> + *
> + * Note that this function increase the enable_count and enable the
> + * devfreq-event device. The devfreq-event device should be enabled before
> + * using it by devfreq device.
> + */
> +int devfreq_event_enable_edev(struct devfreq_event_dev *edev)
> +{
> + int ret = 0;
> +
> + if (!edev || !edev->desc)
> + return -EINVAL;
> +
> + mutex_lock(&edev->lock);
> + if (edev->desc->ops && edev->desc->ops->enable) {
> + ret = edev->desc->ops->enable(edev);
> + if (ret < 0)
> + goto err;
> + }
Is there any reason to call enable(edev) even when enable_count is already > 0
while you do not call disable(edev) while enable_count > 0?
I think this may incur errors in the related device drivers.
(e.g., incorrect pairing of clk/runtime-pm/regulator enable/disable
at the device driver side)
> + edev->enable_count++;
> +err:
> + mutex_unlock(&edev->lock);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(devfreq_event_enable_edev);
> +
> +/**
> + * devfreq_event_disable_edev() - Disable the devfreq-event dev and decrease
> + * the enable_count of the devfreq-event dev.
> + * @edev : the devfreq-event device
> + *
> + * Note that this function decrease the enable_count and disable the
> + * devfreq-event device. After the devfreq-event device is disabled,
> + * devfreq device can't use the devfreq-event device for get/set/reset
> + * operations.
> + */
> +int devfreq_event_disable_edev(struct devfreq_event_dev *edev)
> +{
> + int ret = 0;
> +
> + if (!edev || !edev->desc)
> + return -EINVAL;
> +
> + mutex_lock(&edev->lock);
> + if (edev->enable_count > 0) {
> + edev->enable_count--;
> + } else {
> + dev_warn(&edev->dev, "unbalanced enable_count\n");
> + ret = -EINVAL;
> + goto err;
> + }
> +
> + if (edev->desc->ops && edev->desc->ops->disable) {
> + ret = edev->desc->ops->disable(edev);
> + if (ret < 0) {
> + edev->enable_count++;
> + goto err;
> + }
> + }
You did it correctly with disable here;
not calling it when it is not required.
> +err:
> + mutex_unlock(&edev->lock);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(devfreq_event_disable_edev);
> +
[]
> +EXPORT_SYMBOL_GPL(devfreq_event_is_enabled);
[]
> +EXPORT_SYMBOL_GPL(devfreq_event_set_event);
[]
> +
> +/**
> + * devfreq_event_get_event() - Get event and total_event from devfreq-event
> dev.
> + * @edev : the devfreq-event device
> + * @edata: the calculated data of devfreq-event device
> + *
> + * Note that this function get the calculated event data from dev
Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms
Marek Szyprowski wrote: > Please check the following kernel tree - instead of hacking around hdmi > clock I've added > handling of it directly to drm mixer driver: > https://git.linaro.org/people/marek.szyprowski/linux-srpol.git/shortlog/refs/heads/v3.19-odroid-hdmi > > I hope that this will finally solve all mixer initialization related > issues (also for > Odroid XU3, discussed recently in the other thread). If it works fine, I > will resend > exynos4 hdmi patches to include this change. OK, I can verify that with the additional patches the lockup issues no longer occur. When doing the vsync tests though there are still the drm_vblank_put warnings. I have yet to check if patch by Joonyoung (thanks Joonyoung for the hint!) fixes these warnings. With best wishes, Tobias -- 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 00/16] thermal: exynos: Thermal code rework to use device tree
Hello! Lukasz Majewski wrote: > We all know that this code is floating around - early version of this > work was posted in the Q3 2013. > > To be fair - this code is both needed and welcome, but new problems > with it are found (please search for recent comment from Kevin > Hilman). > > From my side, I focus on the code which is in Eduardo Valentin's next > (3.19-rc3), since I don't know when and if eventually cpufreq rework > would be merged. I'm sorry, my wording wasn't the best here. I'm not critizing the work done here, merely voicing my concern (and also interest!) about how the new stuff interacts with code that may eventually get merged. You're aware of it, that's enough for me to know. > The code which touches exynos-cpufreq.c is around 30 LOC, only for > preserving cpu cooling functionality. > > Is it worth to wait for code developed for so long to happily apply 30 > LOC and delay removal of around 400 LOC in other subsystem (thermal)? No, of course not. That was pretty stupid of me :( > I rise my hand as a volunteer to fix any thermal related issues which > show up after cpufreq rework code applying to Exynos. That's certainly good to hear! > This series is NOT providing any NEW functionality. It in fact > preserves functionality, which allows using CPU frequency as a mean to > cool the device. I've got a question concerning this. Is this only needed for exynos-cpufreq, or does cpufreq-dt also need something like that. The point is that I'm still working with a rather old version of the cpufreq series, a version which still had the Exynos4x12 code in it (this was removed later, if I remember correctly because of problems with how to properly describe boost configuration in DT). Anyway, to not get completly off-topic here, I noticed some small issue with v3 of the thermal series. I've enabled CONFIG_THERMAL_HWMON so that I can use lm_sensors to query temperature of the board. However while the thermal_zone is created, there is no hwmon node to be found. This was working properly without the thermal series. With best wishes, Tobias -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms
Hello!
Marek Szyprowski wrote:
> Thanks for you tests and pointing this issue. I turned out that the
> initial fix proposed
> by Andrzej Hajda
> (http://www.spinics.net/lists/linux-samsung-soc/msg38915.html) worked
> fine, while the final version merged to clock fixes ('clk: samsung:
> exynos4: set parent
> of sclk_hdmiphy to hdmi' - commit
> df019a5c0f7083001cb694f44821ca506425bda2) doesn't work
> properly.
I should thank you for pushing all this code to mainline. It's really
nice to see how all the pieces now come together.
> Please check the following kernel tree - instead of hacking around hdmi
> clock I've added
> handling of it directly to drm mixer driver:
> https://git.linaro.org/people/marek.szyprowski/linux-srpol.git/shortlog/refs/heads/v3.19-odroid-hdmi
>
> I hope that this will finally solve all mixer initialization related
> issues (also for
> Odroid XU3, discussed recently in the other thread). If it works fine, I
> will resend
> exynos4 hdmi patches to include this change.
I have picked the additional patches to my tree, which currently has a
bunch of other stuff in it, in particular v4 of the IOMMU series.
Anyway, now the 'modetest' application immediately crashes the system,
but I get a least something on the serial console:
http://www.math.uni-bielefeld.de/~tjakobi/archive/odroid_modetest_crash_sysmmu.txt
So this is probably due to the IOMMU. Please note that DRM IOMMU support
(CONFIG_DRM_EXYNOS_IOMMU) was disabled (!) in my config.
CONFIG_EXYNOS_IOMMU however was on.
I'm going to retest with the IOMMU series removed and
CONFIG_EXYNOS_IOMMU disabled as well.
Just posting this already since you're probably interested in these
'side-issues' as well.
With best wishes,
Tobias
--
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 2/3] regmap: Use the enhancement of i2c API to address circular dependency problem
On Mon, Jan 19, 2015 at 10:31:22AM +0100, Paul Osmialowski wrote: > On Fri, 16 Jan 2015, Mark Brown wrote: > >What I'm saying is that I want to understand this change from a point of > >view that isn't tied to I2C - at the regmap level what is this doing, > From the regmap point of view, it allows its functions to have a chance to > prepare transfer medium for (synchronous) transfer (no matter what bus > handles it) before it actually start to happen (then unprepare it when it's > done) and crucially before any lock is obtained in functions like > regmap_write(), regmap_read() or regmap_update_bits. OK, so that's what should go in the changelog (along with an explanation of why this preparation is required at all) - but I still don't see the async bit of this I'm afraid. > Maybe adding a pair of callbacks (map->reg_write_sync_prepared(), > map->reg_read_sync_prepared()) would make situation clearer. No, I don't think so - it'd just complicate the callers. > >I2C is a bus that has some properties which you're saying needs some > >changes, what are those properties and those changes? > I'm not saying I2C as a bus requires changes. What I'm saying is that I2C > API can be extended to allow more detailed control on what happens with the > transfer. My point here is that your explanation is in terms of I2C specifics and not really at a generic regmap level. > >Can you be more specific please? If something needs preparing it seems > >like it'd need preparing over an async transaction just as much as over > >a synchronous one. > Even with those preparation and unpreparation stages, this transfer is still > synchronous. For example, it starts when regmap_read() starts and ends when > regmap_read() ends. Nothing is queued or deferred. Namely, when > max_gen_clk_unprepare() function calls regmap_update_bits() it expects that > when regmap_update_bits() returned, no outstanding transfer are happening > nor waiting to proceed. Everything must be completed before returning to > max_gen_clk_unprepare(). That doesn't address my question - all you're saying is that in a synchronous call path things are synchronous which is fine but obviously regmap supports async I/O too. > >Not in this pattern where the caller needs to check too. > I don't persist on that. Apparently, you're the author of this file, though > regmap_init() function was later expanded by other guys. They never assigned > bus callback function pointers directly to map operation callbacks. It is > possible to replace 'map->reg_prepare_sync_io = regmap_bus_prepare_sync_io' > with 'map->reg_prepare_sync_io = map->bus->prepare_sync_io' - this will > compile and this will work properly. But IMHO it wouldn't match with what > the others did. If you look at the other callbacks they're doing other things beyond simply forwarding the functions on. That's the problem here, the functions just add a layer of indirection and nothing else. signature.asc Description: Digital signature
Re: [PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support
On Mon, 2015-01-19 at 15:01 -0200, Gustavo Padovan wrote: > 2015-01-19 Thierry Reding : > > > On Mon, Jan 19, 2015 at 11:27:52AM +0100, Javier Martinez Canillas wrote: > > > Hello Thierry, > > > > > > On 01/05/2015 02:50 PM, Thierry Reding wrote: > > > > On Fri, Jan 02, 2015 at 01:10:14PM +, Daniel Stone wrote: > > > >> > > > > >> > Ajay's series don't apply cleanly anymore because it has been a > > > >> > while since > > > >> > he posted it but he can rebase on top of 3.19-rc1 once it is > > > >> > released and > > > >> > re-resend. > > > >> > > > > >> > > > >> Do you have any plans to rebase this so it's ready for merging? > > > >> > > > >> Thierry, Daniel, Dave - whose tree would this be best to merge through? > > > > > > > > The plan is for me to take the bridge patches through the drm/panel > > > > tree. I'm going to look at these patches again later this week but from > > > > a very quick peek there don't seem to be any major issues left. > > > > > > > > > > I know you probably are very busy but it would be great if you can take a > > > look > > > to this series to avoid another kernel release to be missed since we are > > > already > > > at v3.19-rc5. > > > > > > Only this version was posted 2 months ago and the first version of the > > > series > > > was sent on May, 2014 so it has been on the list for almost a year now... > > > > > > Tomi and Laurent had already agreed with the DT binging so I think that > > > we can > > > already merge these and if there are any remaining issues, those can be > > > fixed > > > during the 3.20 -rc cycle. > > > > I see only a single Tested-by on this series and that seems to be with a > > bunch of out-of-tree patches applied on top. Does this now actually work > > applied on top of upstream? Also it seems like many people actually want > > this to get merged but there's been no Reviewed-bys and only a single > > Tested-by? Is that as good as it's going to get? > > I've been using this series on top of exynos-drm for more than a month and it > works fine for me so.. > > Tested-by: Gustavo Padovan Same here, just test-booted on my snow with just these patch on top of 3.19-rc5 and got a nicely working display. Tested-by: Sjoerd Simons -- Sjoerd Simons Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH v3 7/7] ARM: dts: exynos5250: add display power domain
Hello Marek and Andrzej, On Wed, Jan 14, 2015 at 2:44 PM, Marek Szyprowski wrote: > From: Andrzej Hajda > > The patch adds domain definition and references to it in appropriate devices. > > Signed-off-by: Andrzej Hajda > [mszyprow: rebased onto generic power domains dt bindings] > Signed-off-by: Marek Szyprowski > --- > arch/arm/boot/dts/exynos5250.dtsi | 10 ++ > 1 file changed, 10 insertions(+) This patch makes HDMI to work on my Exynos5250 Snow Chromebook: Tested-by: Javier Martinez Canillas Reviewed-by: Javier Martinez Canillas 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
Re: [PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support
Hello Thierry, On 01/19/2015 05:30 PM, Thierry Reding wrote: >> >> I know you probably are very busy but it would be great if you can take a >> look >> to this series to avoid another kernel release to be missed since we are >> already >> at v3.19-rc5. >> >> Only this version was posted 2 months ago and the first version of the series >> was sent on May, 2014 so it has been on the list for almost a year now... >> >> Tomi and Laurent had already agreed with the DT binging so I think that we >> can >> already merge these and if there are any remaining issues, those can be fixed >> during the 3.20 -rc cycle. > > I see only a single Tested-by on this series and that seems to be with a > bunch of out-of-tree patches applied on top. Does this now actually work > applied on top of upstream? Also it seems like many people actually want > this to get merged but there's been no Reviewed-bys and only a single > Tested-by? Is that as good as it's going to get? > Good point, I provided some feedback on an early version of the series but I'm not an DRM expert so I couldn't review it in detail to provide my Reviewed-by. I did provide my Tested-by a long time ago though but looking at the patches it seems those were dropped so here goes again: For the whole series on an Exynos5420 Peach Pit and an Exynos5250 Snow Chromebooks: Tested-by: Javier Martinez Canillas > Also I think the last update was that Ajay was going to resend this > based on v3.19-rc1 or something. Is that still going to happen? > Otherwise I can probably try to apply as-is, but not sure how well it > will. > Ajay, Are you going to rebase and resend this series with all the provided tags? Gustavo and I have a rebased branch on top of 3.19-rc5 and one of us can post your series if you are not planning to do it. Laurent and Tomi, You said that you are OK with the DT bindings now, does that count as an Acked-by or Reviewed-by for you at least for the DT bindings changes in the series? > Thierry > 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
Re: [PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support
2015-01-19 Thierry Reding : > On Mon, Jan 19, 2015 at 11:27:52AM +0100, Javier Martinez Canillas wrote: > > Hello Thierry, > > > > On 01/05/2015 02:50 PM, Thierry Reding wrote: > > > On Fri, Jan 02, 2015 at 01:10:14PM +, Daniel Stone wrote: > > >> > > > >> > Ajay's series don't apply cleanly anymore because it has been a while > > >> > since > > >> > he posted it but he can rebase on top of 3.19-rc1 once it is released > > >> > and > > >> > re-resend. > > >> > > > >> > > >> Do you have any plans to rebase this so it's ready for merging? > > >> > > >> Thierry, Daniel, Dave - whose tree would this be best to merge through? > > > > > > The plan is for me to take the bridge patches through the drm/panel > > > tree. I'm going to look at these patches again later this week but from > > > a very quick peek there don't seem to be any major issues left. > > > > > > > I know you probably are very busy but it would be great if you can take a > > look > > to this series to avoid another kernel release to be missed since we are > > already > > at v3.19-rc5. > > > > Only this version was posted 2 months ago and the first version of the > > series > > was sent on May, 2014 so it has been on the list for almost a year now... > > > > Tomi and Laurent had already agreed with the DT binging so I think that we > > can > > already merge these and if there are any remaining issues, those can be > > fixed > > during the 3.20 -rc cycle. > > I see only a single Tested-by on this series and that seems to be with a > bunch of out-of-tree patches applied on top. Does this now actually work > applied on top of upstream? Also it seems like many people actually want > this to get merged but there's been no Reviewed-bys and only a single > Tested-by? Is that as good as it's going to get? I've been using this series on top of exynos-drm for more than a month and it works fine for me so.. Tested-by: Gustavo Padovan Gustavo -- 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] thermal: exynos: Add TMU support for Exynos7 SoC
Hi Lukasz, On Mon, Jan 19, 2015 at 6:34 PM, Lukasz Majewski wrote: > Hi Abhilash, > >> Add registers, bit fields and compatible strings for Exynos7 TMU >> (Thermal Management Unit). Following are a few of the differences >> in the Exynos7 TMU from earlier SoCs: >> - 8 trigger levels >> - Different bit offsets and more registers for the rising >> and falling thresholds. >> - New power down detection bit in the TMU_CONTROL register >> which does not update the CURRENT_TEMP0 when tmu power down >> is detected. >> - Change in bit offset for the NEXT_DATA field of EMUL_CON >> register. EMUL_CON register address has also changed. >> - INTSTAT and INTCLEAR registers present in earlier SoCs >> have been combined into one INTPEND register. The register >> address for INTCLEAR and INTPEND is also different. >> - Since there are 8 rising/falling interrupts as against >> at most 4 in earlier SoCs the INTEN bit offsets are different. >> - Multiple probe support which is handled by a TMU_CONTROL1 >> register (No support for this in the current patch). >> >> This patch adds special clock support required only for Exynos7 >> and updates the bindings documentation appropriately. It also updates >> the "code_to_temp" prototype as Exynos7 has 9 bit code-temp mapping. >> >> Signed-off-by: Abhilash Kesavan >> --- >> This patch is based on Lukasz Majewski's Exynos TMU v4 patchset: >> http://www.spinics.net/lists/linux-samsung-soc/msg41183.html >> >> Changes since v2: >> - Rebased on top of Lukasz' latest exynos tmu series (v4). >> - Added new exynos7 soc_type. >> Changes since v1: >> - Rebased on top of Lukasz' latest exynos tmu series (v2). >> - Added sclk support to patch adding Exynos7 tmu support. >> Previously, it was a separate patch. >> - Used the SOC type to decide if sclk is present. >> >> .../devicetree/bindings/thermal/exynos-thermal.txt |4 + >> drivers/thermal/samsung/exynos_tmu.c | 203 >> +++- >> drivers/thermal/samsung/exynos_tmu.h |1 + 3 files >> changed, 199 insertions(+), 9 deletions(-) >> >> diff --git >> a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt >> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt index >> 0f44932..695150a 100644 --- >> a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt +++ >> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt @@ >> -12,6 +12,7 @@ "samsung,exynos5420-tmu-ext-triminfo" for TMU channels >> 2, 3 and 4 Exynos5420 (Must pass triminfo base and triminfo clock) >> "samsung,exynos5440-tmu" >> +"samsung,exynos7-tmu" >> - interrupt-parent : The phandle for the interrupt controller >> - reg : Address range of the thermal registers. For soc's which has >> multiple instances of TMU and some registers are shared across all >> TMU's like @@ -32,10 +33,13 @@ >> - clocks : The main clocks for TMU device >> -- 1. operational clock for TMU channel >> -- 2. optional clock to access the shared registers of TMU >> channel >> + -- 3. optional special clock for functional operation >> - clock-names : Thermal system clock name >> -- "tmu_apbif" operational clock for current TMU channel >> -- "tmu_triminfo_apbif" clock to access the shared triminfo >> register for current TMU channel >> + -- "tmu_sclk" clock for functional operation of the current >> TMU >> + channel >> - vtmu-supply: This entry is optional and provides the regulator >> node supplying voltage to TMU. If needed this entry can be placed >> inside board/platform specific dts file. > > I would recommend splitting the documentation from the code. IMHO it > would be more readable. I will split the documentation out into a separate patch. > >> diff --git a/drivers/thermal/samsung/exynos_tmu.c >> b/drivers/thermal/samsung/exynos_tmu.c index 633a9e2..8b26acb 100644 >> --- a/drivers/thermal/samsung/exynos_tmu.c >> +++ b/drivers/thermal/samsung/exynos_tmu.c >> @@ -119,6 +119,26 @@ >> #define EXYNOS5440_TMU_TH_RISE4_SHIFT24 >> #define EXYNOS5440_EFUSE_SWAP_OFFSET 8 >> >> +/* Exynos7 specific registers */ >> +#define EXYNOS7_THD_TEMP_RISE7_6 0x50 >> +#define EXYNOS7_THD_TEMP_FALL7_6 0x60 >> +#define EXYNOS7_TMU_REG_INTEN0x110 >> +#define EXYNOS7_TMU_REG_INTPEND 0x118 > ^ I suppose that > this misalignment is > only done by my mail > client and checkpatch > is not complaining. I re-ran checkpatch and it did not report any warnings, so perhaps it is your e-mail client. >> +#define EXYNOS
Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms
Hello,
On 2015-01-16 23:32, Tobias Jakobi wrote:
Hello,
so OK, this doesn't look too good.
Tobias Jakobi wrote:
I checked with my panel just now and played around a bit with the DRM
(opening, vsync, etc.). However on deinitialization the entire system
locked up. I currently haven't hooked the board up to the serial
console, otherwise I would've tried to extract some more meaningful
information.
Going to check again more thoroughly on the weekend what exactly
triggers the lockup.
So, first of all I did my initial test with the exynos video backend of
RetroArch. But it turns out that there's no fancy application needed. I
now tested this with the 'modetest' application from libdrm, and did this:
./modetest -M exynos -s 16@13:1920x1080
setting mode 1920x1080-60Hz@XR24 on connectors 16, crtc 13
^C
./modetest -M exynos -s 16@13:640x480
setting mode 640x480-60Hz@XR24 on connectors 16, crtc 13
^C
./modetest -M exynos -s 16@13:640x480
setting mode 640x480-60Hz@XR24 on connectors 16, crtc 13
^C
./modetest -M exynos -s 16@13:640x480
The board instantly died then. No kernel log output from the serial
console, the heartbeat just stops and the board is dead. Need to
power-cycle to get it running again.
I'm unsure how to triage this at all.
Thanks for you tests and pointing this issue. I turned out that the
initial fix proposed
by Andrzej Hajda
(http://www.spinics.net/lists/linux-samsung-soc/msg38915.html) worked
fine, while the final version merged to clock fixes ('clk: samsung:
exynos4: set parent
of sclk_hdmiphy to hdmi' - commit
df019a5c0f7083001cb694f44821ca506425bda2) doesn't work
properly.
Please check the following kernel tree - instead of hacking around hdmi
clock I've added
handling of it directly to drm mixer driver:
https://git.linaro.org/people/marek.szyprowski/linux-srpol.git/shortlog/refs/heads/v3.19-odroid-hdmi
I hope that this will finally solve all mixer initialization related
issues (also for
Odroid XU3, discussed recently in the other thread). If it works fine, I
will resend
exynos4 hdmi patches to include this change.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support
On Mon, Jan 19, 2015 at 11:27:52AM +0100, Javier Martinez Canillas wrote: > Hello Thierry, > > On 01/05/2015 02:50 PM, Thierry Reding wrote: > > On Fri, Jan 02, 2015 at 01:10:14PM +, Daniel Stone wrote: > >> > > >> > Ajay's series don't apply cleanly anymore because it has been a while > >> > since > >> > he posted it but he can rebase on top of 3.19-rc1 once it is released and > >> > re-resend. > >> > > >> > >> Do you have any plans to rebase this so it's ready for merging? > >> > >> Thierry, Daniel, Dave - whose tree would this be best to merge through? > > > > The plan is for me to take the bridge patches through the drm/panel > > tree. I'm going to look at these patches again later this week but from > > a very quick peek there don't seem to be any major issues left. > > > > I know you probably are very busy but it would be great if you can take a look > to this series to avoid another kernel release to be missed since we are > already > at v3.19-rc5. > > Only this version was posted 2 months ago and the first version of the series > was sent on May, 2014 so it has been on the list for almost a year now... > > Tomi and Laurent had already agreed with the DT binging so I think that we can > already merge these and if there are any remaining issues, those can be fixed > during the 3.20 -rc cycle. I see only a single Tested-by on this series and that seems to be with a bunch of out-of-tree patches applied on top. Does this now actually work applied on top of upstream? Also it seems like many people actually want this to get merged but there's been no Reviewed-bys and only a single Tested-by? Is that as good as it's going to get? Also I think the last update was that Ajay was going to resend this based on v3.19-rc1 or something. Is that still going to happen? Otherwise I can probably try to apply as-is, but not sure how well it will. Thierry pgpDHQpUnOVrn.pgp Description: PGP signature
[PATCH] i2c: s3c2410: fix ABBA deadlock by keeping clock prepared
This patch solves deadlock between clock prepare mutex and regmap mutex reported
by Tomasz Figa in [1] by implementing solution from [2]: "always leave the clock
of the i2c controller in a prepared state".
[1] https://lkml.org/lkml/2014/7/2/171
[2] https://lkml.org/lkml/2014/7/2/207
On each i2c transfer handled by s3c24xx_i2c_xfer(), clk_prepare_enable() was
called, which calls clk_prepare() then clk_enable(). clk_prepare() takes
prepare_lock mutex before proceeding. Note that i2c transfer functions are
invoked from many places in kernel, typically with some other additional lock
held.
It may happen that function on CPU1 (e.g. regmap_update_bits()) has taken a
mutex (i.e. regmap lock mutex) then it attempts i2c communication in order to
proceed (so it needs to obtain clock related prepare_lock mutex during transfer
preparation stage due to clk_prepare() call). At the same time other task on
CPU0 wants to operate on clock (e.g. to (un)prepare clock for some other reason)
so it has taken prepare_lock mutex.
CPU0:CPU1:
clk_disable_unused() regulator_disable()
clk_prepare_lock() map->lock(map->lock_arg)
regmap_read()s3c24xx_i2c_xfer()
map->lock(map->lock_arg) clk_prepare_lock()
Implemented solution from [2] leaves i2c clock prepared. Preparation is done in
s3c24xx_i2c_probe() function. Without this patch, it is immediately unprepared
by clk_disable_unprepare() call. I've replaced this call with clk_disable() and
I've added clk_unprepare() call in s3c24xx_i2c_remove().
The s3c24xx_i2c_xfer() function now uses clk_enable() instead of
clk_prepare_enable() (and clk_disable() instead of clk_unprepare_disable()).
Signed-off-by: Paul Osmialowski
---
drivers/i2c/busses/i2c-s3c2410.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index bff20a5..958c8db 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -785,14 +785,16 @@ static int s3c24xx_i2c_xfer(struct i2c_adapter *adap,
int ret;
pm_runtime_get_sync(&adap->dev);
- clk_prepare_enable(i2c->clk);
+ ret = clk_enable(i2c->clk);
+ if (ret)
+ return ret;
for (retry = 0; retry < adap->retries; retry++) {
ret = s3c24xx_i2c_doxfer(i2c, msgs, num);
if (ret != -EAGAIN) {
- clk_disable_unprepare(i2c->clk);
+ clk_disable(i2c->clk);
pm_runtime_put(&adap->dev);
return ret;
}
@@ -802,7 +804,7 @@ static int s3c24xx_i2c_xfer(struct i2c_adapter *adap,
udelay(100);
}
- clk_disable_unprepare(i2c->clk);
+ clk_disable(i2c->clk);
pm_runtime_put(&adap->dev);
return -EREMOTEIO;
}
@@ -1197,7 +1199,7 @@ static int s3c24xx_i2c_probe(struct platform_device *pdev)
clk_prepare_enable(i2c->clk);
ret = s3c24xx_i2c_init(i2c);
- clk_disable_unprepare(i2c->clk);
+ clk_disable(i2c->clk);
if (ret != 0) {
dev_err(&pdev->dev, "I2C controller init failed\n");
return ret;
@@ -1210,6 +1212,7 @@ static int s3c24xx_i2c_probe(struct platform_device *pdev)
i2c->irq = ret = platform_get_irq(pdev, 0);
if (ret <= 0) {
dev_err(&pdev->dev, "cannot find IRQ\n");
+ clk_unprepare(i2c->clk);
return ret;
}
@@ -1218,6 +1221,7 @@ static int s3c24xx_i2c_probe(struct platform_device *pdev)
if (ret != 0) {
dev_err(&pdev->dev, "cannot claim IRQ %d\n", i2c->irq);
+ clk_unprepare(i2c->clk);
return ret;
}
}
@@ -1225,6 +1229,7 @@ static int s3c24xx_i2c_probe(struct platform_device *pdev)
ret = s3c24xx_i2c_register_cpufreq(i2c);
if (ret < 0) {
dev_err(&pdev->dev, "failed to register cpufreq notifier\n");
+ clk_unprepare(i2c->clk);
return ret;
}
@@ -1241,6 +1246,7 @@ static int s3c24xx_i2c_probe(struct platform_device *pdev)
if (ret < 0) {
dev_err(&pdev->dev, "failed to add bus to i2c core\n");
s3c24xx_i2c_deregister_cpufreq(i2c);
+ clk_unprepare(i2c->clk);
return ret;
}
@@ -1262,6 +1268,8 @@ static int s3c24xx_i2c_remove(struct platform_device
*pdev)
{
struct s3c24xx_i2c *i2c = platform_get_drvdata(pdev);
+ clk_unprepare(i2c->clk);
+
pm_runtime_disable(&i2c->adap.dev);
pm_runtime_disable(&pdev->dev);
@@ -1293,13 +1301,16 @@ static int s3c24xx_i2c_resume_noirq(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct s3c24xx_i2c *i2
Re: [PATCH v4 18/18] iommu: exynos: add callback for initializing devices from device tree
Hello Marek,
I wanted to test your IOMMU series on an Exynos5420 Peach Pit but the
kernel hangs with your series + dependencies on top of 3.19-rc5.
Bisecting I found that $subject is the offending commit. I've pushed
my test branch [0] in case I missed something.
On Fri, Jan 16, 2015 at 10:13 AM, Marek Szyprowski
wrote:
> This patch adds implementation of of_xlate callback, which prepares
> masters device for attaching to IOMMU. This callback is called during
> creating devices from device tree.
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/iommu/exynos-iommu.c | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index ea2659159e63..5432b443abfc 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -1077,6 +1077,33 @@ static phys_addr_t exynos_iommu_iova_to_phys(struct
> iommu_domain *iommu_domain,
> return phys;
> }
>
> +static int exynos_iommu_of_xlate(struct device *dev,
> +struct of_phandle_args *spec)
> +{
> + struct exynos_iommu_owner *owner = dev->archdata.iommu;
> + struct platform_device *sysmmu = of_find_device_by_node(spec->np);
> + struct sysmmu_drvdata *data;
> +
> + if (!sysmmu)
> + return -ENODEV;
> +
> + data = platform_get_drvdata(sysmmu);
> + if (!data)
> + return -ENODEV;
> +
> + if (!owner) {
> + owner = kzalloc(sizeof(*owner), GFP_KERNEL);
> + if (!owner)
> + return -ENOMEM;
> +
> + INIT_LIST_HEAD(&owner->clients);
> + dev->archdata.iommu = owner;
> + }
> +
> + list_add_tail(&data->owner_node, &owner->clients);
This is the line that causes the kernel to hang, if I comment the
list_add_tail() call then the kernel boots.
I checked that neither data nor owner are NULL and that the
owner->clients list_head is initialized. Do you have any ideas what
could be happening?
Thanks a lot and best regards,
Javier
[0]: git://git.collabora.co.uk/git/user/javier/linux.git exynos-sysmmu-3.19-rc5
--
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] usb: dwc2: rework initialization of host and gadget in dual-role mode
If device is configured to work only in HOST or DEVICE mode, there is
no point in initializing both subdrivers. This patch also fixes
resource leakage if host subdriver fails to initialize.
Signed-off-by: Marek Szyprowski
---
drivers/usb/dwc2/core.h | 2 ++
drivers/usb/dwc2/platform.c | 29 +
2 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 7a70a1349334..f93b06daef97 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -570,6 +570,8 @@ struct dwc2_hsotg {
struct dwc2_core_params *core_params;
enum usb_otg_state op_state;
enum usb_dr_mode dr_mode;
+ unsigned int hcd_enabled:1;
+ unsigned int gadget_enabled:1;
struct phy *phy;
struct usb_phy *uphy;
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 6a795aa2ff05..ee0b0b06d0fc 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -121,8 +121,10 @@ static int dwc2_driver_remove(struct platform_device *dev)
{
struct dwc2_hsotg *hsotg = platform_get_drvdata(dev);
- dwc2_hcd_remove(hsotg);
- s3c_hsotg_remove(hsotg);
+ if (hsotg->hcd_enabled)
+ dwc2_hcd_remove(hsotg);
+ if (hsotg->gadget_enabled)
+ s3c_hsotg_remove(hsotg);
return 0;
}
@@ -214,12 +216,23 @@ static int dwc2_driver_probe(struct platform_device *dev)
spin_lock_init(&hsotg->lock);
mutex_init(&hsotg->init_mutex);
- retval = dwc2_gadget_init(hsotg, irq);
- if (retval)
- return retval;
- retval = dwc2_hcd_init(hsotg, irq, params);
- if (retval)
- return retval;
+
+ if (hsotg->dr_mode != USB_DR_MODE_HOST) {
+ retval = dwc2_gadget_init(hsotg, irq);
+ if (retval)
+ return retval;
+ hsotg->gadget_enabled = 1;
+ }
+
+ if (hsotg->dr_mode != USB_DR_MODE_PERIPHERAL) {
+ retval = dwc2_hcd_init(hsotg, irq, params);
+ if (retval) {
+ if (hsotg->gadget_enabled)
+ s3c_hsotg_remove(hsotg);
+ return retval;
+ }
+ hsotg->hcd_enabled = 1;
+ }
platform_set_drvdata(dev, hsotg);
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: DTS: Exynos: add 'dr_mode' property to hsotg devices
All currently supported boards use hsotg/dwc2 controller in device
('peripheral') mode, so add property which sets correct operation mode.
This patch fixes support in recent changes in dwc2 driver, which added
support for dual-role devices.
Suggested-by: Paul Zimmerman
Signed-off-by: Marek Szyprowski
---
arch/arm/boot/dts/exynos3250-monk.dts | 1 +
arch/arm/boot/dts/exynos3250-rinato.dts | 1 +
arch/arm/boot/dts/exynos4210-trats.dts | 1 +
arch/arm/boot/dts/exynos4210-universal_c210.dts | 1 +
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 1 +
arch/arm/boot/dts/exynos4412-trats2.dts | 1 +
arch/arm/boot/dts/s5pv210-aquila.dts| 1 +
arch/arm/boot/dts/s5pv210-goni.dts | 1 +
arch/arm/boot/dts/s5pv210-smdkv210.dts | 1 +
9 files changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250-monk.dts
b/arch/arm/boot/dts/exynos3250-monk.dts
index 5e4a471faee1..683596844ef3 100644
--- a/arch/arm/boot/dts/exynos3250-monk.dts
+++ b/arch/arm/boot/dts/exynos3250-monk.dts
@@ -140,6 +140,7 @@
&hsotg {
vusb_d-supply = <&ldo15_reg>;
vusb_a-supply = <&ldo12_reg>;
+ dr_mode = "peripheral";
status = "okay";
};
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index c7f4fab6dfd9..5121954579ad 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -131,6 +131,7 @@
&hsotg {
vusb_d-supply = <&ldo15_reg>;
vusb_a-supply = <&ldo12_reg>;
+ dr_mode = "peripheral";
status = "okay";
};
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/arch/arm/boot/dts/exynos4210-trats.dts
index 720836205546..1c0c7be02616 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -91,6 +91,7 @@
hsotg@1248 {
vusb_d-supply = <&vusb_reg>;
vusb_a-supply = <&vusbdac_reg>;
+ dr_mode = "peripheral";
status = "okay";
};
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index 01f7d3cfdd02..1d7643288569 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -71,6 +71,7 @@
hsotg@1248 {
vusb_d-supply = <&ldo3_reg>;
vusb_a-supply = <&ldo8_reg>;
+ dr_mode = "peripheral";
status = "okay";
};
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 4a11e84b036e..9329135342a6 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -401,6 +401,7 @@
};
hsotg@1248 {
+ dr_mode = "peripheral";
status = "okay";
vusb_d-supply = <&ldo15_reg>;
vusb_a-supply = <&ldo12_reg>;
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 29231b452643..c81c4769411d 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -845,6 +845,7 @@
hsotg@1248 {
vusb_d-supply = <&ldo15_reg>;
vusb_a-supply = <&ldo12_reg>;
+ dr_mode = "peripheral";
status = "okay";
};
diff --git a/arch/arm/boot/dts/s5pv210-aquila.dts
b/arch/arm/boot/dts/s5pv210-aquila.dts
index aa31b84a707a..f00cea7aca2f 100644
--- a/arch/arm/boot/dts/s5pv210-aquila.dts
+++ b/arch/arm/boot/dts/s5pv210-aquila.dts
@@ -355,6 +355,7 @@
&hsotg {
vusb_a-supply = <&ldo3_reg>;
vusb_d-supply = <&ldo8_reg>;
+ dr_mode = "peripheral";
status = "okay";
};
diff --git a/arch/arm/boot/dts/s5pv210-goni.dts
b/arch/arm/boot/dts/s5pv210-goni.dts
index 6387c77a6f7b..a3d4643b202e 100644
--- a/arch/arm/boot/dts/s5pv210-goni.dts
+++ b/arch/arm/boot/dts/s5pv210-goni.dts
@@ -333,6 +333,7 @@
&hsotg {
vusb_a-supply = <&ldo3_reg>;
vusb_d-supply = <&ldo8_reg>;
+ dr_mode = "peripheral";
status = "okay";
};
diff --git a/arch/arm/boot/dts/s5pv210-smdkv210.dts
b/arch/arm/boot/dts/s5pv210-smdkv210.dts
index cb8521899ec8..da7d210df670 100644
--- a/arch/arm/boot/dts/s5pv210-smdkv210.dts
+++ b/arch/arm/boot/dts/s5pv210-smdkv210.dts
@@ -181,6 +181,7 @@
};
&hsotg {
+ dr_mode = "peripheral";
status = "okay";
};
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 5/8] [media] exynos-gsc: Fixup clock management at ->remove()
To make sure the clock is fully gated in ->remove(), we first need to
to bring the device into full power by invoking pm_runtime_get_sync().
Then, let's both unprepare and disable the clock.
Signed-off-by: Ulf Hansson
---
drivers/media/platform/exynos-gsc/gsc-core.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index e84bc35..5d3cfe8 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1104,12 +1104,15 @@ static int gsc_remove(struct platform_device *pdev)
{
struct gsc_dev *gsc = platform_get_drvdata(pdev);
+ pm_runtime_get_sync(&pdev->dev);
+
gsc_unregister_m2m_device(gsc);
v4l2_device_unregister(&gsc->v4l2_dev);
-
vb2_dma_contig_cleanup_ctx(gsc->alloc_ctx);
+ clk_disable_unprepare(gsc->clock);
+
pm_runtime_disable(&pdev->dev);
- clk_unprepare(gsc->clock);
+ pm_runtime_put_noidle(&pdev->dev);
dev_dbg(&pdev->dev, "%s driver unloaded\n", pdev->name);
return 0;
--
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 4/8] [media] exynos-gsc: Make runtime PM callbacks available for CONFIG_PM
There are no need to set up the runtime PM callbacks unless they are
being used. It also causes compiler warnings about unused functions.
Silence the warnings by making them available for CONFIG_PM.
Signed-off-by: Ulf Hansson
---
drivers/media/platform/exynos-gsc/gsc-core.c | 79 ++--
1 file changed, 40 insertions(+), 39 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 532daa8..e84bc35 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1003,43 +1003,6 @@ static void *gsc_get_drv_data(struct platform_device
*pdev)
return driver_data;
}
-static int gsc_m2m_suspend(struct gsc_dev *gsc)
-{
- unsigned long flags;
- int timeout;
-
- spin_lock_irqsave(&gsc->slock, flags);
- if (!gsc_m2m_pending(gsc)) {
- spin_unlock_irqrestore(&gsc->slock, flags);
- return 0;
- }
- clear_bit(ST_M2M_SUSPENDED, &gsc->state);
- set_bit(ST_M2M_SUSPENDING, &gsc->state);
- spin_unlock_irqrestore(&gsc->slock, flags);
-
- timeout = wait_event_timeout(gsc->irq_queue,
-test_bit(ST_M2M_SUSPENDED, &gsc->state),
-GSC_SHUTDOWN_TIMEOUT);
-
- clear_bit(ST_M2M_SUSPENDING, &gsc->state);
- return timeout == 0 ? -EAGAIN : 0;
-}
-
-static void gsc_m2m_resume(struct gsc_dev *gsc)
-{
- struct gsc_ctx *ctx;
- unsigned long flags;
-
- spin_lock_irqsave(&gsc->slock, flags);
- /* Clear for full H/W setup in first run after resume */
- ctx = gsc->m2m.ctx;
- gsc->m2m.ctx = NULL;
- spin_unlock_irqrestore(&gsc->slock, flags);
-
- if (test_and_clear_bit(ST_M2M_SUSPENDED, &gsc->state))
- gsc_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
-}
-
static int gsc_probe(struct platform_device *pdev)
{
struct gsc_dev *gsc;
@@ -1152,6 +1115,44 @@ static int gsc_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM
+static int gsc_m2m_suspend(struct gsc_dev *gsc)
+{
+ unsigned long flags;
+ int timeout;
+
+ spin_lock_irqsave(&gsc->slock, flags);
+ if (!gsc_m2m_pending(gsc)) {
+ spin_unlock_irqrestore(&gsc->slock, flags);
+ return 0;
+ }
+ clear_bit(ST_M2M_SUSPENDED, &gsc->state);
+ set_bit(ST_M2M_SUSPENDING, &gsc->state);
+ spin_unlock_irqrestore(&gsc->slock, flags);
+
+ timeout = wait_event_timeout(gsc->irq_queue,
+test_bit(ST_M2M_SUSPENDED, &gsc->state),
+GSC_SHUTDOWN_TIMEOUT);
+
+ clear_bit(ST_M2M_SUSPENDING, &gsc->state);
+ return timeout == 0 ? -EAGAIN : 0;
+}
+
+static void gsc_m2m_resume(struct gsc_dev *gsc)
+{
+ struct gsc_ctx *ctx;
+ unsigned long flags;
+
+ spin_lock_irqsave(&gsc->slock, flags);
+ /* Clear for full H/W setup in first run after resume */
+ ctx = gsc->m2m.ctx;
+ gsc->m2m.ctx = NULL;
+ spin_unlock_irqrestore(&gsc->slock, flags);
+
+ if (test_and_clear_bit(ST_M2M_SUSPENDED, &gsc->state))
+ gsc_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
+}
+
static int gsc_runtime_resume(struct device *dev)
{
struct gsc_dev *gsc = dev_get_drvdata(dev);
@@ -1182,6 +1183,7 @@ static int gsc_runtime_suspend(struct device *dev)
pr_debug("gsc%d: state: 0x%lx", gsc->id, gsc->state);
return ret;
}
+#endif
static int gsc_resume(struct device *dev)
{
@@ -1223,8 +1225,7 @@ static int gsc_suspend(struct device *dev)
static const struct dev_pm_ops gsc_pm_ops = {
.suspend= gsc_suspend,
.resume = gsc_resume,
- .runtime_suspend= gsc_runtime_suspend,
- .runtime_resume = gsc_runtime_resume,
+ SET_RUNTIME_PM_OPS(gsc_runtime_suspend, gsc_runtime_resume, NULL)
};
static struct platform_driver gsc_driver = {
--
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 6/8] [media] exynos-gsc: Do full clock gating at runtime PM suspend
To potentially save more power in runtime PM suspend state, let's also
prepare/unprepare the clock from the runtime PM callbacks.
Signed-off-by: Ulf Hansson
---
drivers/media/platform/exynos-gsc/gsc-core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 5d3cfe8..0b126eb 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1163,7 +1163,7 @@ static int gsc_runtime_resume(struct device *dev)
pr_debug("gsc%d: state: 0x%lx", gsc->id, gsc->state);
- ret = clk_enable(gsc->clock);
+ ret = clk_prepare_enable(gsc->clock);
if (ret)
return ret;
@@ -1181,7 +1181,7 @@ static int gsc_runtime_suspend(struct device *dev)
ret = gsc_m2m_suspend(gsc);
if (!ret)
- clk_disable(gsc->clock);
+ clk_disable_unprepare(gsc->clock);
pr_debug("gsc%d: state: 0x%lx", gsc->id, gsc->state);
return ret;
--
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/8] [media] exynos-gsc: Convert gsc_m2m_resume() from int to void
Since gsc_m2m_resume() always returns 0, convert it to a void instead.
Signed-off-by: Ulf Hansson
---
drivers/media/platform/exynos-gsc/gsc-core.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index bd769d4..1865738 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1025,7 +1025,7 @@ static int gsc_m2m_suspend(struct gsc_dev *gsc)
return timeout == 0 ? -EAGAIN : 0;
}
-static int gsc_m2m_resume(struct gsc_dev *gsc)
+static void gsc_m2m_resume(struct gsc_dev *gsc)
{
struct gsc_ctx *ctx;
unsigned long flags;
@@ -1038,8 +1038,6 @@ static int gsc_m2m_resume(struct gsc_dev *gsc)
if (test_and_clear_bit(ST_M2M_SUSPENDED, &gsc->state))
gsc_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
-
- return 0;
}
static int gsc_probe(struct platform_device *pdev)
@@ -1168,8 +1166,9 @@ static int gsc_runtime_resume(struct device *dev)
gsc_hw_set_sw_reset(gsc);
gsc_wait_reset(gsc);
+ gsc_m2m_resume(gsc);
- return gsc_m2m_resume(gsc);
+ return 0;
}
static int gsc_runtime_suspend(struct device *dev)
--
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 3/8] [media] exynos-gsc: Make driver functional when CONFIG_PM is unset
The driver depended on CONFIG_PM to be functional. Let's remove that
dependency, by enable the runtime PM resourses during ->probe() and
update the device's runtime PM status to reflect this.
Signed-off-by: Ulf Hansson
---
drivers/media/platform/exynos-gsc/gsc-core.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 1865738..532daa8 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1088,7 +1088,7 @@ static int gsc_probe(struct platform_device *pdev)
return PTR_ERR(gsc->clock);
}
- ret = clk_prepare(gsc->clock);
+ ret = clk_prepare_enable(gsc->clock);
if (ret) {
dev_err(&gsc->pdev->dev, "clock prepare failed for clock: %s\n",
GSC_CLOCK_GATE_NAME);
@@ -,30 +,29 @@ static int gsc_probe(struct platform_device *pdev)
goto err_v4l2;
platform_set_drvdata(pdev, gsc);
- pm_runtime_enable(dev);
- ret = pm_runtime_get_sync(&pdev->dev);
- if (ret < 0)
- goto err_m2m;
+
+ gsc_hw_set_sw_reset(gsc);
+ gsc_wait_reset(gsc);
/* Initialize continious memory allocator */
gsc->alloc_ctx = vb2_dma_contig_init_ctx(dev);
if (IS_ERR(gsc->alloc_ctx)) {
ret = PTR_ERR(gsc->alloc_ctx);
- goto err_pm;
+ goto err_m2m;
}
dev_dbg(dev, "gsc-%d registered successfully\n", gsc->id);
- pm_runtime_put(dev);
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+
return 0;
-err_pm:
- pm_runtime_put(dev);
err_m2m:
gsc_unregister_m2m_device(gsc);
err_v4l2:
v4l2_device_unregister(&gsc->v4l2_dev);
err_clk:
- clk_unprepare(gsc->clock);
+ clk_disable_unprepare(gsc->clock);
return ret;
}
--
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 7/8] [media] exynos-gsc: Make system PM callbacks available for CONFIG_PM_SLEEP
There are no need to set up the system PM callbacks unless they are
being used. It also causes compiler warnings about unused functions.
Silence the warnings by making them available for CONFIG_PM_SLEEP.
Signed-off-by: Ulf Hansson
---
drivers/media/platform/exynos-gsc/gsc-core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 0b126eb..194f9fc 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1188,6 +1188,7 @@ static int gsc_runtime_suspend(struct device *dev)
}
#endif
+#ifdef CONFIG_PM_SLEEP
static int gsc_resume(struct device *dev)
{
struct gsc_dev *gsc = dev_get_drvdata(dev);
@@ -1224,10 +1225,10 @@ static int gsc_suspend(struct device *dev)
return 0;
}
+#endif
static const struct dev_pm_ops gsc_pm_ops = {
- .suspend= gsc_suspend,
- .resume = gsc_resume,
+ SET_SYSTEM_SLEEP_PM_OPS(gsc_suspend, gsc_resume)
SET_RUNTIME_PM_OPS(gsc_runtime_suspend, gsc_runtime_resume, NULL)
};
--
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 8/8] [media] exynos-gsc: Simplify system PM
It's not needed to keep a local flag about the current system PM state.
Let's just remove that code and the corresponding debug print.
Signed-off-by: Ulf Hansson
---
drivers/media/platform/exynos-gsc/gsc-core.c | 21 -
drivers/media/platform/exynos-gsc/gsc-core.h | 3 ---
2 files changed, 24 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 194f9fc..71b227c 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1191,20 +1191,6 @@ static int gsc_runtime_suspend(struct device *dev)
#ifdef CONFIG_PM_SLEEP
static int gsc_resume(struct device *dev)
{
- struct gsc_dev *gsc = dev_get_drvdata(dev);
- unsigned long flags;
-
- pr_debug("gsc%d: state: 0x%lx", gsc->id, gsc->state);
-
- /* Do not resume if the device was idle before system suspend */
- spin_lock_irqsave(&gsc->slock, flags);
- if (!test_and_clear_bit(ST_SUSPEND, &gsc->state) ||
- !gsc_m2m_opened(gsc)) {
- spin_unlock_irqrestore(&gsc->slock, flags);
- return 0;
- }
- spin_unlock_irqrestore(&gsc->slock, flags);
-
if (!pm_runtime_suspended(dev))
return gsc_runtime_resume(dev);
@@ -1213,13 +1199,6 @@ static int gsc_resume(struct device *dev)
static int gsc_suspend(struct device *dev)
{
- struct gsc_dev *gsc = dev_get_drvdata(dev);
-
- pr_debug("gsc%d: state: 0x%lx", gsc->id, gsc->state);
-
- if (test_and_set_bit(ST_SUSPEND, &gsc->state))
- return 0;
-
if (!pm_runtime_suspended(dev))
return gsc_runtime_suspend(dev);
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.h
b/drivers/media/platform/exynos-gsc/gsc-core.h
index fa572aa..2f62271 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.h
+++ b/drivers/media/platform/exynos-gsc/gsc-core.h
@@ -48,9 +48,6 @@
#defineGSC_CTX_ABORT (1 << 7)
enum gsc_dev_flags {
- /* for global */
- ST_SUSPEND,
-
/* for m2m node */
ST_M2M_OPEN,
ST_M2M_RUN,
--
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 1/8] [media] exynos-gsc: Simplify clock management
Instead of having separate functions that fecthes, prepares and
unprepares the clock, let's encapsulate this code into ->probe().
This makes error handling easier and decreases the lines of code.
Signed-off-by: Ulf Hansson
---
drivers/media/platform/exynos-gsc/gsc-core.c | 49
1 file changed, 14 insertions(+), 35 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index fd2891c..bd769d4 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1003,36 +1003,6 @@ static void *gsc_get_drv_data(struct platform_device
*pdev)
return driver_data;
}
-static void gsc_clk_put(struct gsc_dev *gsc)
-{
- if (!IS_ERR(gsc->clock))
- clk_unprepare(gsc->clock);
-}
-
-static int gsc_clk_get(struct gsc_dev *gsc)
-{
- int ret;
-
- dev_dbg(&gsc->pdev->dev, "gsc_clk_get Called\n");
-
- gsc->clock = devm_clk_get(&gsc->pdev->dev, GSC_CLOCK_GATE_NAME);
- if (IS_ERR(gsc->clock)) {
- dev_err(&gsc->pdev->dev, "failed to get clock~~~: %s\n",
- GSC_CLOCK_GATE_NAME);
- return PTR_ERR(gsc->clock);
- }
-
- ret = clk_prepare(gsc->clock);
- if (ret < 0) {
- dev_err(&gsc->pdev->dev, "clock prepare failed for clock: %s\n",
- GSC_CLOCK_GATE_NAME);
- gsc->clock = ERR_PTR(-EINVAL);
- return ret;
- }
-
- return 0;
-}
-
static int gsc_m2m_suspend(struct gsc_dev *gsc)
{
unsigned long flags;
@@ -1101,7 +1071,6 @@ static int gsc_probe(struct platform_device *pdev)
init_waitqueue_head(&gsc->irq_queue);
spin_lock_init(&gsc->slock);
mutex_init(&gsc->lock);
- gsc->clock = ERR_PTR(-EINVAL);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
gsc->regs = devm_ioremap_resource(dev, res);
@@ -1114,9 +1083,19 @@ static int gsc_probe(struct platform_device *pdev)
return -ENXIO;
}
- ret = gsc_clk_get(gsc);
- if (ret)
+ gsc->clock = devm_clk_get(dev, GSC_CLOCK_GATE_NAME);
+ if (IS_ERR(gsc->clock)) {
+ dev_err(dev, "failed to get clock~~~: %s\n",
+ GSC_CLOCK_GATE_NAME);
+ return PTR_ERR(gsc->clock);
+ }
+
+ ret = clk_prepare(gsc->clock);
+ if (ret) {
+ dev_err(&gsc->pdev->dev, "clock prepare failed for clock: %s\n",
+ GSC_CLOCK_GATE_NAME);
return ret;
+ }
ret = devm_request_irq(dev, res->start, gsc_irq_handler,
0, pdev->name, gsc);
@@ -1157,7 +1136,7 @@ err_m2m:
err_v4l2:
v4l2_device_unregister(&gsc->v4l2_dev);
err_clk:
- gsc_clk_put(gsc);
+ clk_unprepare(gsc->clock);
return ret;
}
@@ -1170,7 +1149,7 @@ static int gsc_remove(struct platform_device *pdev)
vb2_dma_contig_cleanup_ctx(gsc->alloc_ctx);
pm_runtime_disable(&pdev->dev);
- gsc_clk_put(gsc);
+ clk_unprepare(gsc->clock);
dev_dbg(&pdev->dev, "%s driver unloaded\n", pdev->name);
return 0;
--
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/8] [media] exynos-gsc: Fixup PM support
Changes in v2: - Rebase patches. - Adapt to changes for the PM core. Especially, the Kconfig option for CONFIG_PM_RUNTIME has been removed and the runtime PM core is now build for CONFIG_PM. This patchset fixup the PM support and adds some minor improvements to potentially save some more power at runtime PM suspend. Ulf Hansson (8): [media] exynos-gsc: Simplify clock management [media] exynos-gsc: Convert gsc_m2m_resume() from int to void [media] exynos-gsc: Make driver functional when CONFIG_PM is unset [media] exynos-gsc: Make runtime PM callbacks available for CONFIG_PM [media] exynos-gsc: Fixup clock management at ->remove() [media] exynos-gsc: Do full clock gating at runtime PM suspend [media] exynos-gsc: Make system PM callbacks available for CONFIG_PM_SLEEP [media] exynos-gsc: Simplify system PM drivers/media/platform/exynos-gsc/gsc-core.c | 183 +++ drivers/media/platform/exynos-gsc/gsc-core.h | 3 - 2 files changed, 72 insertions(+), 114 deletions(-) -- 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 v3] thermal: exynos: Add TMU support for Exynos7 SoC
Hi Abhilash, > Add registers, bit fields and compatible strings for Exynos7 TMU > (Thermal Management Unit). Following are a few of the differences > in the Exynos7 TMU from earlier SoCs: > - 8 trigger levels > - Different bit offsets and more registers for the rising > and falling thresholds. > - New power down detection bit in the TMU_CONTROL register > which does not update the CURRENT_TEMP0 when tmu power down > is detected. > - Change in bit offset for the NEXT_DATA field of EMUL_CON > register. EMUL_CON register address has also changed. > - INTSTAT and INTCLEAR registers present in earlier SoCs > have been combined into one INTPEND register. The register > address for INTCLEAR and INTPEND is also different. > - Since there are 8 rising/falling interrupts as against > at most 4 in earlier SoCs the INTEN bit offsets are different. > - Multiple probe support which is handled by a TMU_CONTROL1 > register (No support for this in the current patch). > > This patch adds special clock support required only for Exynos7 > and updates the bindings documentation appropriately. It also updates > the "code_to_temp" prototype as Exynos7 has 9 bit code-temp mapping. > > Signed-off-by: Abhilash Kesavan > --- > This patch is based on Lukasz Majewski's Exynos TMU v4 patchset: > http://www.spinics.net/lists/linux-samsung-soc/msg41183.html > > Changes since v2: > - Rebased on top of Lukasz' latest exynos tmu series (v4). > - Added new exynos7 soc_type. > Changes since v1: > - Rebased on top of Lukasz' latest exynos tmu series (v2). > - Added sclk support to patch adding Exynos7 tmu support. > Previously, it was a separate patch. > - Used the SOC type to decide if sclk is present. > > .../devicetree/bindings/thermal/exynos-thermal.txt |4 + > drivers/thermal/samsung/exynos_tmu.c | 203 > +++- > drivers/thermal/samsung/exynos_tmu.h |1 + 3 files > changed, 199 insertions(+), 9 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt > b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt index > 0f44932..695150a 100644 --- > a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt +++ > b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt @@ > -12,6 +12,7 @@ "samsung,exynos5420-tmu-ext-triminfo" for TMU channels > 2, 3 and 4 Exynos5420 (Must pass triminfo base and triminfo clock) > "samsung,exynos5440-tmu" > +"samsung,exynos7-tmu" > - interrupt-parent : The phandle for the interrupt controller > - reg : Address range of the thermal registers. For soc's which has > multiple instances of TMU and some registers are shared across all > TMU's like @@ -32,10 +33,13 @@ > - clocks : The main clocks for TMU device > -- 1. operational clock for TMU channel > -- 2. optional clock to access the shared registers of TMU > channel > + -- 3. optional special clock for functional operation > - clock-names : Thermal system clock name > -- "tmu_apbif" operational clock for current TMU channel > -- "tmu_triminfo_apbif" clock to access the shared triminfo > register for current TMU channel > + -- "tmu_sclk" clock for functional operation of the current > TMU > + channel > - vtmu-supply: This entry is optional and provides the regulator > node supplying voltage to TMU. If needed this entry can be placed > inside board/platform specific dts file. I would recommend splitting the documentation from the code. IMHO it would be more readable. > diff --git a/drivers/thermal/samsung/exynos_tmu.c > b/drivers/thermal/samsung/exynos_tmu.c index 633a9e2..8b26acb 100644 > --- a/drivers/thermal/samsung/exynos_tmu.c > +++ b/drivers/thermal/samsung/exynos_tmu.c > @@ -119,6 +119,26 @@ > #define EXYNOS5440_TMU_TH_RISE4_SHIFT24 > #define EXYNOS5440_EFUSE_SWAP_OFFSET 8 > > +/* Exynos7 specific registers */ > +#define EXYNOS7_THD_TEMP_RISE7_6 0x50 > +#define EXYNOS7_THD_TEMP_FALL7_6 0x60 > +#define EXYNOS7_TMU_REG_INTEN0x110 > +#define EXYNOS7_TMU_REG_INTPEND 0x118 ^ I suppose that this misalignment is only done by my mail client and checkpatch is not complaining. > +#define EXYNOS7_TMU_REG_EMUL_CON 0x160 > + > +#define EXYNOS7_TMU_TEMP_MASK0x1ff > +#define EXYNOS7_PD_DET_EN_SHIFT 23 > +#define EXYNOS7_TMU_INTEN_RISE0_SHIFT0 > +#define EXYNOS7_TMU_INTEN_RISE1_SHIFT1 > +#define EXYNOS7_TMU_INTEN_RISE2_SHIFT
Re: [PATCH V3 09/15] ASoC: samsung: i2s: Protect more registers with a spinlock
Hi Tuashar,
On 17/01/15 06:21, Tushar Behera wrote:
> On Thu, Jan 15, 2015 at 3:42 AM, Sylwester Nawrocki
> wrote:
>> Ensure the I2SMOD, I2SPSR registers, which are also exposed through
>> clk API are only accessed with the i2s->spinlock spinlock held.
>>
>> Signed-off-by: Sylwester Nawrocki
>> ---
>> sound/soc/samsung/i2s.c | 81
>> +--
>> 1 file changed, 51 insertions(+), 30 deletions(-)
>>
>> diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
>> index 20cc51f..05fc2f0 100644
>> --- a/sound/soc/samsung/i2s.c
>> +++ b/sound/soc/samsung/i2s.c
>> @@ -472,17 +472,22 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai,
>> {
>> struct i2s_dai *i2s = to_info(dai);
>> struct i2s_dai *other = get_other_dai(i2s);
>> - u32 mod = readl(i2s->addr + I2SMOD);
>> const struct samsung_i2s_variant_regs *i2s_regs = i2s->variant_regs;
>> unsigned int cdcon_mask = 1 << i2s_regs->cdclkcon_off;
>> unsigned int rsrc_mask = 1 << i2s_regs->rclksrc_off;
>> + u32 mod, mask, val = 0;
>> +
>> + spin_lock(i2s->lock);
>> + mod = readl(i2s->addr + I2SMOD);
>> + spin_unlock(i2s->lock);
>>
>
> 'mod' is now updated only at the bottom of this function. The above
> readl can be omitted.
mod is used in some of the 'if' statements below, so we must read it
here beforehand.
>> switch (clk_id) {
>> case SAMSUNG_I2S_OPCLK:
>> - mod &= ~MOD_OPCLK_MASK;
>> - mod |= dir;
>> + mask = MOD_OPCLK_MASK;
>> + val = dir;
>> break;
>> case SAMSUNG_I2S_CDCLK:
>> + mask = 1 << i2s_regs->cdclkcon_off;
>
> Use BIT() macro instead?
Yes, it would be a good code cleanup, might be worth to include it in
some future patch series. I'll keep it in mind, since this patch is merged
already.
And the logical bit operations is one of things people make mistakes most
often, so any changes like these would need to be well tested and/or
carefully reviewed.
--
Thanks,
Sylwester
--
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] thermal: exynos: Reorder exynos_map_dt_data() function
The exynos_map_dt_data() function must be called before
thermal_zone_of_sensor_register(), and hence provide tmu_read() function,
before it is needed.
This change is driven by adding support for enabling thermal_zoneX when
it is properly initialized.
One can read the mode of operation at /sys/class/thermal/thermal_zone0/mode
Such functionality was missing in the of-thermal.c code.
Reported-by: Abhilash Kesavan
Signed-off-by: Lukasz Majewski
---
drivers/thermal/samsung/exynos_tmu.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 9d2d685..5d946ab 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -975,15 +975,16 @@ static int exynos_tmu_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, data);
mutex_init(&data->lock);
+ ret = exynos_map_dt_data(pdev);
+ if (ret)
+ goto err_sensor;
+
data->tzd = thermal_zone_of_sensor_register(&pdev->dev, 0, data,
&exynos_sensor_ops);
if (IS_ERR(data->tzd)) {
pr_err("thermal: tz: %p ERROR\n", data->tzd);
return PTR_ERR(data->tzd);
}
- ret = exynos_map_dt_data(pdev);
- if (ret)
- goto err_sensor;
pdata = data->pdata;
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] thermal: of: Enable thermal_zoneX when sensor is correctly added
Up till now the thermal_zone mode was by default "disabled". With this
patch the default behavior was changed to "enable".
One can read the mode at:
/sys/class/thermal/thermal_zone0/mode
Reported-by: Abhilash Kesavan
Signed-off-by: Lukasz Majewski
---
drivers/thermal/of-thermal.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index d717f3d..668fb1b 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -497,6 +497,9 @@ thermal_zone_of_sensor_register(struct device *dev, int
sensor_id, void *data,
if (sensor_specs.np == sensor_np && id == sensor_id) {
tzd = thermal_zone_of_add_sensor(child, sensor_np,
data, ops);
+ if (!IS_ERR(tzd))
+ tzd->ops->set_mode(tzd, THERMAL_DEVICE_ENABLED);
+
of_node_put(sensor_specs.np);
of_node_put(child);
goto exit;
--
2.0.0.rc2
--
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 0/2] thermal: Set default thermal_zoneX mode to "enabled"
After Exynos TMU rework the default value of /sys/class/thermal/thermal_zone0/mode was set to "disabled" Those two patches enable it by default. The problem was reported by: Abhilash Kesavan Dependencies: linux-soc-thermal/next SHA1: 1813d80874699145f04af6b05ebab0a6419001fb And applied following patch series: [PATCH v5 00/18] thermal: exynos: Thermal code rework to use device tree Lukasz Majewski (2): thermal: exynos: Reorder exynos_map_dt_data() function thermal: of: Enable thermal_zoneX when sensor is correctly added drivers/thermal/of-thermal.c | 3 +++ drivers/thermal/samsung/exynos_tmu.c | 7 --- 2 files changed, 7 insertions(+), 3 deletions(-) -- 2.0.0.rc2 -- 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 v4 17/18] iommu: exynos: init from dt-specific callback instead of initcall
On Mon, Jan 19, 2015 at 01:11:07AM +, Laurent Pinchart wrote:
> On Friday 16 January 2015 10:13:11 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.
[...]
> > +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);
>
> This feels like a hack to me. What happens here is that you're using the
> IOMMU_OF_DECLARE mechanism to make sure that the iommu platform device will
> be
> created and registered before the normal OF bus populate mechanism kicks in,
> thus ensuring that the iommu gets probed before other devices. In practice
> this is pretty similar to using different init levels, which is what Will's
> patch set was trying to avoid in the first place. Creating a new kind of init
> levels mechanism doesn't sound very good to me.
>
> The existing exynos-iommu driver is based on classic instantiation of a
> platform device from DT, using the normal device probing mechanism. As such
> it
> relies on the availability of a struct device for various helper functions. I
> thus understand why you want a struct device being registered for the iommu,
> instead of initializing the device right from the exynos_iommu_of_setup()
> function without a corresponding struct device being registered.
>
> This leads me to question whether we should really introduce
> IOMMU_OF_DECLARE.
> Using regular deferred probing seems more and more like a better solution to
> me.
We seem to be going round and round on this argument. I said before that
I'm not against changing this [1], but somebody would need to propose
patches, which hasn't happened in recent history.
Arnd also makes some good arguments against using probing [2], which would
need further discussion.
Basically, it looks like there are two sides to this argument and I don't
see anything changing without patch proposals. The only thing that the
current discussions seem to be achieving is blocking people like Marek,
who are trying to make use of what we have in mainline today!
Will
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/310783.html
[2]
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/310992.html
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 04/18] arm: dts: odroid: Add LDO10 regulator node necessary for TMU on Odroid
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- None
Changes for v3:
- Patch title has been changed from thermal: dts: exynos to arm: dts: Odroid
Changes for v4:
- None
Changes for v5:
- None
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 3fbf588..0adb57c 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -231,6 +231,13 @@
regulator-always-on;
};
+ ldo10_reg: LDO10 {
+ regulator-name = "VDD18_MIPIHSI_1.8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
ldo11_reg: LDO11 {
regulator-name = "VDD18_ABB1_1.8V";
regulator-min-microvolt = <180>;
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 07/18] thermal: exynos: Modify exynos thermal code to use device tree for cpu cooling configuration
Up till now exynos_tmu_data.c was used for storing CPU cooling configuration
data. Now the Exynos thermal core code uses device tree to get this data.
For this purpose generic thermal code for configuring CPU cooling was
used.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- None
Changes for v3:
- Rewrite code responsible for registering CPU cooling device to not depend
on explicit "/cpus/cpu@0" path since now Exynos SoCs use new cpu node
names (e.g. cpu@A00). New approach iterates over "cpus" node children.
- Patch title changed to thermal: exynos
Changes for v4:
- None
Changes for v5:
- None
---
drivers/cpufreq/exynos-cpufreq.c| 30 +-
drivers/thermal/samsung/exynos_thermal_common.c | 122 ++--
drivers/thermal/samsung/exynos_tmu.c| 7 --
drivers/thermal/samsung/exynos_tmu.h| 5 -
drivers/thermal/samsung/exynos_tmu_data.c | 42 +---
5 files changed, 101 insertions(+), 105 deletions(-)
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index f99a0b0..32bc64d 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -18,10 +18,13 @@
#include
#include
#include
+#include
+#include
#include "exynos-cpufreq.h"
static struct exynos_dvfs_info *exynos_info;
+static struct thermal_cooling_device *cdev;
static struct regulator *arm_regulator;
static unsigned int locking_frequency;
@@ -156,6 +159,7 @@ static struct cpufreq_driver exynos_driver = {
static int exynos_cpufreq_probe(struct platform_device *pdev)
{
+ struct device_node *cpus, *np;
int ret = -EINVAL;
exynos_info = kzalloc(sizeof(*exynos_info), GFP_KERNEL);
@@ -198,9 +202,31 @@ static int exynos_cpufreq_probe(struct platform_device
*pdev)
/* Done here as we want to capture boot frequency */
locking_frequency = clk_get_rate(exynos_info->cpu_clk) / 1000;
- if (!cpufreq_register_driver(&exynos_driver))
- return 0;
+ if (cpufreq_register_driver(&exynos_driver))
+ goto err;
+ cpus = of_find_node_by_path("/cpus");
+ if (!cpus) {
+ pr_err("failed to find cpus node\n");
+ return -ENOENT;
+ }
+
+ for (np = of_get_next_child(cpus, NULL); np;
+of_node_put(np), np = of_get_next_child(cpus, np)) {
+ if (of_find_property(np, "#cooling-cells", NULL)) {
+ cdev = of_cpufreq_cooling_register(np,
+ cpu_present_mask);
+ if (IS_ERR(cdev))
+ pr_err("running cpufreq without cooling device:
%ld\n",
+ PTR_ERR(cdev));
+ break;
+ }
+ }
+ of_node_put(np);
+ of_node_put(cpus);
+
+ return 0;
+ err:
dev_err(&pdev->dev, "failed to register cpufreq driver\n");
regulator_put(arm_regulator);
err_vdd_arm:
diff --git a/drivers/thermal/samsung/exynos_thermal_common.c
b/drivers/thermal/samsung/exynos_thermal_common.c
index 6dc3815..00aa688 100644
--- a/drivers/thermal/samsung/exynos_thermal_common.c
+++ b/drivers/thermal/samsung/exynos_thermal_common.c
@@ -133,47 +133,62 @@ static int exynos_get_crit_temp(struct
thermal_zone_device *thermal,
static int exynos_bind(struct thermal_zone_device *thermal,
struct thermal_cooling_device *cdev)
{
- int ret = 0, i, tab_size, level;
- struct freq_clip_table *tab_ptr, *clip_data;
struct exynos_thermal_zone *th_zone = thermal->devdata;
struct thermal_sensor_conf *data = th_zone->sensor_conf;
+ struct device_node *child, *gchild, *np;
+ struct of_phandle_args cooling_spec;
+ unsigned long max, state = 0;
+ int ret = 0, i = 0;
- tab_ptr = (struct freq_clip_table *)data->cooling_data.freq_data;
- tab_size = data->cooling_data.freq_clip_count;
-
- if (tab_ptr == NULL || tab_size == 0)
+ /*
+* Below code is necessary to skip binding when cpufreq's
+* frequency table is not yet initialized.
+*/
+ cdev->ops->get_max_state(cdev, &state);
+ if (!state && !th_zone->cool_dev_size) {
+ th_zone->cool_dev_size = 1;
+ th_zone->cool_dev[0] = cdev;
+ th_zone->bind = false;
return 0;
+ }
- /* find the cooling device registered*/
- for (i = 0; i < th_zone->cool_dev_size; i++)
- if (cdev == th_zone->cool_dev[i])
- break;
+ np = of_find_node_by_path("/thermal-zones/cpu-thermal");
+ if (!np) {
+ pr_err("failed to find thmerla-zones/cpu-thermal node\n");
+ return -ENOENT;
+ }
- /* No matching cooling device */
- if (i == th_zone->cool_dev_size)
- return 0;
+ child = of_get_chil
[PATCH v5 09/18] dts: Documentation: Extending documentation entry for exynos-thermal
Properties necessary for providing Exynos thermal configuration via device
tree.
Signed-off-by: Lukasz Majewski
---
Changes for v3:
- New patch
Changes for v4:
- Remove entry regarding Exynos5440
Changes for v5:
- None
---
.../devicetree/bindings/thermal/exynos-thermal.txt | 16
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index ae738f5..8497794 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -39,6 +39,18 @@
- vtmu-supply: This entry is optional and provides the regulator node supplying
voltage to TMU. If needed this entry can be placed inside
board/platform specific dts file.
+Following properties are mandatory (depending on SoC):
+- samsung,tmu_gain: Gain value for internal TMU operation.
+- samsung,tmu_reference_voltage: Value of TMU IP block's reference voltage
+- samsung,tmu_noise_cancel_mode: Mode for noise cancellation
+- samsung,tmu_efuse_value: Default level of temperature - it is needed when
+ in factory fusing produced wrong value
+- samsung,tmu_min_efuse_value: Minimum temperature fused value
+- samsung,tmu_max_efuse_value: Maximum temperature fused value
+- samsung,tmu_first_point_trim: First point trimming value
+- samsung,tmu_second_point_trim: Second point trimming value
+- samsung,tmu_default_temp_offset: Default temperature offset
+- samsung,tmu_cal_type: Callibration type
Example 1):
@@ -51,6 +63,7 @@ Example 1):
clock-names = "tmu_apbif";
status = "disabled";
vtmu-supply = <&tmu_regulator_node>;
+ #include "exynos4412-tmu-sensor-conf.dtsi"
};
Example 2):
@@ -70,6 +83,7 @@ Example 3): (In case of Exynos5420 "with misplaced TRIMINFO
register")
interrupts = <0 184 0>;
clocks = <&clock 318>, <&clock 318>;
clock-names = "tmu_apbif", "tmu_triminfo_apbif";
+ #include "exynos4412-tmu-sensor-conf.dtsi"
};
tmu_cpu3: tmu@1006c000 {
@@ -78,6 +92,7 @@ Example 3): (In case of Exynos5420 "with misplaced TRIMINFO
register")
interrupts = <0 185 0>;
clocks = <&clock 318>, <&clock 319>;
clock-names = "tmu_apbif", "tmu_triminfo_apbif";
+ #include "exynos4412-tmu-sensor-conf.dtsi"
};
tmu_gpu: tmu@100a {
@@ -86,6 +101,7 @@ Example 3): (In case of Exynos5420 "with misplaced TRIMINFO
register")
interrupts = <0 215 0>;
clocks = <&clock 319>, <&clock 318>;
clock-names = "tmu_apbif", "tmu_triminfo_apbif";
+ #include "exynos4412-tmu-sensor-conf.dtsi"
};
Note: For multi-instance tmu each instance should have an alias correctly
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 08/18] thermal: exynos: dts: Add default definition of the TMU sensor parameter
Exynos 4 and 5 family of SoCs uses almost identical TMU sensor to measure the on chip temperature. For this reason it is possible to group TMU configuration parameters in one dts file. Signed-off-by: Lukasz Majewski --- Changes for v2: - None Changes for v3: - "samsung,tmu_" prefix for TMU specific properties has been added Changes for v4: - None Changes for v5: - None --- arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi | 24 +++ 1 file changed, 24 insertions(+) create mode 100644 arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi diff --git a/arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi b/arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi new file mode 100644 index 000..e3f7934 --- /dev/null +++ b/arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi @@ -0,0 +1,24 @@ +/* + * Device tree sources for Exynos4412 TMU sensor configuration + * + * Copyright (c) 2014 Lukasz Majewski + * + * 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 + +#thermal-sensor-cells = <0>; +samsung,tmu_gain = <8>; +samsung,tmu_reference_voltage = <16>; +samsung,tmu_noise_cancel_mode = <4>; +samsung,tmu_efuse_value = <55>; +samsung,tmu_min_efuse_value = <40>; +samsung,tmu_max_efuse_value = <100>; +samsung,tmu_first_point_trim = <25>; +samsung,tmu_second_point_trim = <85>; +samsung,tmu_default_temp_offset = <50>; +samsung,tmu_cal_type = ; -- 2.0.0.rc2 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 10/18] thermal: dts: Default trip points definition for Exynos5420 SoCs
This code groups in one place default settings of trip points. It is used
in SoCs with multiple instances of TMU sensor.
Separate device tree file prevents from multiple copying of the same data.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- None
---
arch/arm/boot/dts/exynos5420-trip-points.dtsi | 35 +++
1 file changed, 35 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5420-trip-points.dtsi
diff --git a/arch/arm/boot/dts/exynos5420-trip-points.dtsi
b/arch/arm/boot/dts/exynos5420-trip-points.dtsi
new file mode 100644
index 000..09d6c56
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5420-trip-points.dtsi
@@ -0,0 +1,35 @@
+/*
+ * Device tree sources for default Exynos 5420 thermal zone definition
+ *
+ * Copyright (c) 2014 Lukasz Majewski
+ *
+ * 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.
+ *
+ */
+
+polling-delay-passive = <0>;
+polling-delay = <0>;
+trips {
+ cpu-alert-0 {
+ temperature = <85000>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+ type = "active";
+ };
+ cpu-alert-1 {
+ temperature = <103000>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+ type = "active";
+ };
+ cpu-alert-2 {
+ temperature = <11>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+ type = "active";
+ };
+ cpu-crit-0 {
+ temperature = <120>; /* millicelsius */
+ hysteresis = <0>; /* millicelsius */
+ type = "critical";
+ };
+};
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 17/18] thermal: exynos: Remove exynos_tmu_data.c file
Data already present in the exynos_tmu_data.c file has been moved to the
appropriate device tree files.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- None
---
drivers/thermal/samsung/exynos_tmu_data.c | 228 --
1 file changed, 228 deletions(-)
delete mode 100644 drivers/thermal/samsung/exynos_tmu_data.c
diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
b/drivers/thermal/samsung/exynos_tmu_data.c
deleted file mode 100644
index a993f3d..000
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ /dev/null
@@ -1,228 +0,0 @@
-/*
- * exynos_tmu_data.c - Samsung EXYNOS tmu data file
- *
- * Copyright (C) 2013 Samsung Electronics
- * Amit Daniel Kachhap
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- *
- */
-
-#include "exynos_thermal_common.h"
-#include "exynos_tmu.h"
-
-struct exynos_tmu_init_data const exynos4210_default_tmu_data = {
- .tmu_data = {
- {
- .threshold = 80,
- .trigger_levels[0] = 5,
- .trigger_levels[1] = 20,
- .trigger_levels[2] = 30,
- .trigger_enable[0] = true,
- .trigger_enable[1] = true,
- .trigger_enable[2] = true,
- .trigger_enable[3] = false,
- .trigger_type[0] = THROTTLE_ACTIVE,
- .trigger_type[1] = THROTTLE_ACTIVE,
- .trigger_type[2] = SW_TRIP,
- .max_trigger_level = 4,
- .non_hw_trigger_levels = 3,
- .gain = 15,
- .reference_voltage = 7,
- .cal_type = TYPE_ONE_POINT_TRIMMING,
- .min_efuse_value = 40,
- .max_efuse_value = 100,
- .first_point_trim = 25,
- .second_point_trim = 85,
- .default_temp_offset = 50,
- .type = SOC_ARCH_EXYNOS4210,
- },
- },
- .tmu_count = 1,
-};
-
-#define EXYNOS3250_TMU_DATA \
- .threshold_falling = 10, \
- .trigger_levels[0] = 70, \
- .trigger_levels[1] = 95, \
- .trigger_levels[2] = 110, \
- .trigger_levels[3] = 120, \
- .trigger_enable[0] = true, \
- .trigger_enable[1] = true, \
- .trigger_enable[2] = true, \
- .trigger_enable[3] = false, \
- .trigger_type[0] = THROTTLE_ACTIVE, \
- .trigger_type[1] = THROTTLE_ACTIVE, \
- .trigger_type[2] = SW_TRIP, \
- .trigger_type[3] = HW_TRIP, \
- .max_trigger_level = 4, \
- .non_hw_trigger_levels = 3, \
- .gain = 8, \
- .reference_voltage = 16, \
- .noise_cancel_mode = 4, \
- .cal_type = TYPE_TWO_POINT_TRIMMING, \
- .efuse_value = 55, \
- .min_efuse_value = 40, \
- .max_efuse_value = 100, \
- .first_point_trim = 25, \
- .second_point_trim = 85, \
- .default_temp_offset = 50
-
-struct exynos_tmu_init_data const exynos3250_default_tmu_data = {
- .tmu_data = {
- {
- EXYNOS3250_TMU_DATA,
- .type = SOC_ARCH_EXYNOS3250,
- },
- },
- .tmu_count = 1,
-};
-
-#define EXYNOS4412_TMU_DATA \
- .threshold_falling = 10, \
- .trigger_levels[0] = 70, \
- .trigger_levels[1] = 95, \
- .trigger_levels[2] = 110, \
- .trigger_levels[3] = 120, \
- .trigger_enable[0] = true, \
- .trigger_enable[1] = true, \
- .trigger_enable[2] = true, \
- .trigger_enable[3] = false, \
- .trigger_type[0] = THROTTLE_ACTIVE, \
- .trigger_type[1] = THROTTLE_ACTIVE, \
- .trigger_type[2] = SW_TRIP, \
- .trigger_type[3] = HW_TRIP, \
- .max_trigger_level = 4, \
- .non_hw_trigger_levels = 3, \
- .gain = 8, \
- .reference_voltage = 16, \
- .noise_cancel_mode = 4, \
- .cal_type = TYPE_ONE_POINT_TRIMMING, \
- .efuse_value = 55, \
- .min_efuse_value = 40, \
- .max_efuse_value = 100, \
- .first_point_trim = 25, \
- .second_point_trim = 85, \
- .default_temp_offset = 50
-
-struct exynos_tmu_init_data const exynos4412_default_tmu_data = {
- .tmu_data = {
- {
- EXYNOS4412_TMU_DATA,
- .type = SOC_ARC
[PATCH v5 12/18] thermal: dts: exynos: Trip points and sensor configuration data for Exynos5440
This commit provides information about Exynos5440 device configuration.
Previously this information was available in exynos_tmu_data.c file.
Now it is available in the device tree.
Such approach allows reusing some common code for thermal.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- None
Changes for v3:
- "type" property removed
- "samsung,tmu_" prefix for TMU specific properties has been added
Changes for v4:
- None
Changes for v5:
- None
---
arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi | 24 ++
arch/arm/boot/dts/exynos5440-trip-points.dtsi | 25 +++
2 files changed, 49 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi
create mode 100644 arch/arm/boot/dts/exynos5440-trip-points.dtsi
diff --git a/arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi
b/arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi
new file mode 100644
index 000..7b2fba0
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi
@@ -0,0 +1,24 @@
+/*
+ * Device tree sources for Exynos5440 TMU sensor configuration
+ *
+ * Copyright (c) 2014 Lukasz Majewski
+ *
+ * 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
+
+#thermal-sensor-cells = <0>;
+samsung,tmu_gain = <5>;
+samsung,tmu_reference_voltage = <16>;
+samsung,tmu_noise_cancel_mode = <4>;
+samsung,tmu_efuse_value = <0x5d2d>;
+samsung,tmu_min_efuse_value = <16>;
+samsung,tmu_max_efuse_value = <76>;
+samsung,tmu_first_point_trim = <25>;
+samsung,tmu_second_point_trim = <70>;
+samsung,tmu_default_temp_offset = <25>;
+samsung,tmu_cal_type = ;
diff --git a/arch/arm/boot/dts/exynos5440-trip-points.dtsi
b/arch/arm/boot/dts/exynos5440-trip-points.dtsi
new file mode 100644
index 000..48adfa8
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5440-trip-points.dtsi
@@ -0,0 +1,25 @@
+/*
+ * Device tree sources for default Exynos5440 thermal zone definition
+ *
+ * Copyright (c) 2014 Lukasz Majewski
+ *
+ * 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.
+ *
+ */
+
+polling-delay-passive = <0>;
+polling-delay = <0>;
+trips {
+ cpu-alert-0 {
+ temperature = <10>; /* millicelsius */
+ hysteresis = <0>; /* millicelsius */
+ type = "active";
+ };
+ cpu-crit-0 {
+ temperature = <105>; /* millicelsius */
+ hysteresis = <0>; /* millicelsius */
+ type = "critical";
+ };
+};
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 11/18] thermal: exynos: dts: Define default thermal-zones for Exynos4
Trip points corresponding to the one defined in the exynos_tmu_data.c
for Exynos4 have been included.
This thermal-zones attribute is afterwards reused for Exynos4210, Exynos4412
and Exynos5250.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- None
---
arch/arm/boot/dts/exynos4-cpu-thermal.dtsi | 52 ++
1 file changed, 52 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos4-cpu-thermal.dtsi
diff --git a/arch/arm/boot/dts/exynos4-cpu-thermal.dtsi
b/arch/arm/boot/dts/exynos4-cpu-thermal.dtsi
new file mode 100644
index 000..506600a
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4-cpu-thermal.dtsi
@@ -0,0 +1,52 @@
+/*
+ * Device tree sources for Exynos4 thermal zone
+ *
+ * Copyright (c) 2014 Lukasz Majewski
+ *
+ * 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
+
+/ {
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ thermal-sensors = <&tmu 0>;
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ trips {
+ cpu_alert0: cpu-alert-0 {
+ temperature = <7>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+ type = "active";
+ };
+ cpu_alert1: cpu-alert-1 {
+ temperature = <95000>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+ type = "active";
+ };
+ cpu_alert2: cpu-alert-2 {
+ temperature = <11>; /* millicelsius */
+ hysteresis = <1>; /* millicelsius */
+ type = "active";
+ };
+ cpu_crit0: cpu-crit-0 {
+ temperature = <12>; /* millicelsius */
+ hysteresis = <0>; /* millicelsius */
+ type = "critical";
+ };
+ };
+ cooling-maps {
+ map0 {
+ trip = <&cpu_alert0>;
+ };
+ map1 {
+ trip = <&cpu_alert1>;
+ };
+ };
+ };
+ };
+};
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 14/18] thermal: exynos: dts: Provide device tree bindings identical to the one in exynos_tmu_data.c
Presented device tree bindings provide data already hardcoded in the
exynos_tmu_data.c file.
After this commit, it should be possible to reuse common thermal core
framework in Exynos SoCs.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- Add proper TMU entries for exynos3250.dtsi
Changes for v3:
- Remove "type" DT properties, which will be extracted from compatible
- "samsung,tmu_" prefix for TMU specific properties has been added
Changes for v4:
- Providing mandatory properties for thermal-zones (Exynos4210 and Exynos5250)
Changes for v5:
- None
---
arch/arm/boot/dts/exynos3250.dtsi | 2 ++
arch/arm/boot/dts/exynos4.dtsi| 4
arch/arm/boot/dts/exynos4210.dtsi | 25 -
arch/arm/boot/dts/exynos4x12.dtsi | 1 +
arch/arm/boot/dts/exynos5250.dtsi | 9 +++--
arch/arm/boot/dts/exynos5420.dtsi | 28
arch/arm/boot/dts/exynos5440.dtsi | 18 ++
7 files changed, 84 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 2246549..8cc078c 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -18,6 +18,7 @@
*/
#include "skeleton.dtsi"
+#include "exynos4-cpu-thermal.dtsi"
#include
/ {
@@ -188,6 +189,7 @@
interrupts = <0 216 0>;
clocks = <&cmu CLK_TMU_APBIF>;
clock-names = "tmu_apbif";
+ #include "exynos4412-tmu-sensor-conf.dtsi"
status = "disabled";
};
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index b8168f1..f18d746 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -645,4 +645,8 @@
samsung,sysreg = <&sys_reg>;
status = "disabled";
};
+
+ tmu: tmu@100C {
+ #include "exynos4412-tmu-sensor-conf.dtsi"
+ };
};
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index 2e66df8..78a43b0 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -21,6 +21,7 @@
#include "exynos4.dtsi"
#include "exynos4210-pinctrl.dtsi"
+#include "exynos4-cpu-thermal.dtsi"
/ {
compatible = "samsung,exynos4210", "samsung,exynos4";
@@ -146,16 +147,38 @@
reg = <0x0386 0x1000>;
};
- tmu@100C {
+ tmu: tmu@100C {
compatible = "samsung,exynos4210-tmu";
interrupt-parent = <&combiner>;
reg = <0x100C 0x100>;
interrupts = <2 4>;
clocks = <&clock CLK_TMU_APBIF>;
clock-names = "tmu_apbif";
+ samsung,tmu_gain = <15>;
+ samsung,tmu_reference_voltage = <7>;
status = "disabled";
};
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ thermal-sensors = <&tmu 0>;
+
+ trips {
+ cpu_alert0: cpu-alert-0 {
+ temperature = <85000>; /* millicelsius */
+ };
+ cpu_alert1: cpu-alert-1 {
+ temperature = <10>; /* millicelsius */
+ };
+ cpu_alert2: cpu-alert-2 {
+ temperature = <11>; /* millicelsius */
+ };
+ };
+ };
+ };
+
g2d@1280 {
compatible = "samsung,s5pv210-g2d";
reg = <0x1280 0x1000>;
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 93b7040..3ee2031 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -19,6 +19,7 @@
#include "exynos4.dtsi"
#include "exynos4x12-pinctrl.dtsi"
+#include "exynos4-cpu-thermal.dtsi"
/ {
aliases {
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 4641d3c..90211c0 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -20,7 +20,7 @@
#include
#include "exynos5.dtsi"
#include "exynos5250-pinctrl.dtsi"
-
+#include "exynos4-cpu-thermal.dtsi"
#include
/ {
@@ -236,16 +236,21 @@
status = "disabled";
};
- tmu@1006 {
+ tmu: tmu@1006 {
compatible = "samsung,exynos5250-tmu";
reg = <0x1006 0x100>;
interrupts = <0 65 0>;
clocks = <&clock CLK_TMU>;
clock-names = "tmu_apbif";
+ #include "exynos4412-tmu-sensor-conf.dtsi"
};
thermal-zones {
cpu_t
[PATCH v5 18/18] thermal: exynos: Remove not needed exynos_tmu_init_data declarations from exynos_tmu.h
After switching to device tree based configuration those declarations are
not needed anymore.
Reported-by: Abhilash Kesavan
Signed-off-by: Lukasz Majewski
---
Changes for v5:
- New patch
---
drivers/thermal/samsung/exynos_tmu.h | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index d876d4c..9f9b1b8 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -71,12 +71,4 @@ struct exynos_tmu_platform_data {
u32 cal_mode;
};
-extern struct exynos_tmu_init_data const exynos3250_default_tmu_data;
-extern struct exynos_tmu_init_data const exynos4210_default_tmu_data;
-extern struct exynos_tmu_init_data const exynos4412_default_tmu_data;
-extern struct exynos_tmu_init_data const exynos5250_default_tmu_data;
-extern struct exynos_tmu_init_data const exynos5260_default_tmu_data;
-extern struct exynos_tmu_init_data const exynos5420_default_tmu_data;
-extern struct exynos_tmu_init_data const exynos5440_default_tmu_data;
-
#endif /* _EXYNOS_TMU_H */
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 16/18] thermal: exynos: Remove exynos_thermal_common.[c|h] files
After defining all necessary Exynos data in the device tree and heavy
reusage of the of-thermal.c those files can be removed.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- None
---
drivers/thermal/samsung/exynos_thermal_common.c | 445
drivers/thermal/samsung/exynos_thermal_common.h | 106 --
2 files changed, 551 deletions(-)
delete mode 100644 drivers/thermal/samsung/exynos_thermal_common.c
delete mode 100644 drivers/thermal/samsung/exynos_thermal_common.h
diff --git a/drivers/thermal/samsung/exynos_thermal_common.c
b/drivers/thermal/samsung/exynos_thermal_common.c
deleted file mode 100644
index 00aa688..000
--- a/drivers/thermal/samsung/exynos_thermal_common.c
+++ /dev/null
@@ -1,445 +0,0 @@
-/*
- * exynos_thermal_common.c - Samsung EXYNOS common thermal file
- *
- * Copyright (C) 2013 Samsung Electronics
- * Amit Daniel Kachhap
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- *
- */
-
-#include
-#include
-#include
-#include
-
-#include "exynos_thermal_common.h"
-
-struct exynos_thermal_zone {
- enum thermal_device_mode mode;
- struct thermal_zone_device *therm_dev;
- struct thermal_cooling_device *cool_dev[MAX_COOLING_DEVICE];
- unsigned int cool_dev_size;
- struct platform_device *exynos4_dev;
- struct thermal_sensor_conf *sensor_conf;
- bool bind;
-};
-
-/* Get mode callback functions for thermal zone */
-static int exynos_get_mode(struct thermal_zone_device *thermal,
- enum thermal_device_mode *mode)
-{
- struct exynos_thermal_zone *th_zone = thermal->devdata;
- if (th_zone)
- *mode = th_zone->mode;
- return 0;
-}
-
-/* Set mode callback functions for thermal zone */
-static int exynos_set_mode(struct thermal_zone_device *thermal,
- enum thermal_device_mode mode)
-{
- struct exynos_thermal_zone *th_zone = thermal->devdata;
- if (!th_zone) {
- dev_err(&thermal->device,
- "thermal zone not registered\n");
- return 0;
- }
-
- mutex_lock(&thermal->lock);
-
- if (mode == THERMAL_DEVICE_ENABLED &&
- !th_zone->sensor_conf->trip_data.trigger_falling)
- thermal->polling_delay = IDLE_INTERVAL;
- else
- thermal->polling_delay = 0;
-
- mutex_unlock(&thermal->lock);
-
- th_zone->mode = mode;
- thermal_zone_device_update(thermal);
- dev_dbg(th_zone->sensor_conf->dev,
- "thermal polling set for duration=%d msec\n",
- thermal->polling_delay);
- return 0;
-}
-
-
-/* Get trip type callback functions for thermal zone */
-static int exynos_get_trip_type(struct thermal_zone_device *thermal, int trip,
-enum thermal_trip_type *type)
-{
- struct exynos_thermal_zone *th_zone = thermal->devdata;
- int max_trip = th_zone->sensor_conf->trip_data.trip_count;
- int trip_type;
-
- if (trip < 0 || trip >= max_trip)
- return -EINVAL;
-
- trip_type = th_zone->sensor_conf->trip_data.trip_type[trip];
-
- if (trip_type == SW_TRIP)
- *type = THERMAL_TRIP_CRITICAL;
- else if (trip_type == THROTTLE_ACTIVE)
- *type = THERMAL_TRIP_ACTIVE;
- else if (trip_type == THROTTLE_PASSIVE)
- *type = THERMAL_TRIP_PASSIVE;
- else
- return -EINVAL;
-
- return 0;
-}
-
-/* Get trip temperature callback functions for thermal zone */
-static int exynos_get_trip_temp(struct thermal_zone_device *thermal, int trip,
- unsigned long *temp)
-{
- struct exynos_thermal_zone *th_zone = thermal->devdata;
- int max_trip = th_zone->sensor_conf->trip_data.trip_count;
-
- if (trip < 0 || trip >= max_trip)
- return -EINVAL;
-
- *temp = th_zone->sensor_conf->trip_data.trip_val[trip];
- /* convert the temperature into millicelsius */
- *temp = *temp * MCELSIUS;
-
- return 0;
-}
-
-/* Get critical temperature callback functions for thermal zone */
-static int exynos_get_crit_temp(struct thermal_zone_device *thermal,
-
[PATCH v5 13/18] dts: Documentation: Update exynos-thermal.txt example for Exynos5440
Updating exynos-thermal.txt documentation entry for Exynos5440 Signed-off-by: Lukasz Majewski --- Changes for v4: - New patch Changes for v5: - None --- Documentation/devicetree/bindings/thermal/exynos-thermal.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt index 8497794..0f44932 100644 --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt @@ -74,6 +74,7 @@ Example 2): interrupts = <0 58 0>; clocks = <&clock 21>; clock-names = "tmu_apbif"; + #include "exynos5440-tmu-sensor-conf.dtsi" }; Example 3): (In case of Exynos5420 "with misplaced TRIMINFO register") -- 2.0.0.rc2 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 15/18] thermal: samsung: core: Exynos TMU rework to use device tree for configuration
This patch brings support for providing configuration via device tree.
Previously this data has been hardcoded in the exynos_tmu_data.c file.
Such approach was not scalable and very often required copying the whole
data.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- Adjust exynos_tmu.c code to the newest ti-soc-thermal repository
- Usage of of-thermal.c exported trip points table
Changes for v3:
- Adding exynos_of_get_soc_type() method to set SOC type from device's
compatible string
- "samsung,tmu_" prefix for TMU specific properties has been added
Changes for v4:
- None
Changes for v5:
- Remove duplicated exynos_tmu_initialize() - reported by Abhilash Kesavan
---
drivers/thermal/samsung/Makefile | 2 -
drivers/thermal/samsung/exynos_tmu.c | 339 ++-
drivers/thermal/samsung/exynos_tmu.h | 53 +-
3 files changed, 220 insertions(+), 174 deletions(-)
diff --git a/drivers/thermal/samsung/Makefile b/drivers/thermal/samsung/Makefile
index c09d830..1e47d0d 100644
--- a/drivers/thermal/samsung/Makefile
+++ b/drivers/thermal/samsung/Makefile
@@ -3,5 +3,3 @@
#
obj-$(CONFIG_EXYNOS_THERMAL) += exynos_thermal.o
exynos_thermal-y := exynos_tmu.o
-exynos_thermal-y += exynos_tmu_data.o
-exynos_thermal-$(CONFIG_EXYNOS_THERMAL_CORE) += exynos_thermal_common.o
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index ae30f6a..9d2d685 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -1,6 +1,10 @@
/*
* exynos_tmu.c - Samsung EXYNOS TMU (Thermal Management Unit)
*
+ * Copyright (C) 2014 Samsung Electronics
+ * Bartlomiej Zolnierkiewicz
+ * Lukasz Majewski
+ *
* Copyright (C) 2011 Samsung Electronics
* Donggeun Kim
* Amit Daniel Kachhap
@@ -31,8 +35,8 @@
#include
#include
-#include "exynos_thermal_common.h"
#include "exynos_tmu.h"
+#include "../thermal_core.h"
/* Exynos generic registers */
#define EXYNOS_TMU_REG_TRIMINFO0x0
@@ -115,6 +119,7 @@
#define EXYNOS5440_TMU_TH_RISE4_SHIFT 24
#define EXYNOS5440_EFUSE_SWAP_OFFSET 8
+#define MCELSIUS 1000
/**
* struct exynos_tmu_data : A structure to hold the private data of the TMU
driver
@@ -150,7 +155,8 @@ struct exynos_tmu_data {
struct clk *clk, *clk_sec;
u8 temp_error1, temp_error2;
struct regulator *regulator;
- struct thermal_sensor_conf *reg_conf;
+ struct thermal_zone_device *tzd;
+
int (*tmu_initialize)(struct platform_device *pdev);
void (*tmu_control)(struct platform_device *pdev, bool on);
int (*tmu_read)(struct exynos_tmu_data *data);
@@ -159,6 +165,33 @@ struct exynos_tmu_data {
void (*tmu_clear_irqs)(struct exynos_tmu_data *data);
};
+static void exynos_report_trigger(struct exynos_tmu_data *p)
+{
+ char data[10], *envp[] = { data, NULL };
+ struct thermal_zone_device *tz = p->tzd;
+ unsigned long temp;
+ unsigned int i;
+
+ if (!p) {
+ pr_err("Wrong temperature configuration data\n");
+ return;
+ }
+
+ thermal_zone_device_update(tz);
+
+ mutex_lock(&tz->lock);
+ /* Find the level for which trip happened */
+ for (i = 0; i < of_thermal_get_ntrips(tz); i++) {
+ tz->ops->get_trip_temp(tz, i, &temp);
+ if (tz->last_temperature < temp)
+ break;
+ }
+
+ snprintf(data, sizeof(data), "%u", i);
+ kobject_uevent_env(&tz->device.kobj, KOBJ_CHANGE, envp);
+ mutex_unlock(&tz->lock);
+}
+
/*
* TMU treats temperature as a mapped temperature code.
* The temperature is converted differently depending on the calibration type.
@@ -234,14 +267,25 @@ static void sanitize_temp_error(struct exynos_tmu_data
*data, u32 trim_info)
static u32 get_th_reg(struct exynos_tmu_data *data, u32 threshold, bool
falling)
{
- struct exynos_tmu_platform_data *pdata = data->pdata;
+ struct thermal_zone_device *tz = data->tzd;
+ const struct thermal_trip * const trips =
+ of_thermal_get_trip_points(tz);
+ unsigned long temp;
int i;
- for (i = 0; i < pdata->non_hw_trigger_levels; i++) {
- u8 temp = pdata->trigger_levels[i];
+ if (!trips) {
+ pr_err("%s: Cannot get trip points from of-thermal.c!\n",
+ __func__);
+ return 0;
+ }
+ for (i = 0; i < of_thermal_get_ntrips(tz); i++) {
+ if (trips[i].type == THERMAL_TRIP_CRITICAL)
+ continue;
+
+ temp = trips[i].temperature / MCELSIUS;
if (falling)
- temp -= pdata->threshold_falling;
+ temp -= (trips[i].hysteresis / MCELSIUS);
else
threshold
[PATCH v5 06/18] arm: dts: Adding CPU cooling binding for Exynos SoCs
Presented patch aims to move data necessary for correct CPU cooling device
configuration from exynos_tmu_data.c to device tree.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- None
Changes for v3:
- Adjust CPU's DT nodes to work with newest ti-soc-thermal/next branch
- Patch title has been changed from "thermal: cpu_cooling: dts: ..."
Changes for v4:
- Spaces and tabs cleanup
Changes for v5:
- None
---
arch/arm/boot/dts/exynos4210-trats.dts | 15 +++
arch/arm/boot/dts/exynos4210.dtsi | 5 -
arch/arm/boot/dts/exynos4212.dtsi | 5 -
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 15 +++
arch/arm/boot/dts/exynos4412-trats2.dts | 15 +++
arch/arm/boot/dts/exynos4412.dtsi | 5 -
arch/arm/boot/dts/exynos5250.dtsi | 20 +++-
7 files changed, 76 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/arch/arm/boot/dts/exynos4210-trats.dts
index 61009f4..e3879c0 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -428,6 +428,21 @@
status = "okay";
};
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ cooling-maps {
+ map0 {
+/* Corresponds to 800MHz at freq_table */
+cooling-device = <&cpu0 2 2>;
+ };
+ map1 {
+/* Corresponds to 200MHz at freq_table */
+cooling-device = <&cpu0 4 4>;
+ };
+ };
+ };
+ };
+
camera {
pinctrl-names = "default";
pinctrl-0 = <>;
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index bcc9e63..2e66df8 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -35,10 +35,13 @@
#address-cells = <1>;
#size-cells = <0>;
- cpu@900 {
+ cpu0: cpu@900 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0x900>;
+ cooling-min-level = <4>;
+ cooling-max-level = <2>;
+ #cooling-cells = <2>; /* min followed by max */
};
cpu@901 {
diff --git a/arch/arm/boot/dts/exynos4212.dtsi
b/arch/arm/boot/dts/exynos4212.dtsi
index dd0a43e..5be03288 100644
--- a/arch/arm/boot/dts/exynos4212.dtsi
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -26,10 +26,13 @@
#address-cells = <1>;
#size-cells = <0>;
- cpu@A00 {
+ cpu0: cpu@A00 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0xA00>;
+ cooling-min-level = <13>;
+ cooling-max-level = <7>;
+ #cooling-cells = <2>; /* min followed by max */
};
cpu@A01 {
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index c7517fc..25b4f7d 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -401,6 +401,21 @@
vtmu-supply = <&ldo10_reg>;
status = "okay";
};
+
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ cooling-maps {
+ map0 {
+/* Corresponds to 800MHz at freq_table */
+cooling-device = <&cpu0 7 7>;
+ };
+ map1 {
+/* Corresponds to 200MHz at freq_table */
+cooling-device = <&cpu0 13 13>;
+ };
+ };
+ };
+ };
};
&pinctrl_1 {
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 29231b4..52a7771 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -863,6 +863,21 @@
pulldown-ohm = <10>; /* 100K */
io-channels = <&adc 2>; /* Battery temperature */
};
+
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ cooling-maps {
+ map0 {
+/* Corresponds to 800MHz at freq_table */
+cooling-device = <&cpu0 7 7>;
+ };
+
[PATCH v5 05/18] arm: dts: odroid: Enable TMU at Exynos4412 based Odroid U3 device
This commit enables TMU IP block on the Exynos4412 Odroid U3
device.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- Rename patch title from "thermal: dts:" to "arm: dts: odroid"
Changes for v5:
- None
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 0adb57c..c7517fc 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -396,6 +396,11 @@
ehci: ehci@1258 {
status = "okay";
};
+
+ tmu@100C {
+ vtmu-supply = <&ldo10_reg>;
+ status = "okay";
+ };
};
&pinctrl_1 {
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 03/18] arm: dts: trats: Enable TMU on the Exynos4210 trats device
The thermal IP block (Thermal Management Unit) called TMU has been enabled
in this device.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- None
Changes for v3:
- Patch title has been changed from thermal: dts: arm to arm: dts: trats
Changes for v4:
- None
Changes for v5:
- None
---
arch/arm/boot/dts/exynos4210-trats.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/arch/arm/boot/dts/exynos4210-trats.dts
index 7208362..61009f4 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -424,6 +424,10 @@
status = "okay";
};
+ tmu@100C {
+ status = "okay";
+ };
+
camera {
pinctrl-names = "default";
pinctrl-0 = <>;
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 02/18] thermal: exynos: Provide thermal_exynos.h file to be included in device tree files
This patch is a preparatory patch to be able to read Exynos thermal
configuration from the device tree.
It turned out that DTC is not able to interpret enums properly and hence
it is necessary to #define those values explicitly.
For this reason the ./include/dt-bindings/thermal/thermal_exynos.h file
has been introduced.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- None
Changes for v3:
- Restore 'enum soc_type type' since TMU sensor type will be extracted from
device tree compatible
Changes for v4:
- None
Changes for v5:
- None
---
drivers/thermal/samsung/exynos_tmu.h | 12 +++-
include/dt-bindings/thermal/thermal_exynos.h | 28
2 files changed, 31 insertions(+), 9 deletions(-)
create mode 100644 include/dt-bindings/thermal/thermal_exynos.h
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index da3009b..7f880d2 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -26,14 +26,6 @@
#include "exynos_thermal_common.h"
-enum calibration_type {
- TYPE_ONE_POINT_TRIMMING,
- TYPE_ONE_POINT_TRIMMING_25,
- TYPE_ONE_POINT_TRIMMING_85,
- TYPE_TWO_POINT_TRIMMING,
- TYPE_NONE,
-};
-
enum soc_type {
SOC_ARCH_EXYNOS3250 = 1,
SOC_ARCH_EXYNOS4210,
@@ -44,6 +36,7 @@ enum soc_type {
SOC_ARCH_EXYNOS5420_TRIMINFO,
SOC_ARCH_EXYNOS5440,
};
+#include
/**
* struct exynos_tmu_platform_data
@@ -115,8 +108,9 @@ struct exynos_tmu_platform_data {
u8 second_point_trim;
u8 default_temp_offset;
- enum calibration_type cal_type;
enum soc_type type;
+ u32 cal_type;
+ u32 cal_mode;
struct freq_clip_table freq_tab[4];
unsigned int freq_tab_count;
};
diff --git a/include/dt-bindings/thermal/thermal_exynos.h
b/include/dt-bindings/thermal/thermal_exynos.h
new file mode 100644
index 000..0646500
--- /dev/null
+++ b/include/dt-bindings/thermal/thermal_exynos.h
@@ -0,0 +1,28 @@
+/*
+ * thermal_exynos.h - Samsung EXYNOS TMU device tree definitions
+ *
+ * Copyright (C) 2014 Samsung Electronics
+ * Lukasz Majewski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef _EXYNOS_THERMAL_TMU_DT_H
+#define _EXYNOS_THERMAL_TMU_DT_H
+
+#define TYPE_ONE_POINT_TRIMMING 0
+#define TYPE_ONE_POINT_TRIMMING_25 1
+#define TYPE_ONE_POINT_TRIMMING_85 2
+#define TYPE_TWO_POINT_TRIMMING 3
+#define TYPE_NONE 4
+
+#endif /* _EXYNOS_THERMAL_TMU_DT_H */
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 01/18] thermal: exynos: cosmetic: Correct comment format
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- None
---
drivers/thermal/samsung/exynos_tmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index d2f1e62..5000727 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -576,7 +576,7 @@ out:
#define exynos5440_tmu_set_emulation NULL
static int exynos_tmu_set_emulation(void *drv_data,unsigned long temp)
{ return -EINVAL; }
-#endif/*CONFIG_THERMAL_EMULATION*/
+#endif /* CONFIG_THERMAL_EMULATION */
static int exynos4210_tmu_read(struct exynos_tmu_data *data)
{
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 00/18] thermal: exynos: Thermal code rework to use device tree
1. Introduction Following patches aim to clean up the current implementation of the thermal framework on Exynos devices. The main goal was to use a generic code for reading thermal configuration (of-thermal.c). Due to that redundant exynos_thermal_common.[h|c] files were removed. Around 400 lines of code (LOC) were removed directly by this patch, which is around 20% of the Exynos thermal code base. This work should NOT bring any functional changes to Exynos thermal subsystem. 2. Patch-set structure Then the cpu_cooling functionality has been preserved to allow cooling devices by reducing operating frequency. Definition of trip points and cpufreq's cooling properties were moved to device tree. Then the rework of the way in which configuration data is provided to the Exynos thermal subsystem was performed. Now device tree is used for configuration. 3. Dead code removal Thermal support for some SoCs, previously available in the exynos_tmu_data.c file, was removed since, as of (almost) 3.19-rc3, they didn't have TMU bindings. Moreover, support for cpu_cooling devices was preserved only on those SoCs which had available and working cpufreq driver. 4. Testing Test devices: - Exynos4210 - Trats (TMU zone + cpu_cooling) - Exynos4412 - Trats2/Odroid U3 (TMU zone + cpu_cooling) - Exynos5250 - Arndale (TMU zone + cpu_cooling) - Exynos5420 - Arndale-octa (only TMU zones) Unfortunately, I don't posses Exynos5440 for testing. Its functionality has been preserved in the code, but not tested on the hardware. I would be grateful for help in testing. 5. This work apply on the following tree: kernel.org: 'linux-soc-thermal/next' - Eduardo Velentin's tree SHA1: 1813d80874699145f04af6b05ebab0a6419001fb Lukasz Majewski (18): thermal: exynos: cosmetic: Correct comment format thermal: exynos: Provide thermal_exynos.h file to be included in device tree files arm: dts: trats: Enable TMU on the Exynos4210 trats device arm: dts: odroid: Add LDO10 regulator node necessary for TMU on Odroid arm: dts: odroid: Enable TMU at Exynos4412 based Odroid U3 device arm: dts: Adding CPU cooling binding for Exynos SoCs thermal: exynos: Modify exynos thermal code to use device tree for cpu cooling configuration thermal: exynos: dts: Add default definition of the TMU sensor parameter dts: Documentation: Extending documentation entry for exynos-thermal thermal: dts: Default trip points definition for Exynos5420 SoCs thermal: exynos: dts: Define default thermal-zones for Exynos4 thermal: dts: exynos: Trip points and sensor configuration data for Exynos5440 dts: Documentation: Update exynos-thermal.txt example for Exynos5440 thermal: exynos: dts: Provide device tree bindings identical to the one in exynos_tmu_data.c thermal: samsung: core: Exynos TMU rework to use device tree for configuration thermal: exynos: Remove exynos_thermal_common.[c|h] files thermal: exynos: Remove exynos_tmu_data.c file thermal: exynos: Remove not needed exynos_tmu_init_data declarations from exynos_tmu.h .../devicetree/bindings/thermal/exynos-thermal.txt | 17 + arch/arm/boot/dts/exynos3250.dtsi | 2 + arch/arm/boot/dts/exynos4-cpu-thermal.dtsi | 52 +++ arch/arm/boot/dts/exynos4.dtsi | 4 + arch/arm/boot/dts/exynos4210-trats.dts | 19 + arch/arm/boot/dts/exynos4210.dtsi | 30 +- arch/arm/boot/dts/exynos4212.dtsi | 5 +- arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 27 ++ arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi | 24 ++ arch/arm/boot/dts/exynos4412-trats2.dts| 15 + arch/arm/boot/dts/exynos4412.dtsi | 5 +- arch/arm/boot/dts/exynos4x12.dtsi | 1 + arch/arm/boot/dts/exynos5250.dtsi | 29 +- arch/arm/boot/dts/exynos5420-trip-points.dtsi | 35 ++ arch/arm/boot/dts/exynos5420.dtsi | 28 ++ arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi | 24 ++ arch/arm/boot/dts/exynos5440-trip-points.dtsi | 25 ++ arch/arm/boot/dts/exynos5440.dtsi | 18 + drivers/cpufreq/exynos-cpufreq.c | 30 +- drivers/thermal/samsung/Makefile | 2 - drivers/thermal/samsung/exynos_thermal_common.c| 427 - drivers/thermal/samsung/exynos_thermal_common.h| 106 - drivers/thermal/samsung/exynos_tmu.c | 348 +++-- drivers/thermal/samsung/exynos_tmu.h | 76 +--- drivers/thermal/samsung/exynos_tmu_data.c | 264 - include/dt-bindings/thermal/thermal_exynos.h | 28 ++ 26 files changed, 632 insertions(+), 1009 deletions(-) create mode 100644 arch/arm/boot/dts/exynos4-cpu-thermal.dtsi create mode 100644 arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi create mode 100644 arch/arm/boot/dts/exynos5420-trip-points.dtsi create mode 100644 arch/arm/boot/dts/ex
Re: [PATCH v4 14/21] ARM: imx6: convert GPC to stacked domains
On 19/01/15 10:47, Lucas Stach wrote:
> Am Montag, den 19.01.2015, 09:44 + schrieb Marc Zyngier:
>> IMX6 has been (ab)using the gic_arch_extn to provide
>> wakeup from suspend, and it makes a lot of sense to convert
>> this code to use stacked domains instead.
>>
>> This patch does just this, updating the DT files to actually
>> reflect what the HW provides.
>>
>> BIG FAT WARNING: because the DTs were so far lying by not
>> exposing the fact that the GPC block is actually the first
>> interrupt controller in the chain, kernels with this patch
>> applied wont have any suspend-resume facility when booted
>> with old DTs, and old kernels with updated DTs won't even boot.
>>
>> Tested-by: Stefan Agner
>> Acked-by: Stefan Agner
>> Signed-off-by: Marc Zyngier
>> ---
>> arch/arm/boot/dts/imx6qdl.dtsi | 7 ++-
>> arch/arm/boot/dts/imx6sl.dtsi | 6 +-
>> arch/arm/boot/dts/imx6sx.dtsi | 6 +-
>> arch/arm/mach-imx/common.h | 1 -
>> arch/arm/mach-imx/gpc.c | 127
>>
>> arch/arm/mach-imx/mach-imx6q.c | 1 -
>> arch/arm/mach-imx/mach-imx6sl.c | 1 -
>> arch/arm/mach-imx/mach-imx6sx.c | 1 -
>> 8 files changed, 119 insertions(+), 31 deletions(-)
>>
> [...]
>
>> --- a/arch/arm/mach-imx/common.h
>> +++ b/arch/arm/mach-imx/common.h
>> @@ -102,7 +102,6 @@ static inline void imx_scu_map_io(void) {}
>> static inline void imx_smp_prepare(void) {}
>> #endif
>> void imx_src_init(void);
>> -void imx_gpc_init(void);
>> void imx_gpc_pre_suspend(bool arm_power_off);
>> void imx_gpc_post_resume(void);
>> void imx_gpc_mask_all(void);
>> diff --git a/arch/arm/mach-imx/gpc.c b/arch/arm/mach-imx/gpc.c
>> index 5f3602e..838da3c 100644
>> --- a/arch/arm/mach-imx/gpc.c
>> +++ b/arch/arm/mach-imx/gpc.c
>> @@ -22,6 +22,7 @@
>> #define GPC_PGC_CPU_PDN 0x2a0
>>
>> #define IMR_NUM 4
>> +#define GPC_MAX_IRQS(IMR_NUM * 32)
>>
>> static void __iomem *gpc_base;
>> static u32 gpc_wake_irqs[IMR_NUM];
>> @@ -56,17 +57,17 @@ void imx_gpc_post_resume(void)
>>
>> static int imx_gpc_irq_set_wake(struct irq_data *d, unsigned int on)
>> {
>> -unsigned int idx = d->hwirq / 32 - 1;
>> +unsigned int idx = d->hwirq / 32;
>> u32 mask;
>>
>> -/* Sanity check for SPI irq */
>> -if (d->hwirq < 32)
>> -return -EINVAL;
>> -
>> mask = 1 << d->hwirq % 32;
>> gpc_wake_irqs[idx] = on ? gpc_wake_irqs[idx] | mask :
>>gpc_wake_irqs[idx] & ~mask;
>>
>> +/*
>> + * Do *not* call into the parent, as the GIC doesn't have any
>> + * wake-up facility...
>> + */
>> return 0;
>> }
>>
>> @@ -96,7 +97,7 @@ void imx_gpc_hwirq_unmask(unsigned int hwirq)
>> void __iomem *reg;
>> u32 val;
>>
>> -reg = gpc_base + GPC_IMR1 + (hwirq / 32 - 1) * 4;
>> +reg = gpc_base + GPC_IMR1 + hwirq / 32 * 4;
>> val = readl_relaxed(reg);
>> val &= ~(1 << hwirq % 32);
>> writel_relaxed(val, reg);
>> @@ -107,7 +108,7 @@ void imx_gpc_hwirq_mask(unsigned int hwirq)
>> void __iomem *reg;
>> u32 val;
>>
>> -reg = gpc_base + GPC_IMR1 + (hwirq / 32 - 1) * 4;
>> +reg = gpc_base + GPC_IMR1 + hwirq / 32 * 4;
>> val = readl_relaxed(reg);
>> val |= 1 << (hwirq % 32);
>> writel_relaxed(val, reg);
>> @@ -115,37 +116,115 @@ void imx_gpc_hwirq_mask(unsigned int hwirq)
>>
>> static void imx_gpc_irq_unmask(struct irq_data *d)
>> {
>> -/* Sanity check for SPI irq */
>> -if (d->hwirq < 32)
>> -return;
>> -
>> imx_gpc_hwirq_unmask(d->hwirq);
>> +irq_chip_unmask_parent(d);
>> }
>>
>> static void imx_gpc_irq_mask(struct irq_data *d)
>> {
>> -/* Sanity check for SPI irq */
>> -if (d->hwirq < 32)
>> -return;
>> -
>> imx_gpc_hwirq_mask(d->hwirq);
>> +irq_chip_mask_parent(d);
>> +}
>> +
>> +static struct irq_chip imx_gpc_chip = {
>> +.name = "GPC",
>> +.irq_eoi= irq_chip_eoi_parent,
>> +.irq_mask = imx_gpc_irq_mask,
>> +.irq_unmask = imx_gpc_irq_unmask,
>> +.irq_retrigger = irq_chip_retrigger_hierarchy,
>> +.irq_set_wake = imx_gpc_irq_set_wake,
>> +};
>> +
>> +static int imx_gpc_domain_xlate(struct irq_domain *domain,
>> +struct device_node *controller,
>> +const u32 *intspec,
>> +unsigned int intsize,
>> +unsigned long *out_hwirq,
>> +unsigned int *out_type)
>> +{
>> +if (domain->of_node != controller)
>> +return -EINVAL; /* Shouldn't happen, really... */
>> +if (intsize != 3)
>> +return -EINVAL; /* Not GIC compliant */
>> +if (intspec[0] != 0)
>> +return -EINVAL; /* No PPI should point to this domain */
>> +
>> +*out_hwirq = intspec[1];
>> +*out_type = intspec[2];
>> +return 0;
>> +}
>> +
>> +static
Re: [PATCH v4 14/21] ARM: imx6: convert GPC to stacked domains
Am Montag, den 19.01.2015, 09:44 + schrieb Marc Zyngier:
> IMX6 has been (ab)using the gic_arch_extn to provide
> wakeup from suspend, and it makes a lot of sense to convert
> this code to use stacked domains instead.
>
> This patch does just this, updating the DT files to actually
> reflect what the HW provides.
>
> BIG FAT WARNING: because the DTs were so far lying by not
> exposing the fact that the GPC block is actually the first
> interrupt controller in the chain, kernels with this patch
> applied wont have any suspend-resume facility when booted
> with old DTs, and old kernels with updated DTs won't even boot.
>
> Tested-by: Stefan Agner
> Acked-by: Stefan Agner
> Signed-off-by: Marc Zyngier
> ---
> arch/arm/boot/dts/imx6qdl.dtsi | 7 ++-
> arch/arm/boot/dts/imx6sl.dtsi | 6 +-
> arch/arm/boot/dts/imx6sx.dtsi | 6 +-
> arch/arm/mach-imx/common.h | 1 -
> arch/arm/mach-imx/gpc.c | 127
>
> arch/arm/mach-imx/mach-imx6q.c | 1 -
> arch/arm/mach-imx/mach-imx6sl.c | 1 -
> arch/arm/mach-imx/mach-imx6sx.c | 1 -
> 8 files changed, 119 insertions(+), 31 deletions(-)
>
[...]
> --- a/arch/arm/mach-imx/common.h
> +++ b/arch/arm/mach-imx/common.h
> @@ -102,7 +102,6 @@ static inline void imx_scu_map_io(void) {}
> static inline void imx_smp_prepare(void) {}
> #endif
> void imx_src_init(void);
> -void imx_gpc_init(void);
> void imx_gpc_pre_suspend(bool arm_power_off);
> void imx_gpc_post_resume(void);
> void imx_gpc_mask_all(void);
> diff --git a/arch/arm/mach-imx/gpc.c b/arch/arm/mach-imx/gpc.c
> index 5f3602e..838da3c 100644
> --- a/arch/arm/mach-imx/gpc.c
> +++ b/arch/arm/mach-imx/gpc.c
> @@ -22,6 +22,7 @@
> #define GPC_PGC_CPU_PDN 0x2a0
>
> #define IMR_NUM 4
> +#define GPC_MAX_IRQS (IMR_NUM * 32)
>
> static void __iomem *gpc_base;
> static u32 gpc_wake_irqs[IMR_NUM];
> @@ -56,17 +57,17 @@ void imx_gpc_post_resume(void)
>
> static int imx_gpc_irq_set_wake(struct irq_data *d, unsigned int on)
> {
> - unsigned int idx = d->hwirq / 32 - 1;
> + unsigned int idx = d->hwirq / 32;
> u32 mask;
>
> - /* Sanity check for SPI irq */
> - if (d->hwirq < 32)
> - return -EINVAL;
> -
> mask = 1 << d->hwirq % 32;
> gpc_wake_irqs[idx] = on ? gpc_wake_irqs[idx] | mask :
> gpc_wake_irqs[idx] & ~mask;
>
> + /*
> + * Do *not* call into the parent, as the GIC doesn't have any
> + * wake-up facility...
> + */
> return 0;
> }
>
> @@ -96,7 +97,7 @@ void imx_gpc_hwirq_unmask(unsigned int hwirq)
> void __iomem *reg;
> u32 val;
>
> - reg = gpc_base + GPC_IMR1 + (hwirq / 32 - 1) * 4;
> + reg = gpc_base + GPC_IMR1 + hwirq / 32 * 4;
> val = readl_relaxed(reg);
> val &= ~(1 << hwirq % 32);
> writel_relaxed(val, reg);
> @@ -107,7 +108,7 @@ void imx_gpc_hwirq_mask(unsigned int hwirq)
> void __iomem *reg;
> u32 val;
>
> - reg = gpc_base + GPC_IMR1 + (hwirq / 32 - 1) * 4;
> + reg = gpc_base + GPC_IMR1 + hwirq / 32 * 4;
> val = readl_relaxed(reg);
> val |= 1 << (hwirq % 32);
> writel_relaxed(val, reg);
> @@ -115,37 +116,115 @@ void imx_gpc_hwirq_mask(unsigned int hwirq)
>
> static void imx_gpc_irq_unmask(struct irq_data *d)
> {
> - /* Sanity check for SPI irq */
> - if (d->hwirq < 32)
> - return;
> -
> imx_gpc_hwirq_unmask(d->hwirq);
> + irq_chip_unmask_parent(d);
> }
>
> static void imx_gpc_irq_mask(struct irq_data *d)
> {
> - /* Sanity check for SPI irq */
> - if (d->hwirq < 32)
> - return;
> -
> imx_gpc_hwirq_mask(d->hwirq);
> + irq_chip_mask_parent(d);
> +}
> +
> +static struct irq_chip imx_gpc_chip = {
> + .name = "GPC",
> + .irq_eoi= irq_chip_eoi_parent,
> + .irq_mask = imx_gpc_irq_mask,
> + .irq_unmask = imx_gpc_irq_unmask,
> + .irq_retrigger = irq_chip_retrigger_hierarchy,
> + .irq_set_wake = imx_gpc_irq_set_wake,
> +};
> +
> +static int imx_gpc_domain_xlate(struct irq_domain *domain,
> + struct device_node *controller,
> + const u32 *intspec,
> + unsigned int intsize,
> + unsigned long *out_hwirq,
> + unsigned int *out_type)
> +{
> + if (domain->of_node != controller)
> + return -EINVAL; /* Shouldn't happen, really... */
> + if (intsize != 3)
> + return -EINVAL; /* Not GIC compliant */
> + if (intspec[0] != 0)
> + return -EINVAL; /* No PPI should point to this domain */
> +
> + *out_hwirq = intspec[1];
> + *out_type = intspec[2];
> + return 0;
> +}
> +
> +static int imx_gpc_domain_alloc(struct irq_domain *domain,
> + unsigned int irq,
> +
[PATCH 4/4] ASoC: samsung: remove outdated Kconfig references
The Kconfig symbols MACH_SMDKC110 and MACH_SMDKV210 were removed in v3.17. But the Kconfig entries for SND_SOC_SAMSUNG_SMDK_WM8580 and SND_SOC_SAMSUNG_SMDK_WM9713 still reference them. Perhaps these references to those removed symbols should be changed into references to an existing symbol (such as MACH_S5PV210_DT). But apparently no one noticed that these references were pointless ever since v3.17. So it seems they can simply be removed. Let's do that now. Signed-off-by: Paul Bolle --- sound/soc/samsung/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig index 5f983d064920..01980bb2c6e7 100644 --- a/sound/soc/samsung/Kconfig +++ b/sound/soc/samsung/Kconfig @@ -53,7 +53,7 @@ config SND_SOC_SAMSUNG_JIVE_WM8750 config SND_SOC_SAMSUNG_SMDK_WM8580 tristate "SoC I2S Audio support for WM8580 on SMDK" - depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKV210 || MACH_SMDKC110) + depends on SND_SOC_SAMSUNG && MACH_SMDK6410 depends on REGMAP_I2C select SND_SOC_WM8580 select SND_SAMSUNG_I2S @@ -134,7 +134,7 @@ config SND_SOC_SAMSUNG_RX1950_UDA1380 config SND_SOC_SAMSUNG_SMDK_WM9713 tristate "SoC AC97 Audio support for SMDK with WM9713" - depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKV210 || MACH_SMDKC110) + depends on SND_SOC_SAMSUNG && MACH_SMDK6410 select SND_SOC_WM9713 select SND_SAMSUNG_AC97 help -- 1.9.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
[PATCH 2/4] ASoC: samsung: Remove PCM support for WM8580 on SMDK
Commit 28c8331d386a ("ARM: S5PV210: Remove support for board files")
removed the Kconfig symbols MACH_SMDKC110 and MACH_SMDKV210. As a result
the dependencies of SND_SOC_SMDK_WM8580_PCM can never be met. So remove
the unbuildable "SoC PCM Audio support for WM8580 on SMDK".
Signed-off-by: Paul Bolle
---
Suggested by Arnd Bergmann (see https://lkml.org/lkml/2014/9/4/381 ).
Previously submitted in https://lkml.org/lkml/2014/9/18/147 , but again
in an awkward way. So this is a resend too.
sound/soc/samsung/Kconfig | 9 --
sound/soc/samsung/Makefile | 2 -
sound/soc/samsung/smdk_wm8580pcm.c | 176 -
3 files changed, 187 deletions(-)
delete mode 100644 sound/soc/samsung/smdk_wm8580pcm.c
diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index da6d0229cfa2..3be649098b30 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -153,15 +153,6 @@ config SND_SOC_SAMSUNG_SMDK_SPDIF
help
Say Y if you want to add support for SoC S/PDIF audio on the SMDK.
-config SND_SOC_SMDK_WM8580_PCM
- tristate "SoC PCM Audio support for WM8580 on SMDK"
- depends on SND_SOC_SAMSUNG && (MACH_SMDKV210 || MACH_SMDKC110)
- depends on REGMAP_I2C
- select SND_SOC_WM8580
- select SND_SAMSUNG_PCM
- help
- Say Y if you want to add support for SoC audio on the SMDK.
-
config SND_SOC_SMDK_WM8994_PCM
tristate "SoC PCM Audio support for WM8994 on SMDK"
depends on SND_SOC_SAMSUNG
diff --git a/sound/soc/samsung/Makefile b/sound/soc/samsung/Makefile
index 052fe71be518..2b32c371da55 100644
--- a/sound/soc/samsung/Makefile
+++ b/sound/soc/samsung/Makefile
@@ -36,7 +36,6 @@ snd-soc-snow-objs := snow.o
snd-soc-smdk-wm9713-objs := smdk_wm9713.o
snd-soc-s3c64xx-smartq-wm8987-objs := smartq_wm8987.o
snd-soc-smdk-spdif-objs := smdk_spdif.o
-snd-soc-smdk-wm8580pcm-objs := smdk_wm8580pcm.o
snd-soc-smdk-wm8994pcm-objs := smdk_wm8994pcm.o
snd-soc-speyside-objs := speyside.o
snd-soc-tobermory-objs := tobermory.o
@@ -62,7 +61,6 @@ obj-$(CONFIG_SND_SOC_SNOW) += snd-soc-snow.o
obj-$(CONFIG_SND_SOC_SAMSUNG_SMDK_WM9713) += snd-soc-smdk-wm9713.o
obj-$(CONFIG_SND_SOC_SMARTQ) += snd-soc-s3c64xx-smartq-wm8987.o
obj-$(CONFIG_SND_SOC_SAMSUNG_SMDK_SPDIF) += snd-soc-smdk-spdif.o
-obj-$(CONFIG_SND_SOC_SMDK_WM8580_PCM) += snd-soc-smdk-wm8580pcm.o
obj-$(CONFIG_SND_SOC_SMDK_WM8994_PCM) += snd-soc-smdk-wm8994pcm.o
obj-$(CONFIG_SND_SOC_SPEYSIDE) += snd-soc-speyside.o
obj-$(CONFIG_SND_SOC_TOBERMORY) += snd-soc-tobermory.o
diff --git a/sound/soc/samsung/smdk_wm8580pcm.c
b/sound/soc/samsung/smdk_wm8580pcm.c
deleted file mode 100644
index 6deec5234c92..
--- a/sound/soc/samsung/smdk_wm8580pcm.c
+++ /dev/null
@@ -1,176 +0,0 @@
-/*
- * sound/soc/samsung/smdk_wm8580pcm.c
- *
- * Copyright (c) 2011 Samsung Electronics Co. Ltd
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- */
-#include
-#include
-#include
-#include
-
-#include
-
-#include "../codecs/wm8580.h"
-#include "dma.h"
-#include "pcm.h"
-
-/*
- * Board Settings:
- * o '1' means 'ON'
- * o '0' means 'OFF'
- * o 'X' means 'Don't care'
- *
- * SMDK6410 Base B/D: CFG1-, CFG2-
- * SMDKC110, SMDKV210: CFGB11-100100, CFGB12-
- */
-
-#define SMDK_WM8580_EXT_OSC 1200
-#define SMDK_WM8580_EXT_MCLK 4096000
-#define SMDK_WM8580_EXT_VOICE 2048000
-
-static unsigned long mclk_freq;
-static unsigned long xtal_freq;
-
-/*
- * If MCLK clock directly gets from XTAL, we don't have to use PLL
- * to make MCLK, but if XTAL clock source connects with other codec
- * pin (like XTI), we should have to set codec's PLL to make MCLK.
- * Because Samsung SoC does not support pcmcdclk output like I2S.
- */
-
-static int smdk_wm8580_pcm_hw_params(struct snd_pcm_substream *substream,
- struct snd_pcm_hw_params *params)
-{
- struct snd_soc_pcm_runtime *rtd = substream->private_data;
- struct snd_soc_dai *codec_dai = rtd->codec_dai;
- struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
- int rfs, ret;
-
- switch (params_rate(params)) {
- case 8000:
- break;
- default:
- printk(KERN_ERR "%s:%d Sampling Rate %u not supported!\n",
- __func__, __LINE__, params_rate(params));
- return -EINVAL;
- }
-
- rfs = mclk_freq / params_rate(params) / 2;
-
- if (mclk_freq == xtal_freq) {
- ret = snd_soc_dai_set_sysclk(codec_dai, WM8580_CLKSRC_MCLK,
- mclk_freq, SND_SOC_CLOCK_IN);
- if (ret < 0)
- return ret;
-
- ret = snd_soc_dai_set_clkdiv(codec_dai, WM8580_MCLK,
-
[PATCH 3/4] ASoC: samsung: MACH_SMDKC100 isn't supported anymore
Commit b8529ec1c1b0 ("ARM: S5PC100: no more support S5PC100 SoC")
removed Kconfig symbol MACH_SMDKC100. But there are still two references
to that symbol left. These are now pointless. Remove them too.
Signed-off-by: Paul Bolle
---
Apparently Kukjin had a fixup queued (see
http://mailman.alsa-project.org/pipermail/alsa-devel/2014-September/081482.html
). But that fixup never entered the tree, so let's try again.
sound/soc/samsung/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index 3be649098b30..5f983d064920 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -53,7 +53,7 @@ config SND_SOC_SAMSUNG_JIVE_WM8750
config SND_SOC_SAMSUNG_SMDK_WM8580
tristate "SoC I2S Audio support for WM8580 on SMDK"
- depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 ||
MACH_SMDKV210 || MACH_SMDKC110)
+ depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKV210 ||
MACH_SMDKC110)
depends on REGMAP_I2C
select SND_SOC_WM8580
select SND_SAMSUNG_I2S
@@ -134,7 +134,7 @@ config SND_SOC_SAMSUNG_RX1950_UDA1380
config SND_SOC_SAMSUNG_SMDK_WM9713
tristate "SoC AC97 Audio support for SMDK with WM9713"
- depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 ||
MACH_SMDKV210 || MACH_SMDKC110)
+ depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKV210 ||
MACH_SMDKC110)
select SND_SOC_WM9713
select SND_SAMSUNG_AC97
help
--
1.9.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
[PATCH 1/4] ASoC: samsung: Remove goni or aquila with the WM8994
Commit 28c8331d386a ("ARM: S5PV210: Remove support for board files")
removed the Kconfig symbols MACH_GONI and MACH_AQUILA. As a result the
dependencies of SND_SOC_GONI_AQUILA_WM8994 can never be met. So remove
the unbuildable "SoC I2S Audio support for AQUILA/GONI - WM8994".
Signed-off-by: Paul Bolle
---
Suggested by Arnd Bergmann (see https://lkml.org/lkml/2014/9/4/381 ).
Previously submitted in https://lkml.org/lkml/2014/9/18/128 , but in an
awkward way. So this is basically a resend.
sound/soc/samsung/Kconfig | 11 --
sound/soc/samsung/Makefile | 2 -
sound/soc/samsung/goni_wm8994.c | 289
3 files changed, 302 deletions(-)
delete mode 100644 sound/soc/samsung/goni_wm8994.c
diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index fc67f97f19f6..da6d0229cfa2 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -146,17 +146,6 @@ config SND_SOC_SMARTQ
select SND_SAMSUNG_I2S
select SND_SOC_WM8750
-config SND_SOC_GONI_AQUILA_WM8994
- tristate "SoC I2S Audio support for AQUILA/GONI - WM8994"
- depends on SND_SOC_SAMSUNG && (MACH_GONI || MACH_AQUILA)
- depends on I2C=y
- select SND_SAMSUNG_I2S
- select MFD_WM8994
- select SND_SOC_WM8994
- help
- Say Y if you want to add support for SoC audio on goni or aquila
- with the WM8994.
-
config SND_SOC_SAMSUNG_SMDK_SPDIF
tristate "SoC S/PDIF Audio support for SMDK"
depends on SND_SOC_SAMSUNG
diff --git a/sound/soc/samsung/Makefile b/sound/soc/samsung/Makefile
index 31e3dba7e3b5..052fe71be518 100644
--- a/sound/soc/samsung/Makefile
+++ b/sound/soc/samsung/Makefile
@@ -35,7 +35,6 @@ snd-soc-smdk-wm8994-objs := smdk_wm8994.o
snd-soc-snow-objs := snow.o
snd-soc-smdk-wm9713-objs := smdk_wm9713.o
snd-soc-s3c64xx-smartq-wm8987-objs := smartq_wm8987.o
-snd-soc-goni-wm8994-objs := goni_wm8994.o
snd-soc-smdk-spdif-objs := smdk_spdif.o
snd-soc-smdk-wm8580pcm-objs := smdk_wm8580pcm.o
snd-soc-smdk-wm8994pcm-objs := smdk_wm8994pcm.o
@@ -63,7 +62,6 @@ obj-$(CONFIG_SND_SOC_SNOW) += snd-soc-snow.o
obj-$(CONFIG_SND_SOC_SAMSUNG_SMDK_WM9713) += snd-soc-smdk-wm9713.o
obj-$(CONFIG_SND_SOC_SMARTQ) += snd-soc-s3c64xx-smartq-wm8987.o
obj-$(CONFIG_SND_SOC_SAMSUNG_SMDK_SPDIF) += snd-soc-smdk-spdif.o
-obj-$(CONFIG_SND_SOC_GONI_AQUILA_WM8994) += snd-soc-goni-wm8994.o
obj-$(CONFIG_SND_SOC_SMDK_WM8580_PCM) += snd-soc-smdk-wm8580pcm.o
obj-$(CONFIG_SND_SOC_SMDK_WM8994_PCM) += snd-soc-smdk-wm8994pcm.o
obj-$(CONFIG_SND_SOC_SPEYSIDE) += snd-soc-speyside.o
diff --git a/sound/soc/samsung/goni_wm8994.c b/sound/soc/samsung/goni_wm8994.c
deleted file mode 100644
index fad56b9e7369..
--- a/sound/soc/samsung/goni_wm8994.c
+++ /dev/null
@@ -1,289 +0,0 @@
-/*
- * goni_wm8994.c
- *
- * Copyright (C) 2010 Samsung Electronics Co.Ltd
- * Author: Chanwoo Choi
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- *
- */
-
-#include
-#include
-#include
-
-#include
-#include
-
-#include "../codecs/wm8994.h"
-
-#define MACHINE_NAME 0
-#define CPU_VOICE_DAI 1
-
-static const char *aquila_str[] = {
- [MACHINE_NAME] = "aquila",
- [CPU_VOICE_DAI] = "aquila-voice-dai",
-};
-
-static struct snd_soc_card goni;
-static struct platform_device *goni_snd_device;
-
-/* 3.5 pie jack */
-static struct snd_soc_jack jack;
-
-/* 3.5 pie jack detection DAPM pins */
-static struct snd_soc_jack_pin jack_pins[] = {
- {
- .pin = "Headset Mic",
- .mask = SND_JACK_MICROPHONE,
- }, {
- .pin = "Headset Stereophone",
- .mask = SND_JACK_HEADPHONE | SND_JACK_MECHANICAL |
- SND_JACK_AVOUT,
- },
-};
-
-/* 3.5 pie jack detection gpios */
-static struct snd_soc_jack_gpio jack_gpios[] = {
- {
- .gpio = S5PV210_GPH0(6),
- .name = "DET_3.5",
- .report = SND_JACK_HEADSET | SND_JACK_MECHANICAL |
- SND_JACK_AVOUT,
- .debounce_time = 200,
- },
-};
-
-static const struct snd_soc_dapm_widget goni_dapm_widgets[] = {
- SND_SOC_DAPM_SPK("Ext Left Spk", NULL),
- SND_SOC_DAPM_SPK("Ext Right Spk", NULL),
- SND_SOC_DAPM_SPK("Ext Rcv", NULL),
- SND_SOC_DAPM_HP("Headset Stereophone", NULL),
- SND_SOC_DAPM_MIC("Headset Mic", NULL),
- SND_SOC_DAPM_MIC("Main Mic", NULL),
- SND_SOC_DAPM_MIC("2nd Mic", NULL),
- SND_SOC_DAPM_LINE("Radio In", NULL),
-};
-
-static const struct snd_soc_dapm_route goni_dapm_routes[] = {
- {"Ext Left Spk", NULL, "SPKOUTLP"},
- {"Ext Left Spk", NULL, "SPKOUTLN"},
-
- {"Ext Right Spk", NULL, "SPKOUTRP"},
- {"Ext Right Spk", NULL, "SPKOUTRN"},
-
-
[PATCH 0/4] ASoC: samsung: clean up references to outdated Kconfig symbols
A few series of ARM cleanups regarding S5PC100 and S5PV210 were included in v3.17. These series removed these five Kconfig symbols: MACH_AQUILA MACH_GONI MACH_SMDKC100 MACH_SMDKC110 MACH_SMDKV210 This series, done on top of next-20150119, removes the remaining references to those five symbols. (The first two patches are actually resends.) Paul Bolle (4): ASoC: samsung: Remove goni or aquila with the WM8994 ASoC: samsung: Remove PCM support for WM8580 on SMDK ASoC: samsung: MACH_SMDKC100 isn't supported anymore ASoC: samsung: remove outdated Kconfig references sound/soc/samsung/Kconfig | 24 +-- sound/soc/samsung/Makefile | 4 - sound/soc/samsung/goni_wm8994.c| 289 - sound/soc/samsung/smdk_wm8580pcm.c | 176 -- 4 files changed, 2 insertions(+), 491 deletions(-) delete mode 100644 sound/soc/samsung/goni_wm8994.c delete mode 100644 sound/soc/samsung/smdk_wm8580pcm.c -- 1.9.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 V8 00/14] drm/exynos: few patches to enhance bridge chip support
Hello Thierry, On 01/05/2015 02:50 PM, Thierry Reding wrote: > On Fri, Jan 02, 2015 at 01:10:14PM +, Daniel Stone wrote: >> > >> > Ajay's series don't apply cleanly anymore because it has been a while since >> > he posted it but he can rebase on top of 3.19-rc1 once it is released and >> > re-resend. >> > >> >> Do you have any plans to rebase this so it's ready for merging? >> >> Thierry, Daniel, Dave - whose tree would this be best to merge through? > > The plan is for me to take the bridge patches through the drm/panel > tree. I'm going to look at these patches again later this week but from > a very quick peek there don't seem to be any major issues left. > I know you probably are very busy but it would be great if you can take a look to this series to avoid another kernel release to be missed since we are already at v3.19-rc5. Only this version was posted 2 months ago and the first version of the series was sent on May, 2014 so it has been on the list for almost a year now... Tomi and Laurent had already agreed with the DT binging so I think that we can already merge these and if there are any remaining issues, those can be fixed during the 3.20 -rc cycle. > Thierry > Thanks a lot and 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
Re: [RESEND PATCH v3] clocksource: exynos_mct: Add the support for Exynos 64bit SoC
Hi Daniel, On 01/19/2015 06:27 PM, Daniel Lezcano wrote: > On 01/19/2015 01:54 AM, Chanwoo Choi wrote: >> Dear Daniel and Kukjin, >> >> On 01/15/2015 01:02 AM, Daniel Lezcano wrote: >>> On 01/14/2015 04:51 PM, Kukjin Kim wrote: On 01/14/15 14:33, Chanwoo Choi wrote: Hi, + Doug, Olof > This patch adds the support for Exynos 64bit SoC. The delay_timer is only > used > for Exynos 32bit SoC. > Yes, the Exynos MCT(Multi-Core Timer) is 64bit timer and it is available on 64bit exynos SoC such as exynos7. But basically ARMv8 architecture is including ARM ARCH timer (ARM Generic Timer) and exynos7 also has implemented it and additionally its access is faster than using memory mapped register called SFR for MCT...so Doug submitted patch to use MCT on 32bit exynos SoCs before. I know using MCT on 64bit exynos is usefulness for Power Management and I need to talk to relevant guys in office again. If anything, I'll let you know. >>> >>> I will wait for your answer before digging more the patch. > > Hi Chanwoo, > > [ ... ] > >> Do you have any comment about this patch? > > Yes, a similar patch has been posted for the tegra2 timer to run on arm64. > The patch in question put macros #ifdef CONFIG_ARM64 to disable some parts of > the code. That ended, the tegra2 timer was not needed for the moment because > of the arch timer present, so it has been disabled from the compilation until > a proper fix without macros could be proposed. > > It is happening exactly the same with this patch. As Kukjin pointed it, the > exynos_mct may not be needed (at least until a backup timer is needed at PM > time). > > I suggest you look at a nicer way to fix that instead of introducing macros > (which is by the way valid but not recommended by the CodingStyle rules) and > perhaps sync with Paul and Thierry [cc'ed] to find a common solution. OK, I understand your opinion. I'll try to consider it without adding '#ifdef'. 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: Exynos4 CONFIG_HZ
2015-01-18 17:57 GMT+01:00 Sten Spans : > > With the improvements in upstream support for exynos4 devices > I've been looking into adding support odroid devices to Debian's > armmp kernel. The kernel config changes needed are quite minimal > as can be seen here: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774896 > > Mostly enabling support and various modules. > > However as Ian Campbell notes, enabling ARCH_EXYNOS4 triggers > the following from arch/arm/Kconfig: > config HZ_FIXED > int > default 200 if ARCH_EBSA110 || ARCH_S3C24XX || \ > ARCH_S5PV210 || ARCH_EXYNOS4 > default AT91_TIMER_HZ if ARCH_AT91 > default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE_LEGACY > default 0 > > This forces CONFIG_HZ=200 for the entire armmp kernel, which is > undesirable. The reason for this setting isn't very clear to either > me or Ian. I personally have verified that HZ=250 (the default for debian > armmp kernels) boots fine. > > Is there a particular reason for this setting? > Would a patch removing this requirement for ARCH_EXYNOS4 be accepted? +Cc Kukjin Kim I cannot find a valid reason for fixed 200 Hz, especially that other values (<100, 1000>) are working. Maybe Kukjin will share some light on this? 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: [PATCHv8 1/9] devfreq: event: Add new devfreq_event class to provide basic data for devfreq governor
Dear Myungjoo, Following patches need to review from you (DEVFREQ maintainer). Please review these patches. - [PATCHv8 1/9] devfreq: event: Add new devfreq_event class to provide basic data for devfreq governor - [PATCHv8 2/9] devfreq: event: Add resource-managed function for devfreq-event device Best Regards, Chanwoo Choi On 01/12/2015 09:34 PM, 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 > Cc: Kyungmin Park > Signed-off-by: Chanwoo Choi > --- > drivers/devfreq/Kconfig | 2 + > drivers/devfreq/Makefile| 6 +- > drivers/devfreq/devfreq-event.c | 448 > > drivers/devfreq/event/Kconfig | 16 ++ > drivers/devfreq/event/Makefile | 1 + > include/linux/devfreq-event.h | 170 +++ > 6 files changed, 642 insertions(+), 1 deletion(-) > create mode 100644 drivers/devfreq/devfreq-event.c > create mode 100644 drivers/devfreq/event/Kconfig > create mode 100644 drivers/devfreq/event/Makefile > create mode 100644 include/linux/devfreq-event.h > > diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig > index faf4e70..21f8f17 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. > > +source "drivers/devfreq/event/Kconfig" > + > endif # PM_DEVFREQ > diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile > index 16138c9..c449336 100644 > --- a/drivers/devfreq/Makefile > +++ b/drivers/devfreq/Makefile > @@ -1,4 +1,5 @@ > -obj-$(CONFIG_PM_DEVFREQ) += devfreq.o > +obj-$(CONFIG_PM_DEVFREQ) += devfreq.o > +obj-$(CONFIG_PM_DEVFREQ_EVENT) += 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 +8,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) += event/ > diff --git a/drivers/devfreq/devfreq-event.c b/drivers/devfreq/devfreq-event.c > new file mode 100644 > index 000..9ba5ba4 > --- /dev/null > +++ b/drivers/devfreq/devfreq-event.c > @@ -0,0 +1,448 @@ > +/* > + * devfreq-event: a framework to provide raw data and events of devfreq > devices > + * > + * Copyright (C) 2014 Samsung Electronics > + * Author: Chanwoo Choi > + * > + * 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 > +#include > +#include > +#include > +#include > +#inclu
Re: [PATCH 1/2] pinctrl: exynos: Add AUDIO pin controller for exynos7
On Wed, Jan 14, 2015 at 3:27 PM, Tomasz Figa wrote: > 2015-01-14 20:40 GMT+09:00 Linus Walleij : >> On Fri, Dec 19, 2014 at 2:10 PM, Padmavathi Venna >> wrote: >> >>> Audio IPs on Exynos7 require gpios available in AUDIO >>> pin controller block. So adding the AUDIO pinctrl support. >>> >>> Signed-off-by: Padmavathi Venna >> (...) >>> --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt >>> +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt >>> @@ -181,6 +181,7 @@ Aliases for controllers compatible with >>> "samsung,exynos7-pinctrl": >>> - pinctrl6: pin controller of FSYS0 block, >>> - pinctrl7: pin controller of FSYS1 block, >>> - pinctrl8: pin controller of BUS1 block, >>> +- pinctrl9: pin controller of AUDIO block, >> >> This doesn't apply at all, the list has never been in the document merged >> upstream. > > I believe this patch depends on patch [1], which was mentioned in > cover letter and which you seem to have applied two days ago. If it > still doesn't apply, please let me know if I should collect the > patches myself and prepare a pull request for you. > > [1] https://patchwork.kernel.org/patch/5467321/ It applied when I tried it now, sorry I must have screwed up or something :( Patch applied! Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv8 7/9] ARM: dts: Add PPMU dt node for Exynos5260 SoC
Dear all,
I'll drop this patch because I can't test it on Exynos5260-based board.
Best Regards,
Chanwoo Choi
On 01/12/2015 09:34 PM, Chanwoo Choi wrote:
> This patch adds PPMU (Performance Profiling Monitoring Unit) dt node
> Exynos5260 SoC.
>
> Exynos5260 SoC has following PPMU IPs:
> - PPMU_DREX0_S0 0x10c6
> - PPMU_DREX0_S1 0x10c7
> - PPMU_DREX1_S0 0x10c8
> - PPMU_DREX1_S1 0x10c9
> - PPMU_EAGLE0x10cc
> - PPMU_KFC 0x10cd
> - PPMU_MFC 0x1104
> - PPMU_G3D 0x1188
> - PPMU_FSYS 0x1222
> - PPMU_ISP 0x1337
> - PPMU_FICM 0x13cb
> - PPMU_GSCL 0x13e6
> - PPMU_MSCL 0x13ee
> - PPMU_FIMD0X 0x145b
> - PPMU_FIMD1X 0x145c
>
> The drivers/devfreq/exynos/exynos5_bus.c supports the memory bus frequency/
> voltage scaling of Exynos5260 SoC with DEVFREQ framework.
>
> Cc: Kukjin Kim
> Cc: Abhilash Kesavan
> Cc: Jonghwan Choi
> Signed-off-by: Chanwoo Choi
> ---
> arch/arm/boot/dts/exynos5260.dtsi | 90
> +++
> 1 file changed, 90 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5260.dtsi
> b/arch/arm/boot/dts/exynos5260.dtsi
> index 36da38e..26f3074 100644
> --- a/arch/arm/boot/dts/exynos5260.dtsi
> +++ b/arch/arm/boot/dts/exynos5260.dtsi
> @@ -307,6 +307,96 @@
> fifo-depth = <64>;
> status = "disabled";
> };
> +
> + ppmu_drex0_s0: ppmu_drex0_s0@10c6 {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x10c6 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_drex0_s1: ppmu_drex0_s1@10c7 {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x10c7 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_drex1_s0: ppmu_drex1_s0@10c8 {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x10c8 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_drex1_s1: ppmu_drex1_s1@10c9 {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x10c9 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_eagle: ppmu_eagle@10cc {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x10cc 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_kfc: ppmu_kfc@10cd {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x10cd 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_mfc: ppmu_mfc@1104 {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x1104 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_g3d: ppmu_g3d@1188 {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x1188 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_fsys: ppmu_fsys@1222 {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x1222 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_isp: ppmu_isp@1337 {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x1337 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_fimc: ppmu_fimc@13cb {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x13cb 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_gscl: ppmu_gscl@13e6 {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x13e6 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_mscl: ppmu_gscl@13ee {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x13ee 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_fimd0x: ppmu_fimd0x@145b {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x145b 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_fimd1x: ppmu_fimd1x@145c {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x145c 0x2000>;
> + status = "disabled";
> + };
> };
> };
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to m
[alsa-devel] [PATCH v2 3/3] ARM: dts: Add sound nodes for exynos4412-trats2
This patch add WM1811 audio codec, I2S interface and the sound
machine nodes to enable audio on exynos4412-trats2 board.
Signed-off-by: Inha Song
---
arch/arm/boot/dts/exynos4412-trats2.dts | 39 +
1 file changed, 39 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 29231b4..7a52cca 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -203,6 +203,25 @@
};
};
+ i2c@138A {
+ samsung,i2c-sda-delay = <100>;
+ samsung,i2c-slave-addr = <0x10>;
+ samsung,i2c-max-bus-freq = <10>;
+ pinctrl-0 = <&i2c4_bus>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ wm1811: wm1811@1a {
+ compatible = "wlf,wm1811";
+ reg = <0x1a>;
+ clocks = <&pmu_system_controller 0>;
+ clock-names = "MCLK1";
+ DCVDD-supply = <&ldo3_reg>;
+ DBVDD1-supply = <&ldo3_reg>;
+ wlf,ldo1ena = <&gpj0 4 0>;
+ };
+ };
+
i2c@138D {
samsung,i2c-sda-delay = <100>;
samsung,i2c-slave-addr = <0x10>;
@@ -838,6 +857,26 @@
};
};
+ i2s0: i2s@0383 {
+ pinctrl-0 = <&i2s0_bus>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
+
+ sound {
+ compatible = "samsung,trats2-audio";
+ assigned-clocks = <&pmu_system_controller 0>;
+ assigned-clock-parents = <&clock CLK_XUSBXTI>;
+ samsung,i2s-controller = <&i2s0>;
+ samsung,model = "Trats2";
+ samsung,audio-codec = <&wm1811>;
+ samsung,audio-routing =
+ "SPK", "SPKOUTLN",
+ "SPK", "SPKOUTLP",
+ "SPK", "SPKOUTRN",
+ "SPK", "SPKOUTRP";
+ };
+
exynos-usbphy@125B {
status = "okay";
};
--
2.0.0.390.gcb682f8
--
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
[alsa-devel] [PATCH v2 2/3] ASoC: samsung: Document Trats2 audio subsystem bindings
This patch add Trats2 audio subsystem bindings document.
Signed-off-by: Inha Song
---
.../bindings/sound/samsung,trats2-wm1811.txt | 25 ++
1 file changed, 25 insertions(+)
create mode 100644
Documentation/devicetree/bindings/sound/samsung,trats2-wm1811.txt
diff --git a/Documentation/devicetree/bindings/sound/samsung,trats2-wm1811.txt
b/Documentation/devicetree/bindings/sound/samsung,trats2-wm1811.txt
new file mode 100644
index 000..319ff07
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/samsung,trats2-wm1811.txt
@@ -0,0 +1,25 @@
+Samsung Exynos Trats2 audio with WM1811 codec
+
+Required properties:
+
+ - compatible : Must be "samsung,trats2-audio"
+ - samsung,i2s-controller : The phandle of the I2S controller
+ - samsung,model : The user visible name of this sound
+ - samsung,audio-codec : The phandle of the WM1811 audio codec
+ - samsung,audio-routing : A list of the connections between audio
+ components. each entry is a pair of strings, the first being the
+ connection's sink, the second being the connection's source
+
+Example:
+
+sound {
+ compatible = "samsung,trats2-audio";
+ samsung,i2s-controller = <&i2s0>;
+ samsung,model = "Trats2";
+ samsung,audio-codec = <&wm1811>;
+ samsung,audio-routing =
+ "SPK", "SPKOUTLN",
+ "SPK", "SPKOUTLP",
+ "SPK", "SPKOUTRN",
+ "SPK", "SPKOUTRP";
+};
--
2.0.0.390.gcb682f8
--
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
[alsa-devel] [PATCH v2 0/3] Sound support for Exynos4412 Trats2 board
This patch-set adds basic sound support for the Trats2 boards. It just support primary I2s and external speaker playback. Changes in v2: - Remove unnecessary lines in Trats2 machine driver - move clock enable/disable to .startup / .shutdown - Fix code style issues - Remove mclk DT property in Trats2 sound and add MCLK1 property in WM1811 node. (MCLK1 is optional property in WM8994 node - refer: Document/devicetree/bindings/sound/wm8994.txt) - Use mclk that defined in WM1811 DT node. - Add "samsung,audio-codec" property to required properties. Inha Song (3): ASoC: samsung: Add machine driver for Trats2 ASoC: samsung: Document Trats2 audio subsystem bindings ARM: dts: Add sound nodes for exynos4412-trats2 .../bindings/sound/samsung,trats2-wm1811.txt | 25 +++ arch/arm/boot/dts/exynos4412-trats2.dts| 39 sound/soc/samsung/Kconfig | 8 + sound/soc/samsung/Makefile | 2 + sound/soc/samsung/trats2_wm1811.c | 218 + 5 files changed, 292 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/samsung,trats2-wm1811.txt create mode 100644 sound/soc/samsung/trats2_wm1811.c -- 2.0.0.390.gcb682f8 -- 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
[alsa-devel] [PATCH v2 1/3] ASoC: samsung: Add machine driver for Trats2
This patch add the sound machine driver for Trats2 board.
The codec operate in master mode.
Signed-off-by: Inha Song
---
sound/soc/samsung/Kconfig | 8 ++
sound/soc/samsung/Makefile| 2 +
sound/soc/samsung/trats2_wm1811.c | 218 ++
3 files changed, 228 insertions(+)
create mode 100644 sound/soc/samsung/trats2_wm1811.c
diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index fc67f97..8031423 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -245,3 +245,11 @@ config SND_SOC_ARNDALE_RT5631_ALC5631
depends on SND_SOC_SAMSUNG
select SND_SAMSUNG_I2S
select SND_SOC_RT5631
+
+config SND_SOC_SAMSUNG_TRATS2_WM1811
+ tristate "SoC I2S Audio support for WM1811 on Tizen Trats2 board"
+ depends on SND_SOC_SAMSUNG
+ select SND_SOC_WM8994
+ select SND_SAMSUNG_I2S
+ help
+ Say Y if you want to add support for SoC audio on the Tizen Trats2
board.
diff --git a/sound/soc/samsung/Makefile b/sound/soc/samsung/Makefile
index 31e3dba..e2b7b1b 100644
--- a/sound/soc/samsung/Makefile
+++ b/sound/soc/samsung/Makefile
@@ -46,6 +46,7 @@ snd-soc-littlemill-objs := littlemill.o
snd-soc-bells-objs := bells.o
snd-soc-odroidx2-max98090-objs := odroidx2_max98090.o
snd-soc-arndale-rt5631-objs := arndale_rt5631.o
+snd-soc-trats2-wm1811-objs := trats2_wm1811.o
obj-$(CONFIG_SND_SOC_SAMSUNG_JIVE_WM8750) += snd-soc-jive-wm8750.o
obj-$(CONFIG_SND_SOC_SAMSUNG_NEO1973_WM8753) += snd-soc-neo1973-wm8753.o
@@ -73,3 +74,4 @@ obj-$(CONFIG_SND_SOC_LITTLEMILL) += snd-soc-littlemill.o
obj-$(CONFIG_SND_SOC_BELLS) += snd-soc-bells.o
obj-$(CONFIG_SND_SOC_ODROIDX2) += snd-soc-odroidx2-max98090.o
obj-$(CONFIG_SND_SOC_ARNDALE_RT5631_ALC5631) += snd-soc-arndale-rt5631.o
+obj-$(CONFIG_SND_SOC_SAMSUNG_TRATS2_WM1811) += snd-soc-trats2-wm1811.o
diff --git a/sound/soc/samsung/trats2_wm1811.c
b/sound/soc/samsung/trats2_wm1811.c
new file mode 100644
index 000..b937612
--- /dev/null
+++ b/sound/soc/samsung/trats2_wm1811.c
@@ -0,0 +1,218 @@
+/*
+ * Copyright (C) 2015 Samsung Electronics Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "i2s.h"
+#include "../codecs/wm8994.h"
+
+struct trats2_machine_priv {
+ struct clk *clk_mclk;
+};
+
+static struct trats2_machine_priv trats2_wm1811_priv;
+
+static const struct snd_kcontrol_new trats2_controls[] = {
+ SOC_DAPM_PIN_SWITCH("SPK"),
+};
+
+static const struct snd_soc_dapm_widget trats2_dapm_widgets[] = {
+ SND_SOC_DAPM_SPK("SPK", NULL),
+};
+
+static int trats2_aif1_hw_params(struct snd_pcm_substream *substream,
+struct snd_pcm_hw_params *params)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct snd_soc_dai *codec_dai = rtd->codec_dai;
+ struct trats2_machine_priv *priv = snd_soc_card_get_drvdata(rtd->card);
+ unsigned int sysclk_rate;
+ unsigned int mclk_rate =
+ (unsigned int)clk_get_rate(priv->clk_mclk);
+ int ret;
+
+ /* SYSCLK must be greater than 4.096MHz */
+ if (params_rate(params) == 8000 || params_rate(params) == 11025)
+ sysclk_rate = params_rate(params) * 512;
+ else
+ sysclk_rate = params_rate(params) * 256;
+
+ /* Set the codec FLL1 */
+ ret = snd_soc_dai_set_pll(codec_dai, WM8994_FLL1, WM8994_FLL_SRC_MCLK1,
+ mclk_rate, sysclk_rate);
+ if (ret < 0) {
+ dev_err(codec_dai->dev, "Failed to set FLL1: %d\n", ret);
+ return ret;
+ }
+
+ /* Set the codec SYSCLK */
+ ret = snd_soc_dai_set_sysclk(codec_dai, WM8994_SYSCLK_FLL1,
+sysclk_rate, SND_SOC_CLOCK_IN);
+ if (ret < 0) {
+ dev_err(codec_dai->dev, "Failed to set SYSCLK: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int trats2_aif1_startup(struct snd_pcm_substream *substream)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct trats2_machine_priv *priv = snd_soc_card_get_drvdata(rtd->card);
+ int ret;
+
+ ret = clk_prepare_enable(priv->clk_mclk);
+ if (ret) {
+ dev_err(rtd->card->dev, "Failed to enable mclk: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static void trats2_aif1_shutdown(struct snd_pcm_substream *substream)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct trats2_machine_priv *priv = snd_soc_card_get_drvdata(rtd->card);
+
+ clk_disable_unprepare(priv->clk_mclk);
+}
+
+static const struct
[PATCH v4 13/21] ARM: omap: convert wakeupgen to stacked domains
OMAP4/5 has been (ab)using the gic_arch_extn to provide
wakeup from suspend, and it makes a lot of sense to convert
this code to use stacked domains instead.
This patch does just this, updating the DT files to actually
reflect what the HW provides.
BIG FAT WARNING: because the DTs were so far lying by not
exposing the WUGEN HW block, kernels with this patch applied
won't have any suspend-resume facility when booted with old DTs,
and old kernels with updated DTs won't even boot.
On a platform with this patch applied, the system looks like
this:
root@bacon-fat:~# cat /proc/interrupts
CPU0 CPU1
16: 0 0 WUGEN 37 gp_timer
19: 233799 155916 GIC 27 arch_timer
23: 0 0 WUGEN 9 l3-dbg-irq
24: 1 0 WUGEN 10 l3-app-irq
27:282 0 WUGEN 13 omap-dma-engine
44: 0 0 4ae1.gpio 13 DMA
294: 0 0 WUGEN 20 gpmc
297:506 0 WUGEN 56 4807.i2c
298: 0 0 WUGEN 57 48072000.i2c
299: 0 0 WUGEN 61 4806.i2c
300: 0 0 WUGEN 62 4807a000.i2c
301: 8 0 WUGEN 60 4807c000.i2c
308: 2439 0 WUGEN 74 OMAP UART2
312:362 0 WUGEN 83 mmc2
313:502 0 WUGEN 86 mmc0
314: 13 0 WUGEN 94 mmc1
350: 0 0 PRCM pinctrl, pinctrl
406: 35155709 0 GIC 109 ehci_hcd:usb1
407: 0 0 WUGEN 7 palmas
409: 0 0 WUGEN 119 twl6040
410: 0 0 twl6040 5 twl6040_irq_ready
411: 0 0 twl6040 0 twl6040_irq_th
IPI0: 0 1 CPU wakeup interrupts
IPI1: 0 0 Timer broadcast interrupts
IPI2: 95334 902334 Rescheduling interrupts
IPI3: 0 0 Function call interrupts
IPI4:479648 Single function call interrupts
IPI5: 0 0 CPU stop interrupts
IPI6: 0 0 IRQ work interrupts
IPI7: 0 0 completion interrupts
Err: 0
Signed-off-by: Marc Zyngier
---
arch/arm/boot/dts/am4372.dtsi | 11 ++-
arch/arm/boot/dts/am437x-gp-evm.dts | 1 -
arch/arm/boot/dts/am437x-sk-evm.dts | 1 -
arch/arm/boot/dts/am43x-epos-evm.dts | 1 -
arch/arm/boot/dts/dra7.dtsi | 12 ++-
arch/arm/boot/dts/dra72x.dtsi | 2 +-
arch/arm/boot/dts/dra74x.dtsi | 2 +-
arch/arm/boot/dts/omap4-duovero.dtsi | 2 -
arch/arm/boot/dts/omap4-panda-common.dtsi | 8 +-
arch/arm/boot/dts/omap4-sdp.dts | 8 +-
arch/arm/boot/dts/omap4-var-som-om44.dtsi | 2 -
arch/arm/boot/dts/omap4.dtsi | 18 -
arch/arm/boot/dts/omap5-cm-t54.dts| 1 -
arch/arm/boot/dts/omap5-uevm.dts | 2 -
arch/arm/boot/dts/omap5.dtsi | 26 ---
arch/arm/mach-omap2/omap-wakeupgen.c | 125 +++---
arch/arm/mach-omap2/omap-wakeupgen.h | 1 -
arch/arm/mach-omap2/omap4-common.c| 17 ++--
18 files changed, 162 insertions(+), 78 deletions(-)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index b62a1cd..9d672a7 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -15,7 +15,7 @@
/ {
compatible = "ti,am4372", "ti,am43";
- interrupt-parent = <&gic>;
+ interrupt-parent = <&wakeupgen>;
aliases {
@@ -48,6 +48,15 @@
#interrupt-cells = <3>;
reg = <0x48241000 0x1000>,
<0x48240100 0x0100>;
+ interrupt-parent = <&gic>;
+ };
+
+ wakeupgen: interrupt-controller@48281000 {
+ compatible = "ti,omap4-wugen-mpu";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ reg = <0x48281000 0x1000>;
+ interrupt-parent = <&gic>;
};
l2-cache-controller@48242000 {
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 7eaae4c..69f2313 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -280,7 +280,6 @@
reg = <0x24>;
compatible = "ti,tps65218";
interrupts = ; /* NMIn */
- interrupt-parent = <&gic>;
interrupt-controller;
#interrupt-cells = <2>;
diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts
b/arch/arm/boot/dts/am437x-sk-evm.dts
index 53bbfc9..029bade 100644
--- a/arch/arm/boot/dts/am437x-sk-evm.dts
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -334,7 +334,6 @@
tps@24 {
compatible = "ti,tps65218";
reg = <0x24>;
- interrupt-parent = <&gic>;
interrupts = ;
[PATCH v4 12/21] DT: omap4/5: add binding for the wake-up generator
Signed-off-by: Marc Zyngier
---
.../interrupt-controller/ti,omap4-wugen-mpu| 33 ++
1 file changed, 33 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu
b/Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu
new file mode 100644
index 000..43effa0
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu
@@ -0,0 +1,33 @@
+TI OMAP4 Wake-up Generator
+
+All TI OMAP4/5 (and their derivatives) an interrupt controller that
+routes interrupts to the GIC, and also serves as a wakeup source. It
+is also referred to as "WUGEN-MPU", hence the name of the binding.
+
+Reguired properties:
+
+- compatible : should contain at least "ti,omap4-wugen-mpu" or
+ "ti,omap5-wugen-mpu"
+- reg : Specifies base physical address and size of the registers.
+- interrupt-controller : Identifies the node as an interrupt controller.
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt source. The value must be 3.
+- interrupt-parent : a phandle to the GIC these interrupts are routed
+ to.
+
+Notes:
+
+- Because this HW ultimately routes interrupts to the GIC, the
+ interrupt specifier must be that of the GIC.
+- Only SPIs can use the WUGEN as an interrupt parent. SGIs and PPIs
+ are explicitly forbiden.
+
+Example:
+
+ wakeupgen: interrupt-controller@48281000 {
+ compatible = "ti,omap5-wugen-mpu", "ti,omap4-wugen-mpu";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ reg = <0x48281000 0x1000>;
+ interrupt-parent = <&gic>;
+ };
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 21/21] irqchip: gic: Drop support for gic_arch_extn
Now that the users of gic_arch_extn have been fixed, drop the
"feature" for good. This leads to the removal of some now useless
locking.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic.c | 54 -
include/linux/irqchip/arm-gic.h | 2 --
2 files changed, 56 deletions(-)
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 23fe3be..78d4dee 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -80,19 +80,6 @@ static DEFINE_RAW_SPINLOCK(irq_controller_lock);
#define NR_GIC_CPU_IF 8
static u8 gic_cpu_map[NR_GIC_CPU_IF] __read_mostly;
-/*
- * Supported arch specific GIC irq extension.
- * Default make them NULL.
- */
-struct irq_chip gic_arch_extn = {
- .irq_eoi= NULL,
- .irq_mask = NULL,
- .irq_unmask = NULL,
- .irq_retrigger = NULL,
- .irq_set_type = NULL,
- .irq_set_wake = NULL,
-};
-
#ifndef MAX_GIC_NR
#define MAX_GIC_NR 1
#endif
@@ -155,32 +142,18 @@ static void gic_mask_irq(struct irq_data *d)
{
u32 mask = 1 << (gic_irq(d) % 32);
- raw_spin_lock(&irq_controller_lock);
writel_relaxed(mask, gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR +
(gic_irq(d) / 32) * 4);
- if (gic_arch_extn.irq_mask)
- gic_arch_extn.irq_mask(d);
- raw_spin_unlock(&irq_controller_lock);
}
static void gic_unmask_irq(struct irq_data *d)
{
u32 mask = 1 << (gic_irq(d) % 32);
- raw_spin_lock(&irq_controller_lock);
- if (gic_arch_extn.irq_unmask)
- gic_arch_extn.irq_unmask(d);
writel_relaxed(mask, gic_dist_base(d) + GIC_DIST_ENABLE_SET +
(gic_irq(d) / 32) * 4);
- raw_spin_unlock(&irq_controller_lock);
}
static void gic_eoi_irq(struct irq_data *d)
{
- if (gic_arch_extn.irq_eoi) {
- raw_spin_lock(&irq_controller_lock);
- gic_arch_extn.irq_eoi(d);
- raw_spin_unlock(&irq_controller_lock);
- }
-
writel_relaxed(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
}
@@ -196,23 +169,13 @@ static int gic_set_type(struct irq_data *d, unsigned int
type)
if (type != IRQ_TYPE_LEVEL_HIGH && type != IRQ_TYPE_EDGE_RISING)
return -EINVAL;
- raw_spin_lock(&irq_controller_lock);
-
- if (gic_arch_extn.irq_set_type)
- gic_arch_extn.irq_set_type(d, type);
-
gic_configure_irq(gicirq, type, base, NULL);
- raw_spin_unlock(&irq_controller_lock);
-
return 0;
}
static int gic_retrigger(struct irq_data *d)
{
- if (gic_arch_extn.irq_retrigger)
- return gic_arch_extn.irq_retrigger(d);
-
/* the genirq layer expects 0 if we can't retrigger in hardware */
return 0;
}
@@ -244,21 +207,6 @@ static int gic_set_affinity(struct irq_data *d, const
struct cpumask *mask_val,
}
#endif
-#ifdef CONFIG_PM
-static int gic_set_wake(struct irq_data *d, unsigned int on)
-{
- int ret = -ENXIO;
-
- if (gic_arch_extn.irq_set_wake)
- ret = gic_arch_extn.irq_set_wake(d, on);
-
- return ret;
-}
-
-#else
-#define gic_set_wake NULL
-#endif
-
static void __exception_irq_entry gic_handle_irq(struct pt_regs *regs)
{
u32 irqstat, irqnr;
@@ -321,7 +269,6 @@ static struct irq_chip gic_chip = {
#ifdef CONFIG_SMP
.irq_set_affinity = gic_set_affinity,
#endif
- .irq_set_wake = gic_set_wake,
};
void __init gic_cascade_irq(unsigned int gic_nr, unsigned int irq)
@@ -985,7 +932,6 @@ void __init gic_init_bases(unsigned int gic_nr, int
irq_start,
set_handle_irq(gic_handle_irq);
}
- gic_chip.flags |= gic_arch_extn.flags;
gic_dist_init(gic);
gic_cpu_init(gic);
gic_pm_init(gic);
diff --git a/include/linux/irqchip/arm-gic.h b/include/linux/irqchip/arm-gic.h
index 36ec4ae..9de976b 100644
--- a/include/linux/irqchip/arm-gic.h
+++ b/include/linux/irqchip/arm-gic.h
@@ -95,8 +95,6 @@
struct device_node;
-extern struct irq_chip gic_arch_extn;
-
void gic_set_irqchip_flags(unsigned long flags);
void gic_init_bases(unsigned int, int, void __iomem *, void __iomem *,
u32 offset, struct device_node *);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 16/21] DT: exynos: update PMU binding
Document the fact that some Exynos PMUs are capable of acting as
an interrupt controller.
Signed-off-by: Marc Zyngier
---
Documentation/devicetree/bindings/arm/samsung/pmu.txt | 13 +
1 file changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
index 1e1979b..d698e74 100644
--- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
@@ -28,10 +28,23 @@ Properties:
- clocks : list of phandles and specifiers to all input clocks listed in
clock-names property.
+Optional properties:
+
+Some PMUs are capable of behaving as an interrupt controller (mostly
+to wake up a suspended PMU). In which case, they can have the
+following properties:
+
+- interrupt-controller: indicate that said PMU is an interrupt controller
+
+- interrupt-parent: a phandle indicating which interrupt controller
+ this PMU signals interrupts to.
+
Example :
pmu_system_controller: system-controller@1004 {
compatible = "samsung,exynos5250-pmu", "syscon";
reg = <0x1004 0x5000>;
+ interrupt-controller;
+ interrupt-parent = <&gic>;
#clock-cells = <1>;
clock-names = "clkout0", "clkout1", "clkout2", "clkout3",
"clkout4", "clkout8", "clkout9";
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 17/21] irqchip: gic: add an entry point to set up irqchip flags
A common use of gic_arch_extn is to set up additional flags
to the GIC irqchip. It looks like a benign enough hack that
doesn't really require the users of that feature to be converted
to stacked domains.
Add a gic_set_irqchip_flags() function that platform code can
call instead of using the dreaded gic_arch_extn.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic.c | 5 +
include/linux/irqchip/arm-gic.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 9c30a76..23fe3be 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -877,6 +877,11 @@ static const struct irq_domain_ops gic_irq_domain_ops = {
.xlate = gic_irq_domain_xlate,
};
+void gic_set_irqchip_flags(unsigned long flags)
+{
+ gic_chip.flags |= flags;
+}
+
void __init gic_init_bases(unsigned int gic_nr, int irq_start,
void __iomem *dist_base, void __iomem *cpu_base,
u32 percpu_offset, struct device_node *node)
diff --git a/include/linux/irqchip/arm-gic.h b/include/linux/irqchip/arm-gic.h
index 3978c5b..36ec4ae 100644
--- a/include/linux/irqchip/arm-gic.h
+++ b/include/linux/irqchip/arm-gic.h
@@ -97,6 +97,7 @@ struct device_node;
extern struct irq_chip gic_arch_extn;
+void gic_set_irqchip_flags(unsigned long flags);
void gic_init_bases(unsigned int, int, void __iomem *, void __iomem *,
u32 offset, struct device_node *);
void gic_cascade_irq(unsigned int gic_nr, unsigned int irq);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 15/21] ARM: exynos4/5: convert pmu wakeup to stacked domains
Exynos has been (ab)using the gic_arch_extn to provide
wakeup from suspend, and it makes a lot of sense to convert
this code to use stacked domains instead.
This patch does just this, updating the DT files to actually
reflect what the HW provides.
BIG FAT WARNING: because the DTs were so far lying by not
exposing the fact that the PMU block is actually the first
interrupt controller in the chain for RTC, kernels with this patch
applied wont have any suspend-resume facility when booted
with old DTs, and old kernels with updated DTs may not even boot.
Also, I stronly suspect that there is more than two wake-up
interrupts on these platforms, but I leave it to the maintainers
to fix their mess.
Signed-off-by: Marc Zyngier
---
arch/arm/boot/dts/exynos4.dtsi| 4 ++
arch/arm/boot/dts/exynos5250.dtsi | 4 ++
arch/arm/boot/dts/exynos5420.dtsi | 4 ++
arch/arm/mach-exynos/exynos.c | 14 ++---
arch/arm/mach-exynos/suspend.c| 122 ++
5 files changed, 129 insertions(+), 19 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index b8168f1..0e7d74e 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -141,6 +141,9 @@
pmu_system_controller: system-controller@1002 {
compatible = "samsung,exynos4210-pmu", "syscon";
reg = <0x1002 0x4000>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ interrupt-parent = <&gic>;
};
dsi_0: dsi@11C8 {
@@ -253,6 +256,7 @@
rtc@1007 {
compatible = "samsung,s3c6410-rtc";
reg = <0x1007 0x100>;
+ interrupt-parent = <&pmu_system_controller>;
interrupts = <0 44 0>, <0 45 0>;
clocks = <&clock CLK_RTC>;
clock-names = "rtc";
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 0a229fc..1dc5f6b 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -194,6 +194,9 @@
clock-names = "clkout16";
clocks = <&clock CLK_FIN_PLL>;
#clock-cells = <1>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ interrupt-parent = <&gic>;
};
sysreg_system_controller: syscon@1005 {
@@ -230,6 +233,7 @@
rtc: rtc@101E {
clocks = <&clock CLK_RTC>;
clock-names = "rtc";
+ interrupt-parent = <&pmu_system_controller>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 517e50f..35ecd36 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -309,6 +309,7 @@
rtc: rtc@101E {
clocks = <&clock CLK_RTC>;
clock-names = "rtc";
+ interrupt-parent = <&pmu_system_controller>;
status = "disabled";
};
@@ -748,6 +749,9 @@
clock-names = "clkout16";
clocks = <&clock CLK_FIN_PLL>;
#clock-cells = <1>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ interrupt-parent = <&gic>;
};
sysreg_system_controller: syscon@1005 {
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index c13d083..e417fdc 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -175,16 +175,15 @@ static void __init exynos_init_io(void)
exynos_map_io();
}
+/*
+ * Apparently, these SoCs are not able to wake-up from suspend using
+ * the PMU. Too bad. Should they suddenly become capable of such a
+ * feat, the matches below should be moved to suspend.c.
+ */
static const struct of_device_id exynos_dt_pmu_match[] = {
{ .compatible = "samsung,exynos3250-pmu" },
- { .compatible = "samsung,exynos4210-pmu" },
- { .compatible = "samsung,exynos4212-pmu" },
- { .compatible = "samsung,exynos4412-pmu" },
- { .compatible = "samsung,exynos4415-pmu" },
- { .compatible = "samsung,exynos5250-pmu" },
{ .compatible = "samsung,exynos5260-pmu" },
{ .compatible = "samsung,exynos5410-pmu" },
- { .compatible = "samsung,exynos5420-pmu" },
{ /*sentinel*/ },
};
@@ -195,9 +194,6 @@ static void exynos_map_pmu(void)
np = of_find_matching_node(NULL, exynos_dt_pmu_match);
if (np)
pmu_base_addr = of_iomap(np, 0);
-
- if (!pmu_base_addr)
- panic("failed to find exynos pmu register\n");
}
static void __init exynos_init_irq(void)
diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index f8e7dcd..b325ecd 100644
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -18,7 +18,9 @@
#inclu
[PATCH v4 09/21] DT: update ti,irq-crossbar binding
Make it look like a real interrupt controller.
Signed-off-by: Marc Zyngier
---
.../devicetree/bindings/arm/omap/crossbar.txt | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
index 4139db3..a9b28d7 100644
--- a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -9,7 +9,9 @@ inputs.
Required properties:
- compatible : Should be "ti,irq-crossbar"
- reg: Base address and the size of the crossbar registers.
-- ti,max-irqs: Total number of irqs available at the interrupt controller.
+- interrupt-controller: indicates that this block is an interrupt controller.
+- interrupt-parent: the interrupt controller this block is connected to.
+- ti,max-irqs: Total number of irqs available at the parent interrupt
controller.
- ti,max-crossbar-sources: Maximum number of crossbar sources that can be
routed.
- ti,reg-size: Size of a individual register in bytes. Every individual
register is assumed to be of same size. Valid sizes are 1, 2, 4.
@@ -27,13 +29,13 @@ Optional properties:
when the interrupt controller irq is unused (when not provided, default is 0)
Examples:
- crossbar_mpu: @4a02 {
+ crossbar_mpu: crossbar@4a002a48 {
compatible = "ti,irq-crossbar";
reg = <0x4a002a48 0x130>;
ti,max-irqs = <160>;
ti,max-crossbar-sources = <400>;
ti,reg-size = <2>;
- ti,irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
+ ti,irqs-reserved = <0 1 2 3 5 6 131 132>;
ti,irqs-skip = <10 133 139 140>;
};
@@ -44,10 +46,6 @@ Documentation/devicetree/bindings/arm/gic.txt for further
details.
An interrupt consumer on an SoC using crossbar will use:
interrupts =
-When the request number is between 0 to that described by
-"ti,max-crossbar-sources", it is assumed to be a crossbar mapping. If the
-request_number is greater than "ti,max-crossbar-sources", then it is mapped as
a
-quirky hardware mapping direct to GIC.
Example:
device_x@0x4a023000 {
@@ -55,9 +53,3 @@ Example:
interrupts = ;
...
};
-
- device_y@0x4a033000 {
- /* Direct mapped GIC SPI 1 used */
- interrupts = ;
- ...
- };
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 20/21] ARM: zynq: switch from gic_arch_extn to gic_set_irqchip_flags
Instead of directly touching gic_arch_extn, which is about to
be removed, use gic_set_irqchip_flags instead.
Signed-off-by: Marc Zyngier
---
arch/arm/mach-zynq/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index 26f92c2..82734d5 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -188,7 +188,7 @@ static void __init zynq_map_io(void)
static void __init zynq_irq_init(void)
{
- gic_arch_extn.flags = IRQCHIP_SKIP_SET_WAKE | IRQCHIP_MASK_ON_SUSPEND;
+ gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE | IRQCHIP_MASK_ON_SUSPEND);
irqchip_init();
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 19/21] ARM: ux500: switch from gic_arch_extn to gic_set_irqchip_flags
Instead of directly touching gic_arch_extn, which is about to
be removed, use gic_set_irqchip_flags instead.
Acked-by: Linus Walleij
Signed-off-by: Marc Zyngier
---
arch/arm/mach-ux500/cpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-ux500/cpu.c b/arch/arm/mach-ux500/cpu.c
index dbb2970..6ced0f6 100644
--- a/arch/arm/mach-ux500/cpu.c
+++ b/arch/arm/mach-ux500/cpu.c
@@ -52,7 +52,7 @@ void ux500_restart(enum reboot_mode mode, const char *cmd)
*/
void __init ux500_init_irq(void)
{
- gic_arch_extn.flags = IRQCHIP_SKIP_SET_WAKE | IRQCHIP_MASK_ON_SUSPEND;
+ gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE | IRQCHIP_MASK_ON_SUSPEND);
irqchip_init();
/*
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 11/21] DT: arm,gic: kill arm,routable-irqs
Nobody will regret it.
Signed-off-by: Marc Zyngier
---
Documentation/devicetree/bindings/arm/gic.txt | 6 --
1 file changed, 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/gic.txt
b/Documentation/devicetree/bindings/arm/gic.txt
index 8112d0c..631cb71 100644
--- a/Documentation/devicetree/bindings/arm/gic.txt
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -52,11 +52,6 @@ Optional
regions, used when the GIC doesn't have banked registers. The offset is
cpu-offset * cpu-nr.
-- arm,routable-irqs : Total number of gic irq inputs which are not directly
- connected from the peripherals, but are routed dynamically
- by a crossbar/multiplexer preceding the GIC. The GIC irq
- input line is assigned dynamically when the corresponding
- peripheral's crossbar line is mapped.
Example:
intc: interrupt-controller@fff11000 {
@@ -64,7 +59,6 @@ Example:
#interrupt-cells = <3>;
#address-cells = <1>;
interrupt-controller;
- arm,routable-irqs = <160>;
reg = <0xfff11000 0x1000>,
<0xfff10100 0x100>;
};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 14/21] ARM: imx6: convert GPC to stacked domains
IMX6 has been (ab)using the gic_arch_extn to provide
wakeup from suspend, and it makes a lot of sense to convert
this code to use stacked domains instead.
This patch does just this, updating the DT files to actually
reflect what the HW provides.
BIG FAT WARNING: because the DTs were so far lying by not
exposing the fact that the GPC block is actually the first
interrupt controller in the chain, kernels with this patch
applied wont have any suspend-resume facility when booted
with old DTs, and old kernels with updated DTs won't even boot.
Tested-by: Stefan Agner
Acked-by: Stefan Agner
Signed-off-by: Marc Zyngier
---
arch/arm/boot/dts/imx6qdl.dtsi | 7 ++-
arch/arm/boot/dts/imx6sl.dtsi | 6 +-
arch/arm/boot/dts/imx6sx.dtsi | 6 +-
arch/arm/mach-imx/common.h | 1 -
arch/arm/mach-imx/gpc.c | 127
arch/arm/mach-imx/mach-imx6q.c | 1 -
arch/arm/mach-imx/mach-imx6sl.c | 1 -
arch/arm/mach-imx/mach-imx6sx.c | 1 -
8 files changed, 119 insertions(+), 31 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 4fc03b7..aff9ded 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -53,6 +53,7 @@
interrupt-controller;
reg = <0x00a01000 0x1000>,
<0x00a00100 0x100>;
+ interrupt-parent = <&intc>;
};
clocks {
@@ -82,7 +83,7 @@
#address-cells = <1>;
#size-cells = <1>;
compatible = "simple-bus";
- interrupt-parent = <&intc>;
+ interrupt-parent = <&gpc>;
ranges;
dma_apbh: dma-apbh@0011 {
@@ -122,6 +123,7 @@
compatible = "arm,cortex-a9-twd-timer";
reg = <0x00a00600 0x20>;
interrupts = <1 13 0xf01>;
+ interrupt-parent = <&intc>;
clocks = <&clks IMX6QDL_CLK_TWD>;
};
@@ -694,8 +696,11 @@
gpc: gpc@020dc000 {
compatible = "fsl,imx6q-gpc";
reg = <0x020dc000 0x4000>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
interrupts = <0 89 IRQ_TYPE_LEVEL_HIGH>,
<0 90 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-parent = <&intc>;
};
gpr: iomuxc-gpr@020e {
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 36ab8e0..0d0962b 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -72,6 +72,7 @@
interrupt-controller;
reg = <0x00a01000 0x1000>,
<0x00a00100 0x100>;
+ interrupt-parent = <&intc>;
};
clocks {
@@ -95,7 +96,7 @@
#address-cells = <1>;
#size-cells = <1>;
compatible = "simple-bus";
- interrupt-parent = <&intc>;
+ interrupt-parent = <&gpc>;
ranges;
ocram: sram@0090 {
@@ -603,7 +604,10 @@
gpc: gpc@020dc000 {
compatible = "fsl,imx6sl-gpc", "fsl,imx6q-gpc";
reg = <0x020dc000 0x4000>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
interrupts = <0 89 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-parent = <&intc>;
};
gpr: iomuxc-gpr@020e {
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 7a24fee..dabaf89 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -88,6 +88,7 @@
interrupt-controller;
reg = <0x00a01000 0x1000>,
<0x00a00100 0x100>;
+ interrupt-parent = <&intc>;
};
clocks {
@@ -131,7 +132,7 @@
#address-cells = <1>;
#size-cells = <1>;
compatible = "simple-bus";
- interrupt-parent = <&intc>;
+ interrupt-parent = <&gpc>;
ranges;
pmu {
@@ -700,7 +701,10 @@
gpc: gpc@020dc000 {
compatible = "fsl,imx6sx-gpc", "fsl,imx6q-gpc";
reg = <0x020dc000 0x4000>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
interrupts = ;
+ interrupt-parent = <&intc>;
};
iomuxc: iomuxc@02
[PATCH v4 18/21] ARM: shmobile: remove use of gic_arch_extn.irq_set_wake
shmobile only uses gic_arch_extn.irq_set_wake to prevent the GIC
from returning -ENXIO when receiving a wake-up configuration request.
It is a lot simpler to tell the irq layer that we don't need any
configuration by using the IRQCHIP_SKIP_SET_WAKE, thanks to the
new gic_set_irqchip_flags function.
Acked-by: Simon Horman
Signed-off-by: Marc Zyngier
---
arch/arm/mach-shmobile/intc-sh73a0.c | 7 +--
arch/arm/mach-shmobile/setup-r8a7779.c | 7 +--
2 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-shmobile/intc-sh73a0.c
b/arch/arm/mach-shmobile/intc-sh73a0.c
index 9e36180..fd63ae6 100644
--- a/arch/arm/mach-shmobile/intc-sh73a0.c
+++ b/arch/arm/mach-shmobile/intc-sh73a0.c
@@ -252,11 +252,6 @@ static irqreturn_t sh73a0_intcs_demux(int irq, void
*dev_id)
return IRQ_HANDLED;
}
-static int sh73a0_set_wake(struct irq_data *data, unsigned int on)
-{
- return 0; /* always allow wakeup */
-}
-
#define PINTER0_PHYS 0xe69000a0
#define PINTER1_PHYS 0xe69000a4
#define PINTER0_VIRT IOMEM(0xe69000a0)
@@ -318,8 +313,8 @@ void __init sh73a0_init_irq(void)
void __iomem *gic_cpu_base = IOMEM(0xf100);
void __iomem *intevtsa = ioremap_nocache(0xffd20100, PAGE_SIZE);
+ gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE);
gic_init(0, 29, gic_dist_base, gic_cpu_base);
- gic_arch_extn.irq_set_wake = sh73a0_set_wake;
register_intc_controller(&intcs_desc);
register_intc_controller(&intc_pint0_desc);
diff --git a/arch/arm/mach-shmobile/setup-r8a7779.c
b/arch/arm/mach-shmobile/setup-r8a7779.c
index 6156d17..989de2d 100644
--- a/arch/arm/mach-shmobile/setup-r8a7779.c
+++ b/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -713,14 +713,9 @@ void __init r8a7779_init_late(void)
}
#ifdef CONFIG_USE_OF
-static int r8a7779_set_wake(struct irq_data *data, unsigned int on)
-{
- return 0; /* always allow wakeup */
-}
-
void __init r8a7779_init_irq_dt(void)
{
- gic_arch_extn.irq_set_wake = r8a7779_set_wake;
+ gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE);
irqchip_init();
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
