Re: [PATCH] dmaengine: pl330: Set residue in tx_status callback
On 11 December 2014 at 10:17, Vinod Koul wrote: > On Tue, Dec 09, 2014 at 08:48:04PM +0530, Jassi Brar wrote: >> As Russell pointed out, that ain't the case either. >> So we are yet to figure out benefits of having explicit >> issue_pending() after tx_submit(). > callback ? > The callback is set after prep() and before tx_submit(), but here we talk after tx_submit(). -- 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] dmaengine: pl330: Set residue in tx_status callback
On Tue, Dec 09, 2014 at 08:48:04PM +0530, Jassi Brar wrote: > As Russell pointed out, that ain't the case either. > So we are yet to figure out benefits of having explicit > issue_pending() after tx_submit(). callback ? -- ~Vinod -- 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 1/2] soc: samsung: add exynos chipid driver support
Hi Yadwinder,
On Thursday 04 December 2014 11:56 PM, Yadwinder Singh Brar wrote:
Hi Pankaj,
On Wed, Dec 3, 2014 at 1:47 PM, Pankaj Dubey mailto:pankaj.du...@samsung.com>> wrote:
Exynos SoCs have Chipid, for identification of product IDs
and SoC revisions. This patch intendes to provide initialization
code for all these functionalites, at the same time it provides some
sysfs entries for accessing these information to userspace.
This driver usese existing binding for exnos-chipid.
[ ... ]
+
+static unsigned int soc_product_id;
+static unsigned int soc_revision;
+
+int exynos_product_id(void)
+{
+ return soc_product_id;
+}
+EXPORT_SYMBOL(exynos_product_id);
+
+int exynos_revision(void)
+{
+ return soc_revision;
+}
+EXPORT_SYMBOL(exynos_revision);
+
How about exporting only a struct containing members : soc_revision,
soc_product_id
OK, keeping in mind that chipid driver might be used from other drivers
as well (such as asv) other than from mach-exynos, we can do this.
and may be some more like asv/fused_info and keeping these function as
Other members such as fused_info etc. can be added as and when required.
As of now there is no active user of all those.
inlines ?
+static const char *exynos_product_id_to_name(unsigned int product_id)
__init ? hmm .. I think almost whole driver other than __ATTR funcs.
OK, I'll take care of this in next patch version.
Otherwise it looks nice to me :)
Best Regards,
Yadwinder
Thanks for review.
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: [RFC PATCHv2 4/7] devfreq: event: Add exynos-ppmu devfreq event driver
Hi Krzysztof,
On 12/10/2014 06:59 PM, Krzysztof Kozlowski wrote:
> On wto, 2014-12-09 at 23:13 +0900, Chanwoo Choi wrote:
>> This patch add exynos-ppmu devfreq event driver to provider raw data about
>> the utilization of each IP in Exynos SoC series.
>>
>> Cc: MyungJoo Ham
>> Cc: Kyungmin Park
>> Signed-off-by: Chanwoo Choi
>> ---
>> drivers/devfreq/Kconfig | 9 +
>> drivers/devfreq/event/Makefile | 1 +
>> drivers/devfreq/event/exynos-ppmu.c | 409
>>
>> 3 files changed, 419 insertions(+)
>> create mode 100644 drivers/devfreq/event/exynos-ppmu.c
>
> I would rather see this as an incremental change for existing
> exynos_ppmu.c file. However I do not insists on that.
>
>>
>> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
>> index 4d15b62..d4559f7 100644
>> --- a/drivers/devfreq/Kconfig
>> +++ b/drivers/devfreq/Kconfig
>> @@ -89,4 +89,13 @@ config ARM_EXYNOS5_BUS_DEVFREQ
>>
>> comment "DEVFREQ Event Drivers"
>>
>> +config DEVFREQ_EVENT_EXYNOS_PPMU
>> +bool "EXYNOS PPMU (Performance Profiling 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
>> + (Performance Profiling Monitoring Unit) counters to estimate the
>> + utilization of each module.
>> +
>> endif # PM_DEVFREQ
>> 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..2706f23
>> --- /dev/null
>> +++ b/drivers/devfreq/event/exynos-ppmu.c
>> @@ -0,0 +1,409 @@
>> +/*
>> + * exynos_ppmu.c - EXYNOS PPMU (Performance Profiling Monitoring Units)
>> 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
>> +
>> +#define PPMU_ENABLE BIT(0)
>> +#define PPMU_DISABLE0x0
>> +#define PPMU_CYCLE_RESETBIT(1)
>> +#define PPMU_COUNTER_RESET BIT(2)
>> +
>> +#define PPMU_ENABLE_COUNT0 BIT(0)
>> +#define PPMU_ENABLE_COUNT1 BIT(1)
>> +#define PPMU_ENABLE_COUNT2 BIT(2)
>> +#define PPMU_ENABLE_COUNT3 BIT(3)
>> +#define PPMU_ENABLE_CYCLE BIT(31)
>> +
>> +#define PPMU_CNTENS 0x10
>> +#define PPMU_FLAG 0x50
>> +#define PPMU_CCNT_OVERFLOW BIT(31)
>> +#define PPMU_CCNT 0x100
>> +
>> +#define PPMU_PMCNT0 0x110
>> +#define PPMU_PMCNT_OFFSET 0x10
>> +#define PMCNT_OFFSET(x) (PPMU_PMCNT0 + (PPMU_PMCNT_OFFSET * x))
>> +
>> +#define PPMU_BEVT0SEL 0x1000
>> +#define PPMU_BEVTSEL_OFFSET 0x100
>> +#define PPMU_BEVTSEL(x) (PPMU_BEVT0SEL + (x *
>> PPMU_BEVTSEL_OFFSET))
>> +
>> +#define RD_DATA_COUNT 0x5
>> +#define WR_DATA_COUNT 0x6
>> +#define RDWR_DATA_COUNT 0x7
>> +
>> +enum ppmu_counter {
>> +PPMU_PMNCNT0,
>> +PPMU_PMNCNT1,
>> +PPMU_PMNCNT2,
>> +PPMU_PMNCNT3,
>> +PPMU_PMNCNT_MAX,
>> +};
>> +
>> +/* Platform data */
>> +struct exynos_ppmu_data {
>> +struct devfreq *devfreq;
>
> Looks like not used here.
Right. I'll remove it.
>
>> +struct devfreq_event_dev **event_dev;
>> +struct devfreq_event_desc *desc;
>> +unsigned int num_events;
>> +
>> +struct device *dev;
>> +struct clk *clk_ppmu;
>> +struct mutex lock;
>> +
>> +struct __exynos_ppmu {
>> +void __iomem *hw_base;
>> +unsigned int ccnt;
>> +unsigned int event[PPMU_PMNCNT_MAX];
>> +unsigned int count[PPMU_PMNCNT_MAX];
>> +unsigned long long ns;
>> +ktime_t reset_time;
>> +bool ccnt_overflow;
>> +bool count_overflow[PPMU_PMNCNT_MAX];
>> +} ppmu;
>> +};
>> +
>> +struct __exynos_ppmu_events {
>> +char *name;
>> +int id;
>> +} ppmu_events[] = {
>> +{ "ppmu-dmc0-pmcnt0", PPMU_PMNCNT0 },
>> +{ "ppmu-dmc0-pmcnt1", PPMU_PMNCNT1 },
>> +{ "ppmu-dmc0-pmcnt2", PPMU_PMNCNT2 },
>> +{ "ppmu-dmc0-pmcnt3", PPMU_PMNCNT3 },
>> +
>> +{ "ppmu-dmc1-pmcnt0", PPMU_PMNCNT0 },
>> +{ "ppmu-dmc1-pmcnt1", PPMU_PMNCNT1 },
>> +{ "ppmu-dmc1-pmcnt2", PPMU_PMNCNT2 },
>> +{ "ppmu-dmc1-pmcnt3", PPMU_PMNCNT3 },
>> +
>> +{ "ppmu-cp
Re: [RFC PATCHv2 1/7] devfreq: event: Add new devfreq_event class to provide basic data for devfreq governor
Hi Krzysztof, First of all, thanks for your review. On 12/10/2014 06:37 PM, Krzysztof Kozlowski wrote: > On wto, 2014-12-09 at 23:13 +0900, Chanwoo Choi wrote: >> This patch add new devfreq_event class for devfreq_event device which provide >> raw data (e.g., memory bus utilization/GPU utilization). This raw data from >> devfreq_event data would be used for the governor of devfreq subsystem. >> - devfreq_event device : Provide raw data for governor of existing devfreq >> device >> - devfreq device : Monitor device state and change frequency/voltage >> of device >> using the raw data from devfreq_event device >> >> The devfreq subsystem support generic DVFS(Dynamic Voltage/Frequency Scaling) >> for Non-CPU Devices. The devfreq device would dertermine current device state >> using various governor (e.g., ondemand, performance, powersave). After >> completed >> determination of system state, devfreq device would change the >> frequency/voltage >> of devfreq device according to the result of governor. >> >> But, devfreq governor must need basic data which indicates current device >> state. >> Existing devfreq subsystem only consider devfreq device which check current >> system >> state and determine proper system state using basic data. There is no >> subsystem >> for device providing basic data to devfreq device. >> >> The devfreq subsystem must need devfreq_event device(data-provider device) >> for >> existing devfreq device. So, this patch add new devfreq_event class for >> devfreq_event device which read various basic data(e.g, memory bus >> utilization, >> GPU utilization) and provide measured data to existing devfreq device through >> standard APIs of devfreq_event class. >> >> The following description explains the feature of two kind of devfreq class: >> - devfreq class (existing) >> : devfreq consumer device use raw data from devfreq_event device for >>determining proper current system state and change voltage/frequency >>dynamically using various governors. >> >> - devfreq_event class (new) >> : Provide measured raw data to devfreq device for governor >> >> Cc: MyungJoo Ham >> Cc: Kyungmin Park >> Signed-off-by: Chanwoo Choi >> --- >> drivers/devfreq/Kconfig | 2 + >> drivers/devfreq/Makefile| 5 +- >> drivers/devfreq/devfreq-event.c | 302 >> >> drivers/devfreq/event/Makefile | 1 + >> include/linux/devfreq.h | 141 +++ >> 5 files changed, 450 insertions(+), 1 deletion(-) >> create mode 100644 drivers/devfreq/devfreq-event.c >> create mode 100644 drivers/devfreq/event/Makefile >> >> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig >> index faf4e70..4d15b62 100644 >> --- a/drivers/devfreq/Kconfig >> +++ b/drivers/devfreq/Kconfig >> @@ -87,4 +87,6 @@ config ARM_EXYNOS5_BUS_DEVFREQ >>It reads PPMU counters of memory controllers and adjusts the >>operating frequencies and voltages with OPP support. >> >> +comment "DEVFREQ Event Drivers" >> + >> endif # PM_DEVFREQ >> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile >> index 16138c9..a1ffabe 100644 >> --- a/drivers/devfreq/Makefile >> +++ b/drivers/devfreq/Makefile >> @@ -1,4 +1,4 @@ >> -obj-$(CONFIG_PM_DEVFREQ)+= devfreq.o >> +obj-$(CONFIG_PM_DEVFREQ)+= devfreq.o devfreq-event.o >> obj-$(CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND) += governor_simpleondemand.o >> obj-$(CONFIG_DEVFREQ_GOV_PERFORMANCE) += governor_performance.o >> obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE) += governor_powersave.o >> @@ -7,3 +7,6 @@ obj-$(CONFIG_DEVFREQ_GOV_USERSPACE) += governor_userspace.o >> # DEVFREQ Drivers >> obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ) += exynos/ >> obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ) += exynos/ >> + >> +# DEVFREQ Event Drivers >> +obj-$(CONFIG_PM_DEVFREQ)+= event/ >> diff --git a/drivers/devfreq/devfreq-event.c >> b/drivers/devfreq/devfreq-event.c >> new file mode 100644 >> index 000..b47329f >> --- /dev/null >> +++ b/drivers/devfreq/devfreq-event.c >> @@ -0,0 +1,302 @@ >> +/* >> + * devfreq-event: Generic DEVFREQ Event class driver >> + * >> + * Copyright (C) 2014 Samsung Electronics >> + * Chanwoo Choi >> + * >> + * 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 >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include "governor.h" >> + >> +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); >
Re: [PATCH RFT 1/2] drivers: bus: check cci device tree node status
On Wed, 10 Dec 2014, Abhilash Kesavan wrote: > Hi, > > On Fri, Nov 28, 2014 at 8:20 PM, Abhilash Kesavan > wrote: > > The arm-cci driver completes the probe sequence even if the cci node is > > marked as disabled. Add a check in the driver to honour the cci status > > in the device tree. > > > > Signed-off-by: Abhilash Kesavan > > This patch helps disable CCI on the Arndale Octa board thus resolving > some imprecise aborts seen on that board. Kindly review. Acked-by: Nicolas Pitre > > Regards, > Abhilash > > --- > > drivers/bus/arm-cci.c |3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c > > index 860da40..0ce5e2d 100644 > > --- a/drivers/bus/arm-cci.c > > +++ b/drivers/bus/arm-cci.c > > @@ -1312,6 +1312,9 @@ static int cci_probe(void) > > if (!np) > > return -ENODEV; > > > > + if (!of_device_is_available(np)) > > + return -ENODEV; > > + > > cci_config = of_match_node(arm_cci_matches, np)->data; > > if (!cci_config) > > return -ENODEV; > > -- > > 1.7.9.5 > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/15] Resource tracking/allocation framework
On Wed, Dec 10, 2014 at 06:23:49PM +0100, A H wrote: > 10 gru 2014 17:16 "Russell King - ARM Linux" > napisał(a): > > > > On Wed, Dec 10, 2014 at 04:48:18PM +0100, Andrzej Hajda wrote: > > > 3. There are drivers which can work without specific resource, but if > > > the resource becomes available/unavailable it can do some additional > stuff. > > > An example of such driver is DRM driver (more precisely > drm_connector) - > > > it can start without attached drm_panel, but if the panel becomes > available it > > > can react by generating HPD event and start using it. > > > > Bad example, and actually incorrect. DRM connectors are referenced in > > userspace by an IDR number, which can be re-used in the case of a > > connector appearing, disappearing, and then a different connector > > re-appearing. > > But it is not about reappearing of drm_connector, it is about reappearing > of drm_panel which is fortunately not a part of drm driver. Connector here > is only consumer of drm_panel which should have possibility to receive > notifications on panel (dis-)appearance. Okay, so that's exactly like a panel being "hotplugged" to the connector, which should be fine. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk: samsung: Fix Exynos 5420 pinctrl setup and clock disable failure due to domain being gated
Sylwester Nawrocki writes: > On 09/12/14 13:59, Krzysztof Kozlowski wrote: >> On pią, 2014-12-05 at 15:15 +0100, Krzysztof Kozlowski wrote: >>> > Audio subsystem clocks are located in separate block. On Exynos 5420 if >>> > clock for this block (from main clock domain) 'mau_epll' is gated then >>> > any read or write to audss registers will block. >>> > >>> > This kind of boot hang was observed on Arndale Octa and Peach Pi/Pit >>> > after introducing runtime PM to pl330 DMA driver. After that commit the >>> > 'mau_epll' was gated, because the "amba" clock was disabled and there >>> > were no more users of mau_epll. >>> > >>> > The system hang on one of steps: >>> > 1. Disabling unused clocks from audss block. >>> > 2. During audss GPIO setup (just before probing i2s0 because >>> >samsung_pinmux_setup() tried to access memory from audss block which >>> > was >>> >gated. >>> > >>> > Add a workaround for this by enabling the 'mau_epll' clock in probe. >>> > >>> > Signed-off-by: Krzysztof Kozlowski >>> > --- >>> > drivers/clk/samsung/clk-exynos-audss.c | 29 - >>> > 1 file changed, 28 insertions(+), 1 deletion(-) >> >> Sorry for pinging so quick but merge window is open and it looks like >> booting Exynos542x boards will be broken (because pl330 will no longer >> hold adma clock enabled so whole audss domain will be gated). >> >> This is a non-intrusive workaround for that issue, as wanted by >> Sylwester: >> https://lkml.org/lkml/2014/12/5/223 >> >> Any comments on this? > > The patch looks OK to me, it would be good though if someone else > has confirmed it fixes the bug. I don't have any clock patches queued > at the moment. Perhaps you could apply it directly, Mike ? I confirm it fixes the boot hang in linux-next (next-20141210) on my exynos5800-peach-pi and exynos5420-arndale-octa. Tested both exynos_defconfig and multi_v7_defconfig. Tested-by: Kevin Hilman Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] drm/exynos/fimd: only finish pageflip if START == START_S
From: Daniel Kurtz
A framebuffer gets committed to FIMD's default window like this:
exynos_drm_crtc_update()
exynos_plane_commit()
fimd_win_commit()
fimd_win_commit() programs BUF_START[0]. At each vblank, FIMD hardware
copies the value from BUF_START to BUF_START_S (BUF_START's shadow
register), starts scanning out from BUF_START_S, and asserts its irq.
This irq is handled by fimd_irq_handler(), which calls
exynos_drm_crtc_finish_pageflip() to free the old buffer that FIMD just
finished scanning out, and potentially commit the next pending flip.
There is a race, however, if fimd_win_commit() programs BUF_START(0)
between the actual vblank irq, and its corresponding fimd_irq_handler().
=> FIMD vblank: BUF_START_S[0] := BUF_START[0], and irq asserted
| => fimd_win_commit(0) writes new BUF_START[0]
|exynos_drm_crtc_try_do_flip() marks exynos_fb as prepared
=> fimd_irq_handler()
exynos_drm_crtc_finish_pageflip() sees prepared exynos_fb,
and unmaps "old" fb
==> but, since BUF_START_S[0] still points to that "old" fb...
==> FIMD iommu fault
This patch ensures that fimd_irq_handler() only calls
exynos_drm_crtc_finish_pageflip() if any previously scheduled flip
has really completed.
This works because exynos_drm_crtc's flip fifo ensures that
fimd_win_commit() is never called more than once per
exynos_drm_crtc_finish_pageflip().
Signed-off-by: Daniel Kurtz
Reviewed-by: Sean Paul
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 31 ---
include/video/samsung_fimd.h | 1 +
2 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index e5810d1..95bac27 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -55,6 +55,7 @@
#define VIDOSD_D(win) (VIDOSD_BASE + 0x0C + (win) * 16)
#define VIDWx_BUF_START(win, buf) (VIDW_BUF_START(buf) + (win) * 8)
+#define VIDWx_BUF_START_S(win, buf) (VIDW_BUF_START_S(buf) + (win) * 8)
#define VIDWx_BUF_END(win, buf)(VIDW_BUF_END(buf) + (win) * 8)
#define VIDWx_BUF_SIZE(win, buf) (VIDW_BUF_SIZE(buf) + (win) * 4)
@@ -1039,6 +1040,7 @@ static irqreturn_t fimd_irq_handler(int irq, void *dev_id)
{
struct fimd_context *ctx = (struct fimd_context *)dev_id;
u32 val, clear_bit;
+ u32 start, start_s;
val = readl(ctx->regs + VIDINTCON1);
@@ -1051,19 +1053,34 @@ static irqreturn_t fimd_irq_handler(int irq, void
*dev_id)
goto out;
if (ctx->i80_if) {
- exynos_drm_crtc_finish_pageflip(ctx->drm_dev, ctx->pipe);
-
/* Exits triggering mode */
atomic_set(&ctx->triggering, 0);
} else {
drm_handle_vblank(ctx->drm_dev, ctx->pipe);
+ }
+
+ /*
+* Ensure finish_pageflip is called iff a pending flip has completed.
+* This works around a race between a page_flip request and the latency
+* between vblank interrupt and this irq_handler:
+* => FIMD vblank: BUF_START_S[0] := BUF_START[0], and asserts irq
+* | => fimd_win_commit(0) writes new BUF_START[0]
+* |exynos_drm_crtc_try_do_flip() marks exynos_fb as prepared
+* => fimd_irq_handler()
+* exynos_drm_crtc_finish_pageflip() sees prepared exynos_fb,
+* and unmaps "old" fb
+* ==> but, since BUF_START_S[0] still points to that "old" fb...
+* ==> FIMD iommu fault
+*/
+ start = readl(ctx->regs + VIDWx_BUF_START(0, 0));
+ start_s = readl(ctx->regs + VIDWx_BUF_START_S(0, 0));
+ if (start == start_s)
exynos_drm_crtc_finish_pageflip(ctx->drm_dev, ctx->pipe);
- /* set wait vsync event to zero and wake up queue. */
- if (atomic_read(&ctx->wait_vsync_event)) {
- atomic_set(&ctx->wait_vsync_event, 0);
- wake_up(&ctx->wait_vsync_queue);
- }
+ /* set wait vsync event to zero and wake up queue. */
+ if (atomic_read(&ctx->wait_vsync_event)) {
+ atomic_set(&ctx->wait_vsync_event, 0);
+ wake_up(&ctx->wait_vsync_queue);
}
out:
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index a20e4a3..f81d081 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -291,6 +291,7 @@
/* Video buffer addresses */
#define VIDW_BUF_START(_buff) (0xA0 + ((_buff) * 8))
+#define VIDW_BUF_START_S(_buff) (0x40A0 + ((_buff) * 8))
#define VIDW_BUF_START1(_buff) (0xA4 + ((_buff) * 8))
#define VIDW_BUF_END(_buff)(0xD0 + ((_buff) * 8))
#define VIDW_BUF_END1(_buff) (0xD4 + ((_buff) * 8))
--
1.9.3
--
To unsubscribe from this list: send the li
Re: [PATCH v4 0/3] Fix Arndale Octa/Peach Pi boot on Audio subsystem clocks
Hi Krzysztof, Krzysztof Kozlowski writes: > Changes since v3 > > 1. Patch 1/3: Fix issues pointed by Sylwester. > 2. Add Javier's tested-by [1] I tested this series on top of next-20141210 (exynos_defconfig and multi_v7_defconfig) on exynos5800-peach-pi and exynos5420-arndale-octa it fixes the boot hangs I was seeing with linux-next on those platforms. Feel free to add: Tested-by: Kevin Hilman Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/15] Resource tracking/allocation framework
On Wed, Dec 10, 2014 at 04:48:18PM +0100, Andrzej Hajda wrote: > 3. There are drivers which can work without specific resource, but if > the resource becomes available/unavailable it can do some additional stuff. > An example of such driver is DRM driver (more precisely drm_connector) - > it can start without attached drm_panel, but if the panel becomes available > it > can react by generating HPD event and start using it. Bad example, and actually incorrect. DRM connectors are referenced in userspace by an IDR number, which can be re-used in the case of a connector appearing, disappearing, and then a different connector re-appearing. DRM really is *not* safe to hotplug like this: DRM is more a card-level thing, which is why we have the component helpers - which allow us to merge several devices into one logical card-like device in a generic manner. DRM needs a stable picture of the CRTCs, encoders and connectors, which should _never_ change during the lifetime of the DRM device. Devices attached to connectors can be hotplugged, but that's about the limit of hot-plugging in DRM. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 04/15] regulator: add restrack support
On Wed, Dec 10, 2014 at 04:48:22PM +0100, Andrzej Hajda wrote: > Regulators supports various methods of lookup. > The patch adds restrack support only to DT based regulators. Why, what does this mean and how might one use it? I've not looked at the code since I don't know what it's supposed to accomplish... One very high level thing is that anything that only works for DT only seems to be a non-starter, the API should be hiding details of the firmware interface. signature.asc Description: Digital signature
[RFC 03/15] drm/panel: add restrack support
The patch adds Device Tree restrack support to drm/panel framework.
As panels supports only Device Tree based lookup all panels can be
converted to restrack.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/drm_panel.c | 97 +
include/drm/drm_panel.h | 4 ++
include/linux/restrack.h| 2 +
3 files changed, 103 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 2ef988e..db04696 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -22,7 +22,9 @@
*/
#include
+#include
#include
+#include
#include
#include
@@ -41,6 +43,7 @@ int drm_panel_add(struct drm_panel *panel)
mutex_lock(&panel_lock);
list_add_tail(&panel->list, &panel_list);
mutex_unlock(&panel_lock);
+ restrack_up(RESTRACK_TYPE_DRM_PANEL, panel->dev->of_node, panel);
return 0;
}
@@ -48,6 +51,7 @@ EXPORT_SYMBOL(drm_panel_add);
void drm_panel_remove(struct drm_panel *panel)
{
+ restrack_down(RESTRACK_TYPE_DRM_PANEL, panel->dev->of_node, panel);
mutex_lock(&panel_lock);
list_del_init(&panel->list);
mutex_unlock(&panel_lock);
@@ -93,6 +97,99 @@ struct drm_panel *of_drm_find_panel(struct device_node *np)
return NULL;
}
EXPORT_SYMBOL(of_drm_find_panel);
+
+struct drm_panel_restrack_desc {
+ struct drm_panel **ptr;
+ const char *name;
+ int port;
+ struct restrack_desc desc;
+};
+
+static int drm_panel_restrack_init(struct device *dev,
+ struct restrack_desc *desc)
+{
+ struct drm_panel_restrack_desc *rd = restrack_desc_to_rd(rd, desc);
+ struct device_node *np;
+
+ if (rd->name) {
+ desc->if_id = of_parse_phandle(dev->of_node, rd->name, 0);
+ goto end;
+ }
+
+ np = NULL;
+ while ((np = of_graph_get_next_endpoint(dev->of_node, np))) {
+ struct of_endpoint ep;
+
+ of_graph_parse_endpoint(np, &ep);
+ if (ep.port != rd->port)
+ continue;
+ desc->if_id = of_graph_get_remote_port_parent(np);
+ of_node_put(np);
+ break;
+ }
+
+end:
+ return desc->if_id ? 0 : -EINVAL;
+}
+
+static void drm_panel_restrack_destroy(struct device *dev,
+ struct restrack_desc *desc)
+{
+ struct drm_panel_restrack_desc *rd = restrack_desc_to_rd(rd, desc);
+
+ of_node_put(desc->if_id);
+ kfree(rd);
+}
+
+static int drm_panel_restrack_ifup(struct device *dev,
+ struct restrack_desc *desc, void *data)
+{
+ struct drm_panel_restrack_desc *rd = restrack_desc_to_rd(rd, desc);
+
+ *rd->ptr = data;
+ return PTR_ERR_OR_ZERO(*rd->ptr);
+}
+
+static void drm_panel_restrack_ifdown(struct device *dev,
+ struct restrack_desc *desc, void *data)
+{
+ struct drm_panel_restrack_desc *rd = restrack_desc_to_rd(rd, desc);
+
+ *rd->ptr = ERR_PTR(-EPROBE_DEFER);
+}
+
+static const struct restrack_ops drm_panel_restrack_ops = {
+ .if_type = RESTRACK_TYPE_DRM_PANEL,
+ .init = drm_panel_restrack_init,
+ .destroy = drm_panel_restrack_destroy,
+ .if_up = drm_panel_restrack_ifup,
+ .if_down = drm_panel_restrack_ifdown,
+};
+
+/**
+ * drm_panel_restrack_desc - drm_panel resource descriptor allocator
+ * @panel: pointer to variable which will be set to drm_panel handle
+ * @prop_name: property name containing phandle to the panel node, it can be
+ *NULL if driver uses only of_graph
+ * @port: of_graph port number in case of_graph is used
+ *
+ * The function creates resource description for panel, which shall be used by
+ * *restrack_register functions.
+ */
+struct restrack_desc *drm_panel_restrack_desc(struct drm_panel **panel,
+ const char *prop_name, int port)
+{
+ struct drm_panel_restrack_desc *rd;
+
+ RESTRACK_DESC_ALLOC(rd, drm_panel_restrack_ops, panel, prop_name);
+ if (!rd)
+ return ERR_PTR(-ENOMEM);
+
+ rd->port = port;
+ return &rd->desc;
+}
+EXPORT_SYMBOL_GPL(drm_panel_restrack_desc);
+
#endif
MODULE_AUTHOR("Thierry Reding ");
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 1fbcc96..46eb88e 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -130,6 +130,10 @@ int drm_panel_detach(struct drm_panel *panel);
#ifdef CONFIG_OF
struct drm_panel *of_drm_find_panel(struct device_node *np);
+
+struct restrack_desc;
+struct restrack_desc *drm_panel_restrack_desc(struct drm_panel **panel,
+ const char *prop_name, int port);
#else
static inline struct drm_panel *of_drm_find_panel(struct device_node *np)
{
diff --git a/include/linux/restrack.h b/include/linux/restrack.h
index 6cf8144f..af5b617 100644
--- a/include/linux/restrack.h
+++ b/include/linux/restrack.h
@@ -3,6 +3,8 @@
#include
+#define RESTRACK_TYPE_DRM_PANEL 1
+
struct
[RFC 02/15] drivers/base: add restrack framework
restrack framework allows tracking presence of resources with dynamic life
time. Typical example of such resources are all resources provided by device
drivers, for example clocks, phys, regulators. Since drivers can be bound and
unbound dynamically and unconditionally, resources provided by such drivers
can appear and disappear at any time.
To use restrack in consumer user should call one of *restrack_register
functions. In the function arguments consumer should provide callback and
description of resources which should be tracked. Each resource description
should contain pointer to variable where restrack should store address of
allocated resource and parameters describing specific resource, for example
in case of clock it should be clock name and in case of gpio it should be
gpio name and flags.
The callback should have two arguments:
- dev - device for which callback have been registered,
- ret - return code.
If callback is called with ret == 0 it means all tracked resources are
present, allocated and provided resource pointers are set accordingly.
In case ret == -EPROBE_DEFER it means all resources are present but at least
one of the resources are to be removed after return form the callback.
Simplified example of framework usage on LCD panel driver.
static int lcd_probe(...)
{
struct restrack *rtrack;
(...initialization w/o resource allocation ...)
rtrack = devm_restrack_register(dev, lcd_callback,
regulator_bulk_restrack_desc(&ctx->supplies[0]),
regulator_bulk_restrack_desc(&ctx->supplies[1]),
clk_restrack_desc(&ctx->pll_clk, "pll_clk"),
clk_restrack_desc(&ctx->bus_clk, "bus_clk"),
phy_restrack_desc(&ctx->phy, "dsim"),
);
return PTR_ERR_OR_NULL(rtrack);
}
void lcd_callback(struct device *dev, int ret)
{
struct lcd_ctx *ctx = dev_get_drvdata(dev);
if (ret == 0)
drm_panel_add(&ctx->panel);
else if (ret == -EPROBE_DEFER)
drm_panel_remove(&ctx->panel);
else
dev_err(dev, "restrack error %d\n", ret);
}
Please note few things:
1. drm_panel_add calls restrack_up and drm_panel_remove calls restrack_down.
It is OK to call restrack framework from the callback.
2. In lcd_callback if ret is 0 or -EDEFER_PROBE all resources are valid, ie
driver for example can call clk_prepare_enable(ctx->pll_clk).
3. No mutexes are needed to protect lcd_ctx in lcd_callback call.
4. All resources are freed by restrack_unregister, which in this case is
called by devres framework.
To add restrack support to specific framework following things should be
defined:
- structure describing resource with embedded restrack_desc structure,
- at least one exported allocator of such structure,
- few simple operations according to description of struct restrack_ops,
- notifications about adding/removal of the resource.
For details please look at implementations.
Signed-off-by: Andrzej Hajda
---
drivers/base/Makefile| 2 +-
drivers/base/restrack.c | 344 +++
include/linux/restrack.h | 137 +++
3 files changed, 482 insertions(+), 1 deletion(-)
create mode 100644 drivers/base/restrack.c
create mode 100644 include/linux/restrack.h
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 4edff7d..cf9a21e 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -4,7 +4,7 @@ obj-y := component.o core.o bus.o dd.o
syscore.o \
driver.o class.o platform.o \
cpu.o firmware.o init.o map.o devres.o \
attribute_container.o transport_class.o \
- topology.o container.o track.o
+ topology.o container.o track.o restrack.o
obj-$(CONFIG_DEVTMPFS) += devtmpfs.o
obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
obj-y += power/
diff --git a/drivers/base/restrack.c b/drivers/base/restrack.c
new file mode 100644
index 000..e16d8ed
--- /dev/null
+++ b/drivers/base/restrack.c
@@ -0,0 +1,344 @@
+/*
+ * Resource tracking framework
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ * Andrzej Hajda
+ *
+ * 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.
+ *
+ * restrack framework allows to track presence of resources with dynamic life
+ * time. Typical example of such resources are all resources provided by device
+ * drivers, for example clocks, phys, regulators. Since drivers can be bound
and
+ * unbound dynamically and unconditionally, resources provided by such drivers
+ * can appear and disappear at any time.
+ *
+ * To use restrack in consumer user should call one of *restrack_register
+ * functions. In the function arguments consumer should provide callback
[RFC 04/15] regulator: add restrack support
Regulators supports various methods of lookup.
The patch adds restrack support only to DT based regulators.
Signed-off-by: Andrzej Hajda
---
drivers/regulator/core.c | 77 ++
include/linux/regulator/consumer.h | 10 +
include/linux/restrack.h | 1 +
3 files changed, 88 insertions(+)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index cd87c0c..5641e85 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#define CREATE_TRACE_POINTS
#include
@@ -3733,6 +3734,10 @@ add_dev:
rdev_init_debugfs(rdev);
out:
mutex_unlock(®ulator_list_mutex);
+
+ if (rdev->dev.of_node)
+ restrack_up(RESTRACK_TYPE_REGULATOR, rdev->dev.of_node, rdev);
+
return rdev;
unset_supplies:
@@ -3767,6 +3772,9 @@ void regulator_unregister(struct regulator_dev *rdev)
if (rdev == NULL)
return;
+ if (rdev->dev.of_node)
+ restrack_down(RESTRACK_TYPE_REGULATOR, rdev->dev.of_node, rdev);
+
if (rdev->supply) {
while (rdev->use_count--)
regulator_disable(rdev->supply);
@@ -3971,6 +3979,75 @@ static const struct file_operations supply_map_fops = {
#endif
};
+struct regulator_restrack_desc {
+ struct regulator **ptr;
+ const char *name;
+ struct restrack_desc desc;
+};
+
+static int regulator_restrack_init(struct device *dev,
+ struct restrack_desc *desc)
+{
+ struct regulator_restrack_desc *rd = restrack_desc_to_rd(rd, desc);
+
+ desc->if_id = of_get_regulator(dev, rd->name);
+ return PTR_ERR_OR_ZERO(desc->if_id);
+}
+
+static void regulator_restrack_destroy(struct device *dev,
+ struct restrack_desc *desc)
+{
+ struct regulator_restrack_desc *rd = restrack_desc_to_rd(rd, desc);
+
+ of_node_put(desc->if_id);
+ kfree(rd);
+}
+
+static int regulator_restrack_ifup(struct device *dev,
+ struct restrack_desc *desc, void *data)
+{
+ struct regulator_restrack_desc *rd = restrack_desc_to_rd(rd, desc);
+
+ *rd->ptr = regulator_get(dev, rd->name);
+ return PTR_ERR_OR_ZERO(*rd->ptr);
+}
+
+static void regulator_restrack_ifdown(struct device *dev,
+ struct restrack_desc *desc, void *data)
+{
+ struct regulator_restrack_desc *rd = restrack_desc_to_rd(rd, desc);
+
+ regulator_put(*rd->ptr);
+ *rd->ptr = ERR_PTR(-EPROBE_DEFER);
+}
+
+static const struct restrack_ops regulator_restrack_ops = {
+ .if_type = RESTRACK_TYPE_REGULATOR,
+ .init = regulator_restrack_init,
+ .destroy = regulator_restrack_destroy,
+ .if_up = regulator_restrack_ifup,
+ .if_down = regulator_restrack_ifdown,
+};
+
+/**
+ * regulator_restrack_desc - regulator resource descriptor allocator
+ * @regulator: pointer to variable which will be set to regulator handle
+ * @name: name of regulator
+ *
+ * The function creates resource description for regulator, which shall be used
+ * by *restrack_register functions.
+ */
+struct restrack_desc *regulator_restrack_desc(struct regulator **regulator,
+ const char *name)
+{
+ struct regulator_restrack_desc *rd;
+
+ RESTRACK_DESC_ALLOC(rd, regulator_restrack_ops, regulator, name);
+
+ return rd ? &rd->desc : ERR_PTR(-ENOMEM);
+}
+EXPORT_SYMBOL_GPL(regulator_restrack_desc);
+
static int __init regulator_init(void)
{
int ret;
diff --git a/include/linux/regulator/consumer.h
b/include/linux/regulator/consumer.h
index f540b14..69e71ebb 100644
--- a/include/linux/regulator/consumer.h
+++ b/include/linux/regulator/consumer.h
@@ -551,4 +551,14 @@ static inline int
regulator_is_supported_voltage_tol(struct regulator *regulator
target_uV + tol_uV);
}
+struct restrack_desc;
+struct restrack_desc *regulator_restrack_desc(struct regulator **regulator,
+ const char *supply);
+
+static inline struct restrack_desc *
+regulator_bulk_restrack_desc(struct regulator_bulk_data *data)
+{
+ return regulator_restrack_desc(&data->consumer, data->supply);
+}
+
#endif
diff --git a/include/linux/restrack.h b/include/linux/restrack.h
index af5b617..4e4eec6 100644
--- a/include/linux/restrack.h
+++ b/include/linux/restrack.h
@@ -4,6 +4,7 @@
#include
#define RESTRACK_TYPE_DRM_PANEL 1
+#define RESTRACK_TYPE_REGULATOR 2
struct device;
struct restrack_ctx;
--
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
[RFC 01/15] drivers/base: add track framework
track is a generic framework for safe tracking presence of any kernel objects
having an id. There are no special requirements about type of object or its
id. Id shall be unique.
Typical usage of the framework by consumer looks as follow:
1. Consumer registers notifier callback for objects with given id.
2. If the object is present consumer is notified immediately, otherwise it
will be notified immediately after object creation.
3. If the object is about to be removed notification is sent to the consumer
just before removal.
4. When consumer do not need the object anymore it unregisters its notifier
callback. If the object is present during notifier unregistration
notification about removal of the object is sent to the consumer.
All notification callbacks are serialized so the consumer do not need use
additional mechanisms to prevent callback races. Consumer should assume that
object is valid only between up and down notification callbacks inclusive.
Framework usage by object provider is simple:
1. When object becomes available it notifies framework about it.
2. When object becomes unavailable it notifies framework about it.
Provider should take care of calling notifications synchronously in proper
order.
The framework does not uses locks during notification calls, so it is safe
to call framework functions from the callbacks. This feature allows to model
complex object dependencies without deadlock risk.
Some framework functions can sleep so the framework should be used in process
context.
Signed-off-by: Andrzej Hajda
---
drivers/base/Makefile | 2 +-
drivers/base/track.c | 241 ++
include/linux/track.h | 148 +++
3 files changed, 390 insertions(+), 1 deletion(-)
create mode 100644 drivers/base/track.c
create mode 100644 include/linux/track.h
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 6922cd6..4edff7d 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -4,7 +4,7 @@ obj-y := component.o core.o bus.o dd.o
syscore.o \
driver.o class.o platform.o \
cpu.o firmware.o init.o map.o devres.o \
attribute_container.o transport_class.o \
- topology.o container.o
+ topology.o container.o track.o
obj-$(CONFIG_DEVTMPFS) += devtmpfs.o
obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
obj-y += power/
diff --git a/drivers/base/track.c b/drivers/base/track.c
new file mode 100644
index 000..8cf0492
--- /dev/null
+++ b/drivers/base/track.c
@@ -0,0 +1,241 @@
+/*
+ * Generic framework for tracking named object
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ * Andrzej Hajda
+ *
+ * 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.
+ *
+ * track is a generic framework for safe tracking presence of any kernel
objects
+ * having an id. There are no special requirements about type of object or its
+ * id. Id shall be unique.
+ * Typical usage of the framework by consumer looks as follow:
+ * 1. Consumer registers notifier callback for objects with given id.
+ * 2. If the object is present consumer is notified immediately, otherwise it
+ *will be notified immediately after object creation.
+ * 3. If the object is about to be removed notification is sent to the consumer
+ *just before removal.
+ * 4. When consumer do not need the object anymore it unregisters its notifier
+ *callback. If the object is present during notifier unregistration
+ *notification about removal of the object is sent to the consumer.
+ *
+ * All notification callbacks are serialized so the consumer do not need use
+ * additional mechanisms to prevent callback races. Consumer should assume that
+ * object is valid only between up and down notification callbacks inclusive.
+ *
+ * Framework usage by object provider is simple:
+ * 1. When object becomes available it notifies framework about it.
+ * 2. When object becomes unavailable it notifies framework about it.
+ *
+ * Provider should take care of calling notifications synchronously in proper
+ * order.
+ *
+ * The framework does not uses locks during notification calls, so it is safe
+ * to call framework functions from the callbacks. This feature allows to model
+ * complex object dependencies without deadlock risk.
+ *
+ * Some framework functions can sleep so the framework should be used in
process
+ * context.
+ *
+ */
+#include
+#include
+#include
+
+struct track_task {
+ struct list_head list;
+ enum track_task_id task_id;
+
+ unsigned long type;
+ const void *id;
+ union {
+ void *data;
+ struct track_block *itb;
+ };
+};
+
+struct track_node {
+ struct list_head list;
+
[RFC 05/15] gpio: move DT parsing code to separate functions
The patch moves Device Tree parsing logic to separate
function.
Signed-off-by: Andrzej Hajda
---
drivers/gpio/gpiolib-of.c | 59 +--
drivers/gpio/gpiolib.c| 33 +++---
drivers/gpio/gpiolib.h| 4 ++--
3 files changed, 53 insertions(+), 43 deletions(-)
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index 604dbe6..4707727 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -28,7 +28,7 @@
/* Private data structure for of_gpiochip_find_and_xlate */
struct gg_data {
enum of_gpio_flags *flags;
- struct of_phandle_args gpiospec;
+ struct of_phandle_args *gpiospec;
struct gpio_desc *out_gpio;
};
@@ -39,12 +39,12 @@ static int of_gpiochip_find_and_xlate(struct gpio_chip *gc,
void *data)
struct gg_data *gg_data = data;
int ret;
- if ((gc->of_node != gg_data->gpiospec.np) ||
- (gc->of_gpio_n_cells != gg_data->gpiospec.args_count) ||
+ if ((gc->of_node != gg_data->gpiospec->np) ||
+ (gc->of_gpio_n_cells != gg_data->gpiospec->args_count) ||
(!gc->of_xlate))
return false;
- ret = gc->of_xlate(gc, &gg_data->gpiospec, gg_data->flags);
+ ret = gc->of_xlate(gc, gg_data->gpiospec, gg_data->flags);
if (ret < 0)
return false;
@@ -52,61 +52,54 @@ static int of_gpiochip_find_and_xlate(struct gpio_chip *gc,
void *data)
return true;
}
-/**
- * of_get_named_gpiod_flags() - Get a GPIO descriptor and flags for GPIO API
- * @np:device node to get GPIO from
- * @propname: property name containing gpio specifier(s)
- * @index: index of the GPIO
- * @flags: a flags pointer to fill in
- *
- * Returns GPIO descriptor to use with Linux GPIO API, or one of the errno
- * value on the error condition. If @flags is not NULL the function also fills
- * in flags for the GPIO.
- */
-struct gpio_desc *of_get_named_gpiod_flags(struct device_node *np,
-const char *propname, int index, enum of_gpio_flags *flags)
+struct gpio_desc *of_get_gpiod_by_spec(struct of_phandle_args *spec,
+ enum of_gpio_flags *flags)
{
/* Return -EPROBE_DEFER to support probe() functions to be called
* later when the GPIO actually becomes available
*/
struct gg_data gg_data = {
.flags = flags,
- .out_gpio = ERR_PTR(-EPROBE_DEFER)
+ .out_gpio = ERR_PTR(-EPROBE_DEFER),
+ .gpiospec = spec
};
- int ret;
/* .of_xlate might decide to not fill in the flags, so clear it. */
if (flags)
*flags = 0;
- ret = of_parse_phandle_with_args(np, propname, "#gpio-cells", index,
-&gg_data.gpiospec);
- if (ret) {
- pr_debug("%s: can't parse '%s' property of node '%s[%d]'\n",
- __func__, propname, np->full_name, index);
- return ERR_PTR(ret);
- }
-
gpiochip_find(&gg_data, of_gpiochip_find_and_xlate);
- of_node_put(gg_data.gpiospec.np);
- pr_debug("%s: parsed '%s' property of node '%s[%d]' - status (%d)\n",
-__func__, propname, np->full_name, index,
+ pr_debug("%s: parsed property of node '%s[%d]' - status (%d)\n",
+__func__, spec->np->full_name, spec->args[0],
PTR_ERR_OR_ZERO(gg_data.out_gpio));
+
return gg_data.out_gpio;
}
int of_get_named_gpio_flags(struct device_node *np, const char *list_name,
int index, enum of_gpio_flags *flags)
{
+ struct of_phandle_args spec;
struct gpio_desc *desc;
+ int ret;
+
+ ret = of_parse_phandle_with_args(np, list_name, "#gpio-cells", index,
+&spec);
+ if (ret) {
+ pr_debug("%s: can't parse '%s' property of node '%s[%d]'\n",
+ __func__, list_name, np->full_name, index);
+ return ret;
+ }
- desc = of_get_named_gpiod_flags(np, list_name, index, flags);
+ desc = of_get_gpiod_by_spec(&spec, flags);
if (IS_ERR(desc))
return PTR_ERR(desc);
- else
- return desc_to_gpio(desc);
+
+ of_node_put(spec.np);
+
+ return desc_to_gpio(desc);
}
EXPORT_SYMBOL(of_get_named_gpio_flags);
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index e8e98ca..78fcec9 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1470,15 +1470,13 @@ void gpiod_add_lookup_table(struct gpiod_lookup_table
*table)
mutex_unlock(&gpio_lookup_lock);
}
-static struct gpio_desc *of_find_gpio(struct device *dev, const char *con_id,
- unsigned int idx,
- enum gpio_lookup_flags *flags)
+sta
[RFC 06/15] gpio: add restrack support
GPIO supports different methods of lookup.
The patch adds restrack support only to DT based GPIOs.
Signed-off-by: Andrzej Hajda
---
drivers/gpio/gpiolib.c| 81 +++
include/linux/gpio/consumer.h | 4 +++
include/linux/restrack.h | 1 +
3 files changed, 86 insertions(+)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 78fcec9..5d85e20 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include "gpiolib.h"
@@ -278,6 +279,8 @@ int gpiochip_add(struct gpio_chip *chip)
if (status)
goto fail;
+ restrack_up(RESTRACK_TYPE_GPIO, chip->of_node, chip);
+
status = gpiochip_export(chip);
if (status)
goto fail;
@@ -313,6 +316,7 @@ void gpiochip_remove(struct gpio_chip *chip)
unsigned long flags;
unsignedid;
+ restrack_down(RESTRACK_TYPE_GPIO, chip->of_node, chip);
acpi_gpiochip_remove(chip);
spin_lock_irqsave(&gpio_lock, flags);
@@ -1770,6 +1774,83 @@ void gpiod_put(struct gpio_desc *desc)
}
EXPORT_SYMBOL_GPL(gpiod_put);
+struct gpiod_restrack_desc {
+ struct gpio_desc **ptr;
+ const char *name;
+ enum gpiod_flags flags;
+ struct of_phandle_args spec;
+ struct restrack_desc desc;
+};
+
+static int gpiod_restrack_init(struct device *dev, struct restrack_desc *desc)
+{
+ struct gpiod_restrack_desc *rd = restrack_desc_to_rd(rd, desc);
+ int ret;
+
+ ret = of_get_gpiod_spec(dev, rd->name, 0, &rd->spec);
+ if (!ret)
+ desc->if_id = rd->spec.np;
+ return ret;
+}
+
+static void gpiod_restrack_destroy(struct device *dev,
+ struct restrack_desc *desc)
+{
+ struct gpiod_restrack_desc *rd = restrack_desc_to_rd(rd, desc);
+
+ of_node_put(desc->if_id);
+ kfree(rd);
+}
+
+static int gpiod_restrack_ifup(struct device *dev, struct restrack_desc *desc,
+ void *data)
+{
+ struct gpiod_restrack_desc *rd = restrack_desc_to_rd(rd, desc);
+
+ *rd->ptr = gpiod_get(dev, rd->name, rd->flags);
+ return PTR_ERR_OR_ZERO(*rd->ptr);
+}
+
+static void gpiod_restrack_ifdown(struct device *dev,
+ struct restrack_desc *desc, void *data)
+{
+ struct gpiod_restrack_desc *rd = restrack_desc_to_rd(rd, desc);
+
+ gpiod_put(*rd->ptr);
+ *rd->ptr = ERR_PTR(-EPROBE_DEFER);
+}
+
+static const struct restrack_ops gpiod_restrack_ops = {
+ .if_type = RESTRACK_TYPE_GPIO,
+ .init = gpiod_restrack_init,
+ .destroy = gpiod_restrack_destroy,
+ .if_up = gpiod_restrack_ifup,
+ .if_down = gpiod_restrack_ifdown,
+};
+
+/**
+ * gpiod_restrack_desc - gpio resource descriptor allocator
+ * @gpiod: pointer to variable which will be set to gpiod handle
+ * @name: name of gpio
+ * @flags: gpiod flags
+ *
+ * The function creates resource description for gpio, which shall be used
+ * by *restrack_register functions.
+ */
+struct restrack_desc *gpiod_restrack_desc(struct gpio_desc **gpiod,
+ const char *con_id, enum gpiod_flags flags)
+{
+ struct gpiod_restrack_desc *rd;
+
+ RESTRACK_DESC_ALLOC(rd, gpiod_restrack_ops, gpiod, con_id);
+ if (!rd)
+ return ERR_PTR(-ENOMEM);
+
+ rd->flags = flags;
+ return &rd->desc;
+}
+EXPORT_SYMBOL_GPL(gpiod_restrack_desc);
+
#ifdef CONFIG_DEBUG_FS
static void gpiolib_dbg_show(struct seq_file *s, struct gpio_chip *chip)
diff --git a/include/linux/gpio/consumer.h b/include/linux/gpio/consumer.h
index 12f146f..55f2e4e 100644
--- a/include/linux/gpio/consumer.h
+++ b/include/linux/gpio/consumer.h
@@ -94,6 +94,10 @@ int gpiod_to_irq(const struct gpio_desc *desc);
struct gpio_desc *gpio_to_desc(unsigned gpio);
int desc_to_gpio(const struct gpio_desc *desc);
+struct restrack_desc;
+struct restrack_desc *gpiod_restrack_desc(struct gpio_desc **gpiod,
+ const char *con_id, enum gpiod_flags flags);
+
#else /* CONFIG_GPIOLIB */
static inline struct gpio_desc *__must_check __gpiod_get(struct device *dev,
diff --git a/include/linux/restrack.h b/include/linux/restrack.h
index 4e4eec6..e1aded0 100644
--- a/include/linux/restrack.h
+++ b/include/linux/restrack.h
@@ -5,6 +5,7 @@
#define RESTRACK_TYPE_DRM_PANEL 1
#define RESTRACK_TYPE_REGULATOR 2
+#define RESTRACK_TYPE_GPIO 3
struct device;
struct restrack_ctx;
--
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
[RFC 09/15] phy: add restrack support
PHYs supports different methods of lookup.
The patch adds restrack support only to DT based PHYs.
Signed-off-by: Andrzej Hajda
---
drivers/phy/phy-core.c | 90
include/linux/phy/phy.h | 3 ++
include/linux/restrack.h | 1 +
3 files changed, 94 insertions(+)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index ff5eec5..449ec4e 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
static struct class *phy_class;
static DEFINE_MUTEX(phy_provider_mutex);
@@ -754,6 +755,8 @@ struct phy_provider *__of_phy_provider_register(struct
device *dev,
list_add_tail(&phy_provider->list, &phy_provider_list);
mutex_unlock(&phy_provider_mutex);
+ restrack_up(RESTRACK_TYPE_PHY, dev->of_node, phy_provider);
+
return phy_provider;
}
EXPORT_SYMBOL_GPL(__of_phy_provider_register);
@@ -804,6 +807,9 @@ void of_phy_provider_unregister(struct phy_provider
*phy_provider)
if (IS_ERR(phy_provider))
return;
+ restrack_down(RESTRACK_TYPE_PHY, phy_provider->dev->of_node,
+ phy_provider);
+
mutex_lock(&phy_provider_mutex);
list_del(&phy_provider->list);
kfree(phy_provider);
@@ -828,6 +834,90 @@ void devm_of_phy_provider_unregister(struct device *dev,
}
EXPORT_SYMBOL_GPL(devm_of_phy_provider_unregister);
+int of_get_phy_spec(struct device *dev, const char *name,
+ struct of_phandle_args *spec)
+{
+ struct device_node *np = dev->of_node;
+ int idx;
+
+ idx = of_property_match_string(np, "phy-names", name);
+
+ return of_parse_phandle_with_args(np, "phys", "#phy-cells", idx, spec);
+}
+
+struct phy_restrack_desc {
+ struct phy **ptr;
+ const char *name;
+ struct of_phandle_args spec;
+ struct restrack_desc desc;
+};
+
+static int phy_restrack_init(struct device *dev,
+ struct restrack_desc *desc)
+{
+ struct phy_restrack_desc *rd = restrack_desc_to_rd(rd, desc);
+ int ret;
+
+ ret = of_get_phy_spec(dev, rd->name, &rd->spec);
+ if (!ret)
+ desc->if_id = rd->spec.np;
+ return ret;
+}
+
+static void phy_restrack_destroy(struct device *dev,
+ struct restrack_desc *desc)
+{
+ struct phy_restrack_desc *rd = restrack_desc_to_rd(rd, desc);
+
+ of_node_put(desc->if_id);
+ kfree(rd);
+}
+
+static int phy_restrack_ifup(struct device *dev,
+ struct restrack_desc *desc, void *data)
+{
+ struct phy_restrack_desc *rd = restrack_desc_to_rd(rd, desc);
+ struct phy_provider *phy_provider = data;
+
+ *rd->ptr = phy_provider->of_xlate(phy_provider->dev, &rd->spec);
+ return PTR_ERR_OR_ZERO(*rd->ptr);
+}
+
+static void phy_restrack_ifdown(struct device *dev,
+ struct restrack_desc *desc, void *data)
+{
+ struct phy_restrack_desc *rd = restrack_desc_to_rd(rd, desc);
+
+ *rd->ptr = ERR_PTR(-EPROBE_DEFER);
+}
+
+static const struct restrack_ops phy_restrack_ops = {
+ .if_type = RESTRACK_TYPE_PHY,
+ .init = phy_restrack_init,
+ .destroy = phy_restrack_destroy,
+ .if_up = phy_restrack_ifup,
+ .if_down = phy_restrack_ifdown,
+};
+
+/**
+ * phy_restrack_desc - phy resource descriptor allocator
+ * @phy: pointer to variable which will be set to phy handle
+ * @name: name of phy
+ *
+ * The function creates resource description for phy, which shall be used
+ * by *restrack_register functions.
+ */
+struct restrack_desc *phy_restrack_desc(struct phy **phy, const char *name)
+{
+ struct phy_restrack_desc *rd;
+
+ RESTRACK_DESC_ALLOC(rd, phy_restrack_ops, phy, name);
+
+ return rd ? &rd->desc : ERR_PTR(-ENOMEM);
+}
+EXPORT_SYMBOL_GPL(phy_restrack_desc);
+
+
/**
* phy_release() - release the phy
* @dev: the dev member within phy
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 8cb6f81..14d176c 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -174,6 +174,9 @@ struct phy_provider *__devm_of_phy_provider_register(struct
device *dev,
void of_phy_provider_unregister(struct phy_provider *phy_provider);
void devm_of_phy_provider_unregister(struct device *dev,
struct phy_provider *phy_provider);
+
+struct restrack_desc;
+struct restrack_desc *phy_restrack_desc(struct phy **phy, const char *name);
#else
static inline int phy_pm_runtime_get(struct phy *phy)
{
diff --git a/include/linux/restrack.h b/include/linux/restrack.h
index 6707dce..411d791 100644
--- a/include/linux/restrack.h
+++ b/include/linux/restrack.h
@@ -7,6 +7,7 @@
#define RESTRACK_TYPE_REGULATOR 2
#define RESTRACK_TYPE_GPIO 3
#define RESTRACK_TYPE_CLOCK 4
+#define RESTRACK_TYPE_PHY 5
struct device;
struct restrack_ctx;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to m
[RFC 07/15] clk: add DT parsing function
The patch adds function for parsing Device Tree to get
clock specifier. The function could be ultimately used
by clock core.
Signed-off-by: Andrzej Hajda
---
drivers/clk/clkdev.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index da4bda8..bd22750 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -120,6 +120,29 @@ struct clk *of_clk_get_by_name(struct device_node *np,
const char *name)
return clk;
}
EXPORT_SYMBOL(of_clk_get_by_name);
+
+static int of_get_clock_spec(struct device *dev, const char *name,
+ struct of_phandle_args *spec)
+{
+ struct device_node *np = dev->of_node;
+
+ while (np) {
+ int idx = 0;
+
+ if (name)
+ idx = of_property_match_string(np, "clock-names", name);
+
+ if (!of_parse_phandle_with_args(np, "clocks", "#clock-cells",
+ idx, spec))
+ return 0;
+
+ np = np->parent;
+ if (np && !of_get_property(np, "clock-ranges", NULL))
+ break;
+ }
+
+ return -ENOENT;
+}
#endif
/*
--
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
[RFC 10/15] drm/exynos/dsi: simplify hotplug code
Exynos DSI driver uses DSI bus attach/detach callbacks to implement
panel hotplug mechanism. The patch moves panel attachment code
from .detect callback to DSI bus callbacks. It makes the code
simpler and more straightforward.
The patch removes also redundant and lock unprotected dpms_off call
from unbind code.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 61 -
1 file changed, 38 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 05fe93d..8201d79 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -271,7 +271,6 @@ struct exynos_dsi {
struct exynos_drm_display display;
struct mipi_dsi_host dsi_host;
struct drm_connector connector;
- struct device_node *panel_node;
struct drm_panel *panel;
struct device *dev;
@@ -1154,10 +1153,11 @@ static int exynos_dsi_init(struct exynos_dsi *dsi)
static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi)
{
+ struct device_node *panel_node = dsi->panel->dev->of_node;
int ret;
int te_gpio_irq;
- dsi->te_gpio = of_get_named_gpio(dsi->panel_node, "te-gpios", 0);
+ dsi->te_gpio = of_get_named_gpio(panel_node, "te-gpios", 0);
if (!gpio_is_valid(dsi->te_gpio)) {
dev_err(dsi->dev, "no te-gpios specified\n");
ret = dsi->te_gpio;
@@ -1198,11 +1198,25 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host
*host,
struct mipi_dsi_device *device)
{
struct exynos_dsi *dsi = host_to_dsi(host);
+ struct drm_device *drm_dev = dsi->connector.dev;
+ bool changed = false;
dsi->lanes = device->lanes;
dsi->format = device->format;
dsi->mode_flags = device->mode_flags;
- dsi->panel_node = device->dev.of_node;
+
+ mutex_lock(&drm_dev->mode_config.mutex);
+
+ dsi->panel = of_drm_find_panel(device->dev.of_node);
+ if (dsi->panel) {
+ drm_panel_attach(dsi->panel, &dsi->connector);
+ if (drm_dev->mode_config.poll_enabled) {
+ dsi->connector.status = connector_status_connected;
+ changed = true;
+ }
+ }
+
+ mutex_unlock(&drm_dev->mode_config.mutex);
/*
* This is a temporary solution and should be made by more generic way.
@@ -1217,8 +1231,8 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host
*host,
return ret;
}
- if (dsi->connector.dev)
- drm_helper_hpd_irq_event(dsi->connector.dev);
+ if (changed)
+ drm_kms_helper_hotplug_event(drm_dev);
return 0;
}
@@ -1227,13 +1241,29 @@ static int exynos_dsi_host_detach(struct mipi_dsi_host
*host,
struct mipi_dsi_device *device)
{
struct exynos_dsi *dsi = host_to_dsi(host);
+ struct drm_device *drm_dev = dsi->connector.dev;
+ struct exynos_drm_display *display = dev_get_drvdata(dsi->dev);
+ bool changed = false;
exynos_dsi_unregister_te_irq(dsi);
- dsi->panel_node = NULL;
+ mutex_lock(&drm_dev->mode_config.mutex);
+
+ display->ops->dpms(display, DRM_MODE_DPMS_OFF);
+
+ if (dsi->panel) {
+ drm_panel_detach(dsi->panel);
+ dsi->panel = NULL;
+ if (drm_dev->mode_config.poll_enabled) {
+ dsi->connector.status = connector_status_disconnected;
+ changed = true;
+ }
+ }
+
+ mutex_unlock(&drm_dev->mode_config.mutex);
- if (dsi->connector.dev)
- drm_helper_hpd_irq_event(dsi->connector.dev);
+ if (changed)
+ drm_kms_helper_hotplug_event(drm_dev);
return 0;
}
@@ -1430,19 +1460,6 @@ exynos_dsi_detect(struct drm_connector *connector, bool
force)
{
struct exynos_dsi *dsi = connector_to_dsi(connector);
- if (!dsi->panel) {
- dsi->panel = of_drm_find_panel(dsi->panel_node);
- if (dsi->panel)
- drm_panel_attach(dsi->panel, &dsi->connector);
- } else if (!dsi->panel_node) {
- struct exynos_drm_display *display;
-
- display = platform_get_drvdata(to_platform_device(dsi->dev));
- exynos_dsi_dpms(display, DRM_MODE_DPMS_OFF);
- drm_panel_detach(dsi->panel);
- dsi->panel = NULL;
- }
-
if (dsi->panel)
return connector_status_connected;
@@ -1665,8 +1682,6 @@ static void exynos_dsi_unbind(struct device *dev, struct
device *master,
struct exynos_drm_display *display = dev_get_drvdata(dev);
struct exynos_dsi *dsi = display_to_dsi(display);
- exynos_dsi_dpms(display, DRM_MODE_DPMS_OFF);
-
mipi_d
[RFC 08/15] clk: add restrack support
Clocks supports different methods of lookup.
The patch adds restrack support only to DT based clocks.
Signed-off-by: Andrzej Hajda
---
drivers/clk/clk.c| 6
drivers/clk/clkdev.c | 74
include/linux/clk.h | 3 ++
include/linux/restrack.h | 1 +
4 files changed, 84 insertions(+)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 4896ae9..2c50204 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2476,6 +2477,9 @@ int of_clk_add_provider(struct device_node *np,
ret = of_clk_set_defaults(np, true);
if (ret < 0)
of_clk_del_provider(np);
+ else
+ restrack_up(RESTRACK_TYPE_CLOCK, cp->node, cp);
+
return ret;
}
@@ -2489,6 +2493,8 @@ void of_clk_del_provider(struct device_node *np)
{
struct of_clk_provider *cp;
+ restrack_down(RESTRACK_TYPE_CLOCK, np, NULL);
+
mutex_lock(&of_clk_mutex);
list_for_each_entry(cp, &of_clk_providers, link) {
if (cp->node == np) {
diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index bd22750..2532ea1 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include "clk.h"
@@ -143,6 +144,79 @@ static int of_get_clock_spec(struct device *dev, const
char *name,
return -ENOENT;
}
+
+struct clk_restrack_desc {
+ struct clk **ptr;
+ const char *name;
+ struct of_phandle_args spec;
+ struct restrack_desc desc;
+};
+
+static int clk_restrack_init(struct device *dev,
+ struct restrack_desc *desc)
+{
+ struct clk_restrack_desc *rd = restrack_desc_to_rd(rd, desc);
+ int ret;
+
+ ret = of_get_clock_spec(dev, rd->name, &rd->spec);
+ if (!ret)
+ desc->if_id = rd->spec.np;
+ return ret;
+}
+
+static void clk_restrack_destroy(struct device *dev,
+ struct restrack_desc *desc)
+{
+ struct clk_restrack_desc *rd = restrack_desc_to_rd(rd, desc);
+
+ of_node_put(desc->if_id);
+ kfree(rd);
+}
+
+static int clk_restrack_ifup(struct device *dev,
+ struct restrack_desc *desc, void *data)
+{
+ struct clk_restrack_desc *rd = restrack_desc_to_rd(rd, desc);
+
+ *rd->ptr = of_clk_get_by_clkspec(&rd->spec);
+ return PTR_ERR_OR_ZERO(*rd->ptr);
+}
+
+static void clk_restrack_ifdown(struct device *dev,
+ struct restrack_desc *desc, void *data)
+{
+ struct clk_restrack_desc *rd = restrack_desc_to_rd(rd, desc);
+
+ clk_put(*rd->ptr);
+ *rd->ptr = ERR_PTR(-EPROBE_DEFER);
+}
+
+static const struct restrack_ops clk_restrack_ops = {
+ .if_type = RESTRACK_TYPE_CLOCK,
+ .init = clk_restrack_init,
+ .destroy = clk_restrack_destroy,
+ .if_up = clk_restrack_ifup,
+ .if_down = clk_restrack_ifdown,
+};
+
+/**
+ * clk_restrack_desc - clock resource descriptor allocator
+ * @clk: pointer to variable which will be set to clock handle
+ * @name: name of clock
+ *
+ * The function creates resource description for clock, which shall be used
+ * by *restrack_register functions.
+ */
+struct restrack_desc *clk_restrack_desc(struct clk **clock, const char *name)
+{
+ struct clk_restrack_desc *rd;
+
+ RESTRACK_DESC_ALLOC(rd, clk_restrack_ops, clock, name);
+
+ return rd ? &rd->desc : ERR_PTR(-ENOMEM);
+}
+EXPORT_SYMBOL_GPL(clk_restrack_desc);
+
#endif
/*
diff --git a/include/linux/clk.h b/include/linux/clk.h
index c7f258a..28bad95 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -428,6 +428,9 @@ struct of_phandle_args;
struct clk *of_clk_get(struct device_node *np, int index);
struct clk *of_clk_get_by_name(struct device_node *np, const char *name);
struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec);
+
+struct restrack_desc;
+struct restrack_desc *clk_restrack_desc(struct clk **clock, const char *name);
#else
static inline struct clk *of_clk_get(struct device_node *np, int index)
{
diff --git a/include/linux/restrack.h b/include/linux/restrack.h
index e1aded0..6707dce 100644
--- a/include/linux/restrack.h
+++ b/include/linux/restrack.h
@@ -6,6 +6,7 @@
#define RESTRACK_TYPE_DRM_PANEL 1
#define RESTRACK_TYPE_REGULATOR 2
#define RESTRACK_TYPE_GPIO 3
+#define RESTRACK_TYPE_CLOCK 4
struct device;
struct restrack_ctx;
--
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
[RFC 13/15] drm/exynos/dpi: convert to restrack API
exynos_dpi implements drm encoder and connector. Currently its probe
was defered if the associated panel was not yet present. It is inefficient
behavior - it could start normally with connector status set to disconnected
and notify drm about status change when panel appears/disapeears.
Unfortunately drm_panel API does not provide such notifications.
restrack solves the issue above.
After converting to restrack driver have following advantages:
- correctly handles removal of resources,
- do not need to defer probing, so as a result the whole drm system
initialization will not be postponed to late initcall, unless other
components delays it,
- it starts/stops tracking panel presence only when necessary.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 80 +++-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 7 +++
2 files changed, 64 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index 91a29e1..75ee578 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -13,9 +13,9 @@
#include
#include
#include
-
#include
#include
+#include
#include
#include
@@ -34,7 +34,6 @@ enum {
struct exynos_dpi {
struct exynos_drm_display display;
struct device *dev;
- struct device_node *panel_node;
struct drm_panel *panel;
struct drm_connector connector;
@@ -42,10 +41,13 @@ struct exynos_dpi {
struct videomode *vm;
int dpms_mode;
+ struct restrack_ctx *rtrack;
};
#define connector_to_dpi(c) container_of(c, struct exynos_dpi, connector)
+struct exynos_drm_display *fimd_dev_to_display(struct device *dev);
+
static inline struct exynos_dpi *display_to_dpi(struct exynos_drm_display *d)
{
return container_of(d, struct exynos_dpi, display);
@@ -56,14 +58,18 @@ exynos_dpi_detect(struct drm_connector *connector, bool
force)
{
struct exynos_dpi *ctx = connector_to_dpi(connector);
- if (ctx->panel && !ctx->panel->connector)
- drm_panel_attach(ctx->panel, &ctx->connector);
+ if (!ctx->vm && IS_ERR(ctx->panel))
+ return connector_status_disconnected;
return connector_status_connected;
}
static void exynos_dpi_connector_destroy(struct drm_connector *connector)
{
+ struct exynos_dpi *ctx = connector_to_dpi(connector);
+
+ if (!IS_ERR(ctx->rtrack))
+ restrack_unregister(ctx->rtrack);
drm_connector_unregister(connector);
drm_connector_cleanup(connector);
}
@@ -94,7 +100,7 @@ static int exynos_dpi_get_modes(struct drm_connector
*connector)
return 1;
}
- if (ctx->panel)
+ if (!IS_ERR(ctx->panel))
return ctx->panel->funcs->get_modes(ctx->panel);
return 0;
@@ -113,6 +119,38 @@ static struct drm_connector_helper_funcs
exynos_dpi_connector_helper_funcs = {
.best_encoder = exynos_dpi_best_encoder,
};
+static void exynos_dpi_dpms(struct exynos_drm_display *display, int mode);
+
+void exynos_dpi_notifier(struct device *dev, int ret)
+{
+ struct exynos_drm_display *display = fimd_dev_to_display(dev);
+ struct exynos_dpi *ctx = display_to_dpi(display);
+ struct drm_connector *connector = &ctx->connector;
+ struct drm_device *drm_dev = connector->dev;
+ bool poll_enabled = drm_dev->mode_config.poll_enabled;
+
+ mutex_lock(&drm_dev->mode_config.mutex);
+
+ if (ret == 0) {
+ drm_panel_attach(ctx->panel, connector);
+ } else if (ret == -EPROBE_DEFER) {
+ exynos_dpi_dpms(&ctx->display, DRM_MODE_DPMS_OFF);
+ drm_panel_detach(ctx->panel);
+ ctx->panel = ERR_PTR(-EPROBE_DEFER);
+ } else {
+ dev_err(dev, "restrack error %d\n", ret);
+ poll_enabled = false;
+ }
+
+ if (poll_enabled)
+ connector->status = exynos_dpi_detect(connector, true);
+
+ mutex_unlock(&drm_dev->mode_config.mutex);
+
+ if (poll_enabled)
+ drm_kms_helper_hotplug_event(drm_dev);
+}
+
static int exynos_dpi_create_connector(struct exynos_drm_display *display,
struct drm_encoder *encoder)
{
@@ -136,12 +174,23 @@ static int exynos_dpi_create_connector(struct
exynos_drm_display *display,
drm_connector_register(connector);
drm_mode_connector_attach_encoder(connector, encoder);
+ if (ctx->vm)
+ return 0;
+
+ ctx->rtrack = restrack_register(ctx->dev, exynos_dpi_notifier,
+ drm_panel_restrack_desc(&ctx->panel, NULL, FIMD_PORT_RGB)
+ );
+
+ if (IS_ERR(ctx->rtrack))
+ DRM_ERROR("error installing panel tracker: %ld\n",
+ PTR_ERR(ctx->rtrack));
+
return 0;
}
static void exynos_dpi_poweron(struct exynos_d
[RFC 15/15] drm/panel/ld9040: convert to restrack API
Convert ld9040 panel driver to use restrack API.
As a result driver have following advantages:
- correctly handles removal of resources,
- do not need to defer probing, so as a result the panel
becomes available as soon as possible, in case of deferred
probing it was late_initcall,
- simplified initialization.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/panel/panel-ld9040.c | 41 ++--
1 file changed, 20 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-ld9040.c
b/drivers/gpu/drm/panel/panel-ld9040.c
index 3337f30..619610e 100644
--- a/drivers/gpu/drm/panel/panel-ld9040.c
+++ b/drivers/gpu/drm/panel/panel-ld9040.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -310,9 +311,22 @@ static int ld9040_parse_dt(struct ld9040 *ctx)
return 0;
}
+void ld9040_restrack_cb(struct device *dev, int ret)
+{
+ struct ld9040 *ctx = dev_get_drvdata(dev);
+
+ if (ret == 0)
+ drm_panel_add(&ctx->panel);
+ else if (ret == -EPROBE_DEFER)
+ drm_panel_remove(&ctx->panel);
+ else
+ dev_err(dev, "restrack error %d\n", ret);
+}
+
static int ld9040_probe(struct spi_device *spi)
{
struct device *dev = &spi->dev;
+ struct restrack_ctx *rtrack;
struct ld9040 *ctx;
int ret;
@@ -331,17 +345,6 @@ static int ld9040_probe(struct spi_device *spi)
ctx->supplies[0].supply = "vdd3";
ctx->supplies[1].supply = "vci";
- ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ctx->supplies),
- ctx->supplies);
- if (ret < 0)
- return ret;
-
- ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
- if (IS_ERR(ctx->reset_gpio)) {
- dev_err(dev, "cannot get reset-gpios %ld\n",
- PTR_ERR(ctx->reset_gpio));
- return PTR_ERR(ctx->reset_gpio);
- }
spi->bits_per_word = 9;
ret = spi_setup(spi);
@@ -354,16 +357,13 @@ static int ld9040_probe(struct spi_device *spi)
ctx->panel.dev = dev;
ctx->panel.funcs = &ld9040_drm_funcs;
- return drm_panel_add(&ctx->panel);
-}
-
-static int ld9040_remove(struct spi_device *spi)
-{
- struct ld9040 *ctx = spi_get_drvdata(spi);
-
- drm_panel_remove(&ctx->panel);
+ rtrack = devm_restrack_register(ctx->dev, ld9040_restrack_cb,
+ regulator_bulk_restrack_desc(&ctx->supplies[0]),
+ regulator_bulk_restrack_desc(&ctx->supplies[1]),
+ gpiod_restrack_desc(&ctx->reset_gpio, "reset", GPIOD_OUT_HIGH),
+ );
- return 0;
+ return PTR_ERR_OR_ZERO(rtrack);
}
static struct of_device_id ld9040_of_match[] = {
@@ -374,7 +374,6 @@ MODULE_DEVICE_TABLE(of, ld9040_of_match);
static struct spi_driver ld9040_driver = {
.probe = ld9040_probe,
- .remove = ld9040_remove,
.driver = {
.name = "ld9040",
.owner = THIS_MODULE,
--
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
[RFC 14/15] drm/panel/ld9040: do not power off panel on removal
Panel is powered off already by connector during drm_panel_remove call.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/panel/panel-ld9040.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-ld9040.c
b/drivers/gpu/drm/panel/panel-ld9040.c
index 08cf2c5..3337f30 100644
--- a/drivers/gpu/drm/panel/panel-ld9040.c
+++ b/drivers/gpu/drm/panel/panel-ld9040.c
@@ -361,7 +361,6 @@ static int ld9040_remove(struct spi_device *spi)
{
struct ld9040 *ctx = spi_get_drvdata(spi);
- ld9040_power_off(ctx);
drm_panel_remove(&ctx->panel);
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
[RFC 12/15] drm/exynos/dpi: use common of_graph functions
The patch removes private of_graph functions and uses common ones.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 117 +++-
1 file changed, 24 insertions(+), 93 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index 37678cf..91a29e1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -14,6 +14,7 @@
#include
#include
+#include
#include
#include
@@ -21,6 +22,15 @@
#include "exynos_drm_drv.h"
+/* possible of_graph port nodes used by device */
+enum {
+ FIMD_PORT_IN0,
+ FIMD_PORT_IN1,
+ FIMD_PORT_IN2,
+ FIMD_PORT_RGB,
+ FIMD_PORT_WRB,
+};
+
struct exynos_dpi {
struct exynos_drm_display display;
struct device *dev;
@@ -171,102 +181,12 @@ static struct exynos_drm_display_ops
exynos_dpi_display_ops = {
.dpms = exynos_dpi_dpms
};
-/* of_* functions will be removed after merge of of_graph patches */
-static struct device_node *
-of_get_child_by_name_reg(struct device_node *parent, const char *name, u32 reg)
-{
- struct device_node *np;
-
- for_each_child_of_node(parent, np) {
- u32 r;
-
- if (!np->name || of_node_cmp(np->name, name))
- continue;
-
- if (of_property_read_u32(np, "reg", &r) < 0)
- r = 0;
-
- if (reg == r)
- break;
- }
-
- return np;
-}
-
-static struct device_node *of_graph_get_port_by_reg(struct device_node *parent,
- u32 reg)
-{
- struct device_node *ports, *port;
-
- ports = of_get_child_by_name(parent, "ports");
- if (ports)
- parent = ports;
-
- port = of_get_child_by_name_reg(parent, "port", reg);
-
- of_node_put(ports);
-
- return port;
-}
-
-static struct device_node *
-of_graph_get_endpoint_by_reg(struct device_node *port, u32 reg)
-{
- return of_get_child_by_name_reg(port, "endpoint", reg);
-}
-
-static struct device_node *
-of_graph_get_remote_port_parent(const struct device_node *node)
-{
- struct device_node *np;
- unsigned int depth;
-
- np = of_parse_phandle(node, "remote-endpoint", 0);
-
- /* Walk 3 levels up only if there is 'ports' node. */
- for (depth = 3; depth && np; depth--) {
- np = of_get_next_parent(np);
- if (depth == 2 && of_node_cmp(np->name, "ports"))
- break;
- }
- return np;
-}
-
-enum {
- FIMD_PORT_IN0,
- FIMD_PORT_IN1,
- FIMD_PORT_IN2,
- FIMD_PORT_RGB,
- FIMD_PORT_WRB,
-};
-
-static struct device_node *exynos_dpi_of_find_panel_node(struct device *dev)
-{
- struct device_node *np, *ep;
-
- np = of_graph_get_port_by_reg(dev->of_node, FIMD_PORT_RGB);
- if (!np)
- return NULL;
-
- ep = of_graph_get_endpoint_by_reg(np, 0);
- of_node_put(np);
- if (!ep)
- return NULL;
-
- np = of_graph_get_remote_port_parent(ep);
- of_node_put(ep);
-
- return np;
-}
-
static int exynos_dpi_parse_dt(struct exynos_dpi *ctx)
{
struct device *dev = ctx->dev;
struct device_node *dn = dev->of_node;
struct device_node *np;
- ctx->panel_node = exynos_dpi_of_find_panel_node(dev);
-
np = of_get_child_by_name(dn, "display-timings");
if (np) {
struct videomode *vm;
@@ -289,10 +209,21 @@ static int exynos_dpi_parse_dt(struct exynos_dpi *ctx)
return 0;
}
- if (!ctx->panel_node)
- return -EINVAL;
+ np = NULL;
+ while ((np = of_graph_get_next_endpoint(dev->of_node, np))) {
+ struct of_endpoint ep;
- return 0;
+ of_graph_parse_endpoint(np, &ep);
+ if (ep.port != FIMD_PORT_RGB)
+ continue;
+
+ ctx->panel_node = of_graph_get_remote_port_parent(np);
+ of_node_put(np);
+
+ return ctx->panel_node ? 0 : -EINVAL;
+ }
+
+ return -EINVAL;
}
struct exynos_drm_display *exynos_dpi_probe(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
[RFC 11/15] drm/exynos/dsi: convert to restrack API
Convert exynos_dsi driver to use restrack API.
As a result driver have following advantages:
- correctly handles removal of resources,
- do not need to defer probing, so as a result the whole drm system
initialization will not be postponed to late initcall, unless other
components delays it,
- simplified initialization.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 52 +
1 file changed, 21 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 8201d79..53ac467 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -23,7 +23,7 @@
#include
#include
#include
-
+#include
#include
#include
@@ -1690,9 +1690,18 @@ static const struct component_ops
exynos_dsi_component_ops = {
.unbind = exynos_dsi_unbind,
};
+void exynos_dsi_restrack_cb(struct device *dev, int ret)
+{
+ if (ret)
+ component_del(dev, &exynos_dsi_component_ops);
+ else
+ component_add(dev, &exynos_dsi_component_ops);
+}
+
static int exynos_dsi_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
+ struct restrack_ctx *rtrack;
struct resource *res;
struct exynos_dsi *dsi;
int ret;
@@ -1728,26 +1737,6 @@ static int exynos_dsi_probe(struct platform_device *pdev)
dsi->supplies[0].supply = "vddcore";
dsi->supplies[1].supply = "vddio";
- ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dsi->supplies),
- dsi->supplies);
- if (ret) {
- dev_info(dev, "failed to get regulators: %d\n", ret);
- return -EPROBE_DEFER;
- }
-
- dsi->pll_clk = devm_clk_get(dev, "pll_clk");
- if (IS_ERR(dsi->pll_clk)) {
- dev_info(dev, "failed to get dsi pll input clock\n");
- ret = PTR_ERR(dsi->pll_clk);
- goto err_del_component;
- }
-
- dsi->bus_clk = devm_clk_get(dev, "bus_clk");
- if (IS_ERR(dsi->bus_clk)) {
- dev_info(dev, "failed to get dsi bus clock\n");
- ret = PTR_ERR(dsi->bus_clk);
- goto err_del_component;
- }
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
dsi->reg_base = devm_ioremap_resource(dev, res);
@@ -1757,13 +1746,6 @@ static int exynos_dsi_probe(struct platform_device *pdev)
goto err_del_component;
}
- dsi->phy = devm_phy_get(dev, "dsim");
- if (IS_ERR(dsi->phy)) {
- dev_info(dev, "failed to get dsim phy\n");
- ret = PTR_ERR(dsi->phy);
- goto err_del_component;
- }
-
dsi->irq = platform_get_irq(pdev, 0);
if (dsi->irq < 0) {
dev_err(dev, "failed to request dsi irq resource\n");
@@ -1782,11 +1764,20 @@ static int exynos_dsi_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, &dsi->display);
- ret = component_add(dev, &exynos_dsi_component_ops);
+ rtrack = devm_restrack_register(dsi->dev, exynos_dsi_restrack_cb,
+ regulator_bulk_restrack_desc(&dsi->supplies[0]),
+ regulator_bulk_restrack_desc(&dsi->supplies[1]),
+ clk_restrack_desc(&dsi->pll_clk, "pll_clk"),
+ clk_restrack_desc(&dsi->bus_clk, "bus_clk"),
+ phy_restrack_desc(&dsi->phy, "dsim"),
+ );
+
+ ret = PTR_ERR_OR_ZERO(rtrack);
+
if (ret)
goto err_del_component;
- return ret;
+ return 0;
err_del_component:
exynos_drm_component_del(dev, EXYNOS_DEVICE_TYPE_CONNECTOR);
@@ -1795,7 +1786,6 @@ err_del_component:
static int exynos_dsi_remove(struct platform_device *pdev)
{
- component_del(&pdev->dev, &exynos_dsi_component_ops);
exynos_drm_component_del(&pdev->dev, EXYNOS_DEVICE_TYPE_CONNECTOR);
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
[RFC 00/15] Resource tracking/allocation framework
Hi,
Many kernel frameworks that uses provider/consumer schema suffer from
few issues:
1. They have broken driver unbinding handling. When device driver of the
provider
is unbound from the device, its consumers stay with reference to non-existing
objects, as a result we can observe oopses, crashes, hangs.
Frameworks tries to handle it by using:
- module refcounting (try_module_get/module_put) - as the name says it
protects only from module unloading, not driver unbinding. Additionally
it can cause circular dependencies of modules and inability to unload them.
- ghost providers - when driver is unbound provider is replaced with phony
one,
which returns errors on every access. It also does not solve the issue -
consumer device can hang if the hardware represented by the provider is off.
2. Consumer does not know when required resource becomes available. Currently it
is solved by deferred probing. The main problem with this solution is that it
delays deferred device probe to late_initcall, for some devices it is
unacceptable/undesirable.
3. There are drivers which can work without specific resource, but if
the resource becomes available/unavailable it can do some additional stuff.
An example of such driver is DRM driver (more precisely drm_connector) -
it can start without attached drm_panel, but if the panel becomes available it
can react by generating HPD event and start using it. Delaying drm
initialization due to lack of panel should be avoided - drm can still be
usable without it, for example it can still use HDMI monitor.
Currently it can be handled by periodic polling drm_panel framework for
the panel, but it is rather an workaround, not a real solution.
The main problem with the 1st issue is that drivers cannot be protected from
unbinding. So there is no way to prevent removal of resources they provide.
The only solution I see is to provide notifications to consumers about incoming
removal of resources they are using, so they can react appropriately.
Symmetrically we can add notifications about appearance of specific resources,
this way the 2nd issue can be solved.
And finally with both notifications we can solve the 3rd issue.
In the 1st patch I propose generic framework providing such notifications, named
track - propositions for better name are welcome.
Its main feature is that callbacks are serialized but are not called under lock,
it allows two important things:
- avoid additional locks in the consumers to protect data access from different
callbacks,
- call the framework from within the callback, so complex dependencies can be
modelled this way, without worries about deadlocks due to framework.
The 2nd patch contains restrack framework which uses internally track framework
to track and automatically allocate different resources. In short it can replace
all resource allocations with single call + callback. Of course it is just
a bonus. The most important thing is that it solves all described issues:
- it can properly handle provider unbind/re-bind,
- it avoids late init due to deferred probing,
- it allows to track optional resources.
Simple example taken from restrack commit message:
static int lcd_probe(...)
{
struct restrack *rtrack;
(...initialization w/o resource allocation ...)
rtrack = devm_restrack_register(dev, lcd_callback,
regulator_bulk_restrack_desc(&ctx->supplies[0]),
regulator_bulk_restrack_desc(&ctx->supplies[1]),
clk_restrack_desc(&ctx->pll_clk, "pll_clk"),
clk_restrack_desc(&ctx->bus_clk, "bus_clk"),
phy_restrack_desc(&ctx->phy, "dsim"),
);
return PTR_ERR_OR_NULL(rtrack);
}
void lcd_callback(struct device *dev, int ret)
{
struct lcd_ctx *ctx = dev_get_drvdata(dev);
if (ret == 0)
drm_panel_add(&ctx->panel);
else if (ret == -EPROBE_DEFER)
drm_panel_remove(&ctx->panel);
else
dev_err(dev, "restrack error %d\n", ret);
}
For other examples look at patches 11, 13, 15.
Patches 3,4,6,8,9 adds restrack support to various frameworks. Restrack support
is added only to resources exposed via Device Tree. Adding support for non-DT
resources should be also possible, but I guess it can be more complicated as
resource lookup mechanism is more fuzzy. Anyway I can work on it if necessary.
Moreover these patches in some cases adds redundant code for DT lookup,
this redundancy can be removed in final version of the patchset.
Also another frameworks may need similar patches.
Patch 11 converts exynos-dsi driver to restrack API. It solves issues of
provider unbind (1st issue) and late init due to deferred probing (2nd issue).
Patch 13 shows how to deal with optional resources (3rd issue).
Patch 15 is a simple example how to deal with resources depending on other
resources. In this particular case ld9040 lcd panel driver
Re: [PATCH v2 00/17] thermal: exynos: Thermal code rework to use device tree
Hi Eduardo, > On Wed, Dec 10, 2014 at 01:09:39PM +0100, Lukasz Majewski wrote: > > 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. > > > > Very good! Thanks for cleaning the code. > > Given the decision to be DT only, my only question now is if you need > to support non-DT booting systems. Do you (Exynos platforms in > general) care about booting without DT? As fair as I know all Exynos systems have been ported to DT. Support for new Exynos based devices is only accepted if configuration is DT based. > > If not, then removing makes completely sense to me. > > > > Around 400 lines of code (LOC) were removed directly by this patch, > > which is around 20% of the Exynos thermal code base. > > > > Great! > > > This work should NOT bring any functional changes to Exynos thermal > > subsystem. > > > > OK. > > > 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. > > > > uhh.. OK. but, by supporting of-thermal that means drivers should > never care about loading cpu cooling. That is done via cpufreq-dt. Up till now exynos has a Kbuild option to enable cpu_cooling for its thermal subsystem. cpufreq for Exynos also undergo major rework (done by Tomas Abraham): "cpufreq: use generic cpufreq drivers for exynos platforms" [1] It converts some Exynos 4 and 5 platform to use cpufreq-dt/cpufreq-bL and is pretty close to be added in this merge window. Unfortunately not all devices were converted (e.g. Exynos 4412) and old legacy cpufreq code is used (I simply wait with porting Exynos4412 for "base" patches landing in the kernel). Although, this shouldn't be a problem. > That is why we had the cycle with cpufreq folks, remember? > > (I will have a look in your patches) It would be great if those patches could find their way to therma -next. Then also Abhilash could benefit from them. > > > 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. > > This is very good. Do you care sending feedback if you need extra > configuration or does of-thermal cover your scenarios (a part from the > amendments you already did)? Changes, which I did recently to of-thermal.c are enough. > > I know people (tegra and rockchip) are interested in hw trip points, > which I believe should be of your interest too. Of course, that is > maybe an off-topic for this series. With this patch series I've tried to preserve previous functionality. I've got some ideas for improvements, but those are for other discussion. > > > > > > Patch series end with removing exynos5250/exynos3250 TMU > > compatibles. Both SoCs have thermal management unit (TMU) > > compatible with the one first introduced at Exynos4412. > > OK. I will have a look in DT changes you did. But in general, removing > support needs to be done carefully for backward compatibility :-(. Essentially this is a clean up, not removing support. The trick here is that Exynos4412 (which was added first to mainline), Exynos5250 and Exynos3250 use the same TMU IP block. > > > > > 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-rc1, > > 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. > > > Have you tried your series with cpufreq-dt? Since I don't know if [1] will be finally accepted - I've used already available cpufreq code (with exynos_defconfig + cpu_cooling enabled). I don't think that there should be any problem with using cpufreq-dt. Moreover, we would have enough time for potential fixes before next kernel (3.19) is released. > > > > > 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: c42c7a44c7a543dcb388c1ee1a798e6ed76ad8cf > > > > > > Lukasz Majewski (17): > > thermal: exynos: cosmetic: Correct comment format > > thermal: exynos: Provide thermal_exynos.h f
Re: [RFC PATCHv2 0/7] devfreq: Add devfreq-event class to provide raw data for devfreq device
Hi Krzysztof, On Wed, Dec 10, 2014 at 7:07 PM, Krzysztof Kozlowski wrote: > On wto, 2014-12-09 at 23:12 +0900, Chanwoo Choi wrote: >> This patchset add new devfreq_event class to provide raw data to determine >> current utilization of device which is used for devfreq governor. >> >> [Description of devfreq-event class] >> This patchset 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 >> >> Also, the devfreq-event device would support various type event as following: >> : DEVFREQ_EVENT_TYPE_RAW_DATA >> : DEVFREQ_EVENT_TYPE_UTILIZATION >> : DEVFREQ_EVENT_TYPE_BANDWIDTH >> : DEVFREQ_EVENT_TYPE_LATENCY >> >> [For example] >> If board dts includes PPMU_DMC0/DMC1/CPU event node, >> would show following sysfs entry. Also devfreq driver(e.g., exynos4_bus.c) >> can get the instance of devfreq-event device by using provided API and then >> get raw data which reflect the current state of device. >> > > Hi, > > Overall I like the idea. I understand that now devfreq devices (like > exynos devfreq) should bind themselves to buses, not to PPMU. It makes > sense to me because bus clock and bus voltage are properties of bus, not > monitoring unit. > > I see that this is still a RFC so it would be hard to base current > devfreq work on top of it. The goal of this patch set is not for devfreq device. This patch set just is used for devfreq-event device according to patch description. The devfreq must need devfreq-event device (e.g., exynos-ppmu.c) but current devfreq subsystem have not been supported any reason for exyons-ppmu.c as devfreq-event device. I discussed this same issue on following patch[1] which was posted to support exynos4 busfreq by me. [1] https://lkml.org/lkml/2014/3/14/132 - [PATCHv2 8/8] devfreq: exynos4: Add busfreq driver for exynos4210/exynos4x12 After discussion, I thought that devfreq-event class must be needed before supporting the dt of devfreq device. So, I think that devfreq have to support the devfreq-event subsystem for exynos-ppmu. And then I'll work to support the device-tree of devfreq device as next job. > > One more general comment: you're adding a some API which is not used by > current devfreq_event user (exynos). For example the exclusive flag or > event types. I think it will be simpler to stick to the basic approach > (reduced API). If some other user emerges then new API will be added. I think that devfreq-event must support both event_flag(e.g., exclusive flag) and event_type(e.g., raw_data, utilization, bandwidth, latency) because devfreq-event device (e.g., exynos-ppmu) would provide various event data. For example, exynos-ppmu driver could support the utilization/bandwidth/latency of each IP of Exynos SoC. I checked PPMU IP on Exynos TRM. Also, If specific devfreq-event device should be used on only one device driver, devfrewq-event class have to support 'exclusive' flag. If devfreq-event class don't support the exclusive flag, devfreq-event could not guarantee the integrity of event from devfreq-event device. Thanks for your comment. Best Regards, Chanwoo Choi -- To unsubscribe
Re: [PATCH v2 00/17] thermal: exynos: Thermal code rework to use device tree
On Wed, Dec 10, 2014 at 01:09:39PM +0100, Lukasz Majewski wrote: > 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. > Very good! Thanks for cleaning the code. Given the decision to be DT only, my only question now is if you need to support non-DT booting systems. Do you (Exynos platforms in general) care about booting without DT? If not, then removing makes completely sense to me. > Around 400 lines of code (LOC) were removed directly by this patch, which > is around 20% of the Exynos thermal code base. > Great! > This work should NOT bring any functional changes to Exynos thermal > subsystem. > OK. > 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. > uhh.. OK. but, by supporting of-thermal that means drivers should never care about loading cpu cooling. That is done via cpufreq-dt. That is why we had the cycle with cpufreq folks, remember? (I will have a look in your patches) > 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. This is very good. Do you care sending feedback if you need extra configuration or does of-thermal cover your scenarios (a part from the amendments you already did)? I know people (tegra and rockchip) are interested in hw trip points, which I believe should be of your interest too. Of course, that is maybe an off-topic for this series. > > Patch series end with removing exynos5250/exynos3250 TMU compatibles. > Both SoCs have thermal management unit (TMU) compatible with the one first > introduced at Exynos4412. OK. I will have a look in DT changes you did. But in general, removing support needs to be done carefully for backward compatibility :-(. > > 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-rc1, 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. Have you tried your series with cpufreq-dt? > > 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: c42c7a44c7a543dcb388c1ee1a798e6ed76ad8cf > > > Lukasz Majewski (17): > thermal: exynos: cosmetic: Correct comment format > thermal: exynos: Provide thermal_exynos.h file to be included in > device tree files > thermal: dts: trats: Enable TMU on the Exynos4210 trats device > thermal: dts: exynos: Add LD010 regulator node necessary for TMU on > Odroid > thermal: dts: Enable TMU at Exynos4412 based Odroid U3 device > thermal: cpu_cooling: dts: Define device tree bindings for Exynos cpu > cooling functionality > thermal: cpu_cooling: Modify exynos thermal code to use device tree > for cpu cooling configuration > thermal: exynos: dts: Add default definition of the TMU sensor > parameter > 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 > thermal: exynos: dts: Provide device tree bindings identical to 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: Make Exynos5250 TMU compatible with Exynos4412 > thermal: exynos: Make Exynos3250 TMU compatible with Exynos4412 > > arch/arm/boot/dts/exynos3250.dtsi | 6 +- > arch/arm/boot/dts/exynos4-cpu-thermal.dtsi| 52 +++ > arch/arm/boot/dts/exynos4.dtsi| 5 + > arch/arm/boot/dts/exynos4210-trats.dts| 19 + > arch/arm/boot/dts/exynos4210.dtsi | 43 ++- > arch/arm/boot/dts/exynos4212.dtsi | 20 + > arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 27 ++ > arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi | 24 ++ > arch/arm/boot/dts/exynos44
[PATCH v2 17/17] thermal: exynos: Make Exynos3250 TMU compatible with Exynos4412
Both SoCs have the same TMU IP block embedded on them. Necessary differences
are specified via device tree.
Therefore there is no need to maintain a separate compatible entry.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- Update DTS TMU entry for Exynos3250 to be compatible with Exynos4412
---
arch/arm/boot/dts/exynos3250.dtsi| 2 +-
drivers/thermal/samsung/exynos_tmu.c | 3 ---
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 6edfa76..306d988 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -185,7 +185,7 @@
};
tmu: tmu@100C {
- compatible = "samsung,exynos3250-tmu";
+ compatible = "samsung,exynos4412-tmu";
reg = <0x100C 0x100>;
interrupts = <0 216 0>;
clocks = <&cmu CLK_TMU_APBIF>;
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 05441fc..86728c5 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -759,9 +759,6 @@ static irqreturn_t exynos_tmu_irq(int irq, void *id)
static const struct of_device_id exynos_tmu_match[] = {
{
- .compatible = "samsung,exynos3250-tmu",
- },
- {
.compatible = "samsung,exynos4210-tmu",
},
{
--
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 v2 16/17] thermal: exynos: Make Exynos5250 TMU compatible with Exynos4412
Both SoCs have the same TMU IP block embedded on them. Necessary differences
are specified via device tree.
Therefore there is no need to maintain a separate compatible entry.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- None
---
arch/arm/boot/dts/exynos5250.dtsi| 2 +-
drivers/thermal/samsung/exynos_tmu.c | 3 ---
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 2167394..7cb1a5b 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -238,7 +238,7 @@
};
tmu: tmu@1006 {
- compatible = "samsung,exynos5250-tmu";
+ compatible = "samsung,exynos4412-tmu";
reg = <0x1006 0x100>;
interrupts = <0 65 0>;
clocks = <&clock CLK_TMU>;
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index dfbf9bd..05441fc 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -768,9 +768,6 @@ static const struct of_device_id exynos_tmu_match[] = {
.compatible = "samsung,exynos4412-tmu",
},
{
- .compatible = "samsung,exynos5250-tmu",
- },
- {
.compatible = "samsung,exynos5260-tmu",
},
{
--
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 v2 14/17] 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
---
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,
- unsigned long *temp)
-{
- struct exynos_thermal_zone *th_zo
[PATCH v2 13/17] 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
---
drivers/thermal/samsung/Makefile | 2 -
drivers/thermal/samsung/exynos_tmu.c | 320 ++-
drivers/thermal/samsung/exynos_tmu.h | 51 --
3 files changed, 200 insertions(+), 173 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 d2d6b53..dfbf9bd 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 &= ~(0xff << 8 * i);
@@ -305,9 +349,19 @@ static void exynos_tmu_control(struct platform_device
*pdev, bool on)
static int exynos4210_tmu_initialize(struct platform_device *pdev)
{
struct exynos_tmu_data *data = platform_get_drvdata(pdev);
- struct exynos_tmu_platform_da
[PATCH v2 15/17] 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
---
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_ARCH_EXYNOS4412,
- },
- },
- .tmu_count = 1,
-
[PATCH v2 12/17] thermal: exynos: dts: Provide device tree bindings identical to 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
---
arch/arm/boot/dts/exynos3250.dtsi | 4
arch/arm/boot/dts/exynos4.dtsi| 5 +
arch/arm/boot/dts/exynos4210.dtsi | 23 ++-
arch/arm/boot/dts/exynos4x12.dtsi | 3 +++
arch/arm/boot/dts/exynos5250.dtsi | 7 +--
arch/arm/boot/dts/exynos5420.dtsi | 33 +
arch/arm/boot/dts/exynos5440.dtsi | 18 ++
7 files changed, 90 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 693a327..6edfa76 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -18,7 +18,9 @@
*/
#include "skeleton.dtsi"
+#include "exynos4-cpu-thermal.dtsi"
#include
+#include
/ {
compatible = "samsung,exynos3250";
@@ -188,6 +190,8 @@
interrupts = <0 216 0>;
clocks = <&cmu CLK_TMU_APBIF>;
clock-names = "tmu_apbif";
+ type = ;
+ #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 e0278ec..1735bb3 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -21,6 +21,7 @@
#include
#include
+#include
#include "skeleton.dtsi"
/ {
@@ -645,4 +646,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 10e8915..1c52681 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -21,6 +21,8 @@
#include "exynos4.dtsi"
#include "exynos4210-pinctrl.dtsi"
+#include "exynos4-cpu-thermal.dtsi"
+#include
/ {
compatible = "samsung,exynos4210", "samsung,exynos4";
@@ -146,16 +148,35 @@
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";
+ gain = <15>;
+ reference_voltage = <7>;
+ type = ;
status = "disabled";
};
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ 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 2e9f1f7..ee24d83 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -19,6 +19,8 @@
#include "exynos4.dtsi"
#include "exynos4x12-pinctrl.dtsi"
+#include "exynos4-cpu-thermal.dtsi"
+#include
/ {
aliases {
@@ -279,6 +281,7 @@
reg = <0x100C 0x100>;
clocks = <&clock 383>;
clock-names = "tmu_apbif";
+ type = ;
status = "disabled";
};
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index a5bbc1a..2167394 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -20,8 +20,9 @@
#include
#include "exynos5.dtsi"
#include "exynos5250-pinctrl.dtsi"
-
+#include "exynos4-cpu-thermal.dtsi"
#include
+#include
/ {
compatible = "samsung,exynos5250", "samsung,exynos5";
@@ -236,12 +237,14 @@
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";
+ type = ;
+ #incl
[PATCH v2 10/17] 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
---
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 v2 11/17] 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
---
arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi | 25 +++
arch/arm/boot/dts/exynos5440-trip-points.dtsi | 25 +++
2 files changed, 50 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..336cb12
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi
@@ -0,0 +1,25 @@
+/*
+ * 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>;
+gain = <5>;
+reference_voltage = <16>;
+noise_cancel_mode = <4>;
+efuse_value = <0x5d2d>;
+min_efuse_value = <16>;
+max_efuse_value = <76>;
+first_point_trim = <25>;
+second_point_trim = <70>;
+default_temp_offset = <25>;
+cal_type = ;
+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 v2 07/17] thermal: cpu_cooling: 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
---
drivers/cpufreq/exynos-cpufreq.c| 23 -
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, 94 insertions(+), 105 deletions(-)
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index 1e0ec57..fdedb8d 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 *np;
int ret = -EINVAL;
exynos_info = kzalloc(sizeof(*exynos_info), GFP_KERNEL);
@@ -198,9 +202,24 @@ 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;
+ np = of_find_node_by_path("/cpus/cpu@0");
+ if (!np) {
+ pr_err("failed to find cpu0 node\n");
+ return -ENOENT;
+ }
+ 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));
+ }
+ of_node_put(np);
+
+ 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_child_by_name(np, "cooling-maps");
- /* Bind the thermal zone to the cpufreq cooling device */
- for (i = 0; i < tab_size; i++) {
- clip_data = (struct freq_clip_table *)&(tab_ptr[i]);
- level = cpufreq_cooling_get_level(0, clip_data->freq_clip_max);
- if (level == THERMAL_CSTATE_INVALID)
- return 0;
- switch (GET_ZONE(i)) {
- case MONITOR_ZONE:
- case WARN_ZONE:
- if (thermal_zone_bind_cooling_device(thermal, i, cdev,
- leve
[PATCH v2 09/17] 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
---
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 v2 08/17] 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 --- 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..ee6d8bb --- /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>; +gain = <8>; +reference_voltage = <16>; +noise_cancel_mode = <4>; +efuse_value = <55>; +min_efuse_value = <40>; +max_efuse_value = <100>; +first_point_trim = <25>; +second_point_trim = <85>; +default_temp_offset = <50>; +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 v2 06/17] thermal: cpu_cooling: dts: Define device tree bindings for Exynos cpu cooling functionality
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
---
arch/arm/boot/dts/exynos4210-trats.dts | 15
arch/arm/boot/dts/exynos4210.dtsi | 20
arch/arm/boot/dts/exynos4212.dtsi | 20
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 15
arch/arm/boot/dts/exynos4412-trats2.dts | 15
arch/arm/boot/dts/exynos4412.dtsi | 32 +
arch/arm/boot/dts/exynos5250.dtsi | 20 +++-
7 files changed, 136 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/arch/arm/boot/dts/exynos4210-trats.dts
index b59019c..d9dd9a7 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 807bb5b..10e8915 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -41,6 +41,26 @@
#clock-cells = <1>;
};
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ 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@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <0x901>;
+ };
+ };
+
sysram@0202 {
compatible = "mmio-sram";
reg = <0x0202 0x2>;
diff --git a/arch/arm/boot/dts/exynos4212.dtsi
b/arch/arm/boot/dts/exynos4212.dtsi
index 3c00e6e..6405954 100644
--- a/arch/arm/boot/dts/exynos4212.dtsi
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -22,6 +22,26 @@
/ {
compatible = "samsung,exynos4212", "samsung,exynos4";
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ 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@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <0xA01>;
+ };
+ };
+
combiner: interrupt-controller@1044 {
samsung,combiner-nr = <18>;
};
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index eb1c08c..15d45f0 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -375,6 +375,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 121430d..396c525 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -786,4 +786,19 @@
pulldown-o
[PATCH v2 05/17] thermal: dts: 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
---
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 9366f5a..eb1c08c 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -370,6 +370,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 v2 04/17] thermal: dts: exynos: Add LD010 regulator node necessary for TMU on Odroid
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- 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 c697ff0..9366f5a 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -205,6 +205,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 v2 03/17] thermal: 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
---
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 f516da9..b59019c 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 v2 02/17] 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
---
drivers/thermal/samsung/exynos_tmu.c | 2 +-
drivers/thermal/samsung/exynos_tmu.h | 24 +++---
include/dt-bindings/thermal/thermal_exynos.h | 37
3 files changed, 42 insertions(+), 21 deletions(-)
create mode 100644 include/dt-bindings/thermal/thermal_exynos.h
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 32ac366..936d16f 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -144,7 +144,7 @@ struct exynos_tmu_data {
void __iomem *base;
void __iomem *base_second;
int irq;
- enum soc_type soc;
+ int soc;
struct work_struct irq_work;
struct mutex lock;
struct clk *clk, *clk_sec;
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index da3009b..03ebdd0 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -26,24 +26,7 @@
#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,
- SOC_ARCH_EXYNOS4412,
- SOC_ARCH_EXYNOS5250,
- SOC_ARCH_EXYNOS5260,
- SOC_ARCH_EXYNOS5420,
- SOC_ARCH_EXYNOS5420_TRIMINFO,
- SOC_ARCH_EXYNOS5440,
-};
+#include
/**
* struct exynos_tmu_platform_data
@@ -115,8 +98,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;
+ u32 type;
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..85789be
--- /dev/null
+++ b/include/dt-bindings/thermal/thermal_exynos.h
@@ -0,0 +1,37 @@
+/*
+ * 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
+
+#define SOC_ARCH_EXYNOS3250 1
+#define SOC_ARCH_EXYNOS4210 2
+#define SOC_ARCH_EXYNOS4412 3
+#define SOC_ARCH_EXYNOS5250 4
+#define SOC_ARCH_EXYNOS5260 5
+#define SOC_ARCH_EXYNOS5420_TRIMINFO 6
+#define SOC_ARCH_EXYNOS5420 7
+#define SOC_ARCH_EXYNOS5440 8
+
+#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 v2 00/17] 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. Patch series end with removing exynos5250/exynos3250 TMU compatibles. Both SoCs have thermal management unit (TMU) compatible with the one first introduced at Exynos4412. 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-rc1, 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: c42c7a44c7a543dcb388c1ee1a798e6ed76ad8cf Lukasz Majewski (17): thermal: exynos: cosmetic: Correct comment format thermal: exynos: Provide thermal_exynos.h file to be included in device tree files thermal: dts: trats: Enable TMU on the Exynos4210 trats device thermal: dts: exynos: Add LD010 regulator node necessary for TMU on Odroid thermal: dts: Enable TMU at Exynos4412 based Odroid U3 device thermal: cpu_cooling: dts: Define device tree bindings for Exynos cpu cooling functionality thermal: cpu_cooling: Modify exynos thermal code to use device tree for cpu cooling configuration thermal: exynos: dts: Add default definition of the TMU sensor parameter 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 thermal: exynos: dts: Provide device tree bindings identical to 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: Make Exynos5250 TMU compatible with Exynos4412 thermal: exynos: Make Exynos3250 TMU compatible with Exynos4412 arch/arm/boot/dts/exynos3250.dtsi | 6 +- arch/arm/boot/dts/exynos4-cpu-thermal.dtsi| 52 +++ arch/arm/boot/dts/exynos4.dtsi| 5 + arch/arm/boot/dts/exynos4210-trats.dts| 19 + arch/arm/boot/dts/exynos4210.dtsi | 43 ++- arch/arm/boot/dts/exynos4212.dtsi | 20 + 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 | 32 ++ arch/arm/boot/dts/exynos4x12.dtsi | 3 + arch/arm/boot/dts/exynos5250.dtsi | 29 +- arch/arm/boot/dts/exynos5420-trip-points.dtsi | 35 ++ arch/arm/boot/dts/exynos5420.dtsi | 33 ++ arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi | 25 ++ arch/arm/boot/dts/exynos5440-trip-points.dtsi | 25 ++ arch/arm/boot/dts/exynos5440.dtsi | 18 + drivers/cpufreq/exynos-cpufreq.c | 23 +- 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 | 337 ++--- drivers/thermal/samsung/exynos_tmu.h | 80 +--- drivers/thermal/samsung/exynos_tmu_data.c | 264 - include/dt-bindings/thermal/thermal_exynos.h | 37 ++ 25 files changed, 669 insertions(+), 1018 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
[PATCH v2 01/17] thermal: exynos: cosmetic: Correct comment format
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- 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 8d7395c..32ac366 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
Re: [RFC PATCHv2 0/7] devfreq: Add devfreq-event class to provide raw data for devfreq device
On wto, 2014-12-09 at 23:12 +0900, Chanwoo Choi wrote: > This patchset add new devfreq_event class to provide raw data to determine > current utilization of device which is used for devfreq governor. > > [Description of devfreq-event class] > This patchset 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 > > Also, the devfreq-event device would support various type event as following: > : DEVFREQ_EVENT_TYPE_RAW_DATA > : DEVFREQ_EVENT_TYPE_UTILIZATION > : DEVFREQ_EVENT_TYPE_BANDWIDTH > : DEVFREQ_EVENT_TYPE_LATENCY > > [For example] > If board dts includes PPMU_DMC0/DMC1/CPU event node, > would show following sysfs entry. Also devfreq driver(e.g., exynos4_bus.c) > can get the instance of devfreq-event device by using provided API and then > get raw data which reflect the current state of device. > Hi, Overall I like the idea. I understand that now devfreq devices (like exynos devfreq) should bind themselves to buses, not to PPMU. It makes sense to me because bus clock and bus voltage are properties of bus, not monitoring unit. I see that this is still a RFC so it would be hard to base current devfreq work on top of it. One more general comment: you're adding a some API which is not used by current devfreq_event user (exynos). For example the exclusive flag or event types. I think it will be simpler to stick to the basic approach (reduced API). If some other user emerges then new API will be added. Best regards, Krzysztof > -sh-3.2# pwd > /sys/class/devfreq_event > -sh-3.2# ls -al > total 0 > drwxr-xr-x 2 root root 0 Jan 7 11:10 . > drwxr-xr-x 37 root root 0 Jan 7 11:10 .. > lrwxrwxrwx 1 root root 0 Jan 7 11:10 event.0 -> > ../../devices/soc/106a.ppmu_dmc0/devfreq_event/event.0 > lrwxrwxrwx 1 root root 0 Jan 7 11:10 event.1 -> > ../../devices/soc/106a.ppmu_dmc0/devfreq_event/event.1 > lrwxrwxrwx 1 root root 0 Jan 7 11:10 event.2 -> > ../../devices/soc/106a.ppmu_dmc0/devfreq_event/event.2 > lrwxrwxrwx 1 root root 0 Jan 7 11:10 event.3 -> > ../../devices/soc/106a.ppmu_dmc0/devfreq_event/event.3 > lrwxrwxrwx 1 root root 0 Jan 7 11:10 event.4 -> > ../../devices/soc/106b.ppmu_dmc1/devfreq_event/event.4 > lrwxrwxrwx 1 root root 0 Jan 7 11:10 event.5 -> > ../../devices/soc/106c.ppmu_cpu/devfreq_event/event.5 > lrwxrwxrwx 1 root root 0 Jan 7 11:10 event.6 -> > ../../devices/soc/106c.ppmu_cpu/devfreq_event/event.6 > lrwxrwxrwx 1 root root 0 Jan 7 11:10 event.7 -> > ../../devices/soc/106c.ppmu_cpu/devfreq_event/event.7 > lrwxrwxrwx 1 root root 0 Jan 7 11:10 event.8 -> > ../../devices/soc/106c.ppmu_cpu/devfreq_event/event.8 > > Changes from v1: > - Code clean > - Add the description of devfreq-event structure > - Add 'is_enabled' function to devfreq_event_ops structure > - Add 'enable_count' field to devfreq_event_dev structure > - Check whether devfreq-event device is enabled or not > during calling devfreq_event API > - Define the type of devfreq-event device as following > : DEVFREQ_EVENT_TYPE_RAW_DATA > : DEVFREQ_EVENT_TYPE_UTILIZATION > : DEVFREQ_EVENT_TYPE_BANDWIDTH > : DEVFRE
Re: [RFC PATCHv2 4/7] devfreq: event: Add exynos-ppmu devfreq event driver
On wto, 2014-12-09 at 23:13 +0900, Chanwoo Choi wrote:
> This patch add exynos-ppmu devfreq event driver to provider raw data about
> the utilization of each IP in Exynos SoC series.
>
> Cc: MyungJoo Ham
> Cc: Kyungmin Park
> Signed-off-by: Chanwoo Choi
> ---
> drivers/devfreq/Kconfig | 9 +
> drivers/devfreq/event/Makefile | 1 +
> drivers/devfreq/event/exynos-ppmu.c | 409
>
> 3 files changed, 419 insertions(+)
> create mode 100644 drivers/devfreq/event/exynos-ppmu.c
I would rather see this as an incremental change for existing
exynos_ppmu.c file. However I do not insists on that.
>
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index 4d15b62..d4559f7 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -89,4 +89,13 @@ config ARM_EXYNOS5_BUS_DEVFREQ
>
> comment "DEVFREQ Event Drivers"
>
> +config DEVFREQ_EVENT_EXYNOS_PPMU
> + bool "EXYNOS PPMU (Performance Profiling 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
> + (Performance Profiling Monitoring Unit) counters to estimate the
> + utilization of each module.
> +
> endif # PM_DEVFREQ
> 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..2706f23
> --- /dev/null
> +++ b/drivers/devfreq/event/exynos-ppmu.c
> @@ -0,0 +1,409 @@
> +/*
> + * exynos_ppmu.c - EXYNOS PPMU (Performance Profiling Monitoring Units)
> 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
> +
> +#define PPMU_ENABLE BIT(0)
> +#define PPMU_DISABLE0x0
> +#define PPMU_CYCLE_RESETBIT(1)
> +#define PPMU_COUNTER_RESET BIT(2)
> +
> +#define PPMU_ENABLE_COUNT0 BIT(0)
> +#define PPMU_ENABLE_COUNT1 BIT(1)
> +#define PPMU_ENABLE_COUNT2 BIT(2)
> +#define PPMU_ENABLE_COUNT3 BIT(3)
> +#define PPMU_ENABLE_CYCLE BIT(31)
> +
> +#define PPMU_CNTENS 0x10
> +#define PPMU_FLAG0x50
> +#define PPMU_CCNT_OVERFLOW BIT(31)
> +#define PPMU_CCNT0x100
> +
> +#define PPMU_PMCNT0 0x110
> +#define PPMU_PMCNT_OFFSET0x10
> +#define PMCNT_OFFSET(x) (PPMU_PMCNT0 + (PPMU_PMCNT_OFFSET * x))
> +
> +#define PPMU_BEVT0SEL0x1000
> +#define PPMU_BEVTSEL_OFFSET 0x100
> +#define PPMU_BEVTSEL(x) (PPMU_BEVT0SEL + (x *
> PPMU_BEVTSEL_OFFSET))
> +
> +#define RD_DATA_COUNT0x5
> +#define WR_DATA_COUNT0x6
> +#define RDWR_DATA_COUNT 0x7
> +
> +enum ppmu_counter {
> + PPMU_PMNCNT0,
> + PPMU_PMNCNT1,
> + PPMU_PMNCNT2,
> + PPMU_PMNCNT3,
> + PPMU_PMNCNT_MAX,
> +};
> +
> +/* Platform data */
> +struct exynos_ppmu_data {
> + struct devfreq *devfreq;
Looks like not used here.
> + struct devfreq_event_dev **event_dev;
> + struct devfreq_event_desc *desc;
> + unsigned int num_events;
> +
> + struct device *dev;
> + struct clk *clk_ppmu;
> + struct mutex lock;
> +
> + struct __exynos_ppmu {
> + void __iomem *hw_base;
> + unsigned int ccnt;
> + unsigned int event[PPMU_PMNCNT_MAX];
> + unsigned int count[PPMU_PMNCNT_MAX];
> + unsigned long long ns;
> + ktime_t reset_time;
> + bool ccnt_overflow;
> + bool count_overflow[PPMU_PMNCNT_MAX];
> + } ppmu;
> +};
> +
> +struct __exynos_ppmu_events {
> + char *name;
> + int id;
> +} ppmu_events[] = {
> + { "ppmu-dmc0-pmcnt0", PPMU_PMNCNT0 },
> + { "ppmu-dmc0-pmcnt1", PPMU_PMNCNT1 },
> + { "ppmu-dmc0-pmcnt2", PPMU_PMNCNT2 },
> + { "ppmu-dmc0-pmcnt3", PPMU_PMNCNT3 },
> +
> + { "ppmu-dmc1-pmcnt0", PPMU_PMNCNT0 },
> + { "ppmu-dmc1-pmcnt1", PPMU_PMNCNT1 },
> + { "ppmu-dmc1-pmcnt2", PPMU_PMNCNT2 },
> + { "ppmu-dmc1-pmcnt3", PPMU_PMNCNT3 },
> +
> + { "ppmu-cpu-pmcnt0", PPMU_PMNCNT0 },
> + { "ppmu-cpu-pmcnt1", PPMU_PMNCNT1 },
> + { "ppmu-cpu-pmcnt2", PPMU_PMNCNT2 },
> + { "ppmu-cpu-pmcnt3", PPMU_PMNCNT3 },
> +
> + { "ppmu-rightbus-pmcnt0"
Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like)
Hello,
On 2014-12-09 17:57, Nishanth Menon wrote:
On 10:13-20141205, Nishanth Menon wrote:
On 12/05/2014 10:10 AM, Nishanth Menon wrote:
next-20141204 fails to boot, but next-20141203 boots fine with
omap2plus_defconfig.
Panda-ES(4460):
https://github.com/nmenon/kernel-test-logs/blob/next-20141204/omap2plus_defconfig/pandaboard-es.txt
Panda(4430):
https://github.com/nmenon/kernel-test-logs/blob/next-20141204/omap2plus_defconfig/pandaboard-vanilla.txt
at the point of hang (JTAG):
pandaboard-es:
cpu0: http://slexy.org/view/s2eIFqkRd5
cpu1: http://slexy.org/view/s2Tysb6gpL
Case #1:
Disabling CPUIDLE allows boot to proceed. there does not seem to have
been any change in drivers/cpuidle and arch/arm/mach-omap2 w.r.t this.
Case #2: Reverting the following allows boot.
From next-20141204
10df7d5 ARM: 8211/1: l2c: Add support for overriding prefetch settings
revert this -> boot still fails
d42ced0 ARM: 8210/1: l2c: Get outer cache .write_sec callback from
mach_desc only if not NULL
revert this -> boot still fails
46b9af8 ARM: 8209/1: l2c: Add interface to ask hypervisor to configure L2C
revert this -> boot still fails
c94e325 ARM: 8208/1: l2c: Refactor the driver to use commit-like
revert this -> boot passed (first bad commit).
+ linux-samsung soc and updated Thomaz's mail ID (gmail now).
Spend a few mins trying to track this down and it does look like commit
c94e325 does a kmemdup for the data as part of l2x0_of_init->__l2c_init
This fails since the invocation is in early_init. doing it a bit later
as the following hack makes it work
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 608079a..0bc6bd9 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -170,12 +170,19 @@ static const char *const omap4_boards_compat[]
__initconst = {
NULL,
};
+
+static void tmp_init_irq(void)
+{
+ omap_l2_cache_init();
+ omap_gic_of_init();
+}
+
DT_MACHINE_START(OMAP4_DT, "Generic OMAP4 (Flattened Device Tree)")
.reserve= omap_reserve,
.smp= smp_ops(omap4_smp_ops),
.map_io = omap4_map_io,
.init_early = omap4430_init_early,
- .init_irq = omap_gic_of_init,
+ .init_irq = tmp_init_irq,
.init_machine = omap_generic_init,
.init_late = omap4430_init_late,
.init_time = omap4_local_timer_init,
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 03cbb16..f97847d 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -627,7 +627,6 @@ void __init omap4430_init_early(void)
omap44xx_clockdomains_init();
omap44xx_hwmod_init();
omap_hwmod_init_postsetup();
- omap_l2_cache_init();
omap_clk_soc_init = omap4xxx_dt_clk_init;
}
Please note that am43xx_init_early() also calls omap_l2_cache_init(),
so similar fix is needed for "Generic AM43 (Flattened Device Tree)"
machines.
I've briefly looked how the initialization is done on various omap
platforms, but I don't see the good generic place for omap_l2_cache_init().
IMHO the best solution will be to completely switch to generic/common l2c
initialization and provide ".l2c_aux_val" and ".l2c_aux_mask" in machine
descriptor. For the time being something like proposed above can be used.
I assume that now it won't be possible to get l2c patches back to -next,
so I will resend them (again...) with the omap related fix.
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index e5948c5..0ca90db 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -848,8 +848,11 @@ static int __init __l2c_init(const struct l2c_init_data
*data,
* context from callers can access the structure.
*/
l2x0_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
- if (!l2x0_data)
+ if (!l2x0_data) {
+ pr_err("%s no mem %d\n", __func__, sizeof(*data));
+ dump_stack();
return -ENOMEM;
+ }
/*
* Sanity check the aux values. aux_mask is the bits we preserve
@@ -1647,6 +1650,7 @@ int __init l2x0_of_init(u32 aux_val, u32 aux_mask)
struct device_node *np;
struct resource res;
u32 cache_id, old_aux;
+ int r;
np = of_find_matching_node(NULL, l2x0_ids);
if (!np)
@@ -1693,6 +1697,8 @@ int __init l2x0_of_init(u32 aux_val, u32 aux_mask)
else
cache_id = readl_relaxed(l2x0_base + L2X0_CACHE_ID);
- return __l2c_init(data, aux_val, aux_mask, cache_id);
+ r = __l2c_init(data, aux_val, aux_mask, cache_id);
+ pr_err("%s: %d\n", __func__, r);
+ return r;
}
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 ht
Re: [RFC PATCHv2 1/7] devfreq: event: Add new devfreq_event class to provide basic data for devfreq governor
On wto, 2014-12-09 at 23:13 +0900, Chanwoo Choi wrote: > This patch add new devfreq_event class for devfreq_event device which provide > raw data (e.g., memory bus utilization/GPU utilization). This raw data from > devfreq_event data would be used for the governor of devfreq subsystem. > - devfreq_event device : Provide raw data for governor of existing devfreq > device > - devfreq device : Monitor device state and change frequency/voltage of > device > using the raw data from devfreq_event device > > The devfreq subsystem support generic DVFS(Dynamic Voltage/Frequency Scaling) > for Non-CPU Devices. The devfreq device would dertermine current device state > using various governor (e.g., ondemand, performance, powersave). After > completed > determination of system state, devfreq device would change the > frequency/voltage > of devfreq device according to the result of governor. > > But, devfreq governor must need basic data which indicates current device > state. > Existing devfreq subsystem only consider devfreq device which check current > system > state and determine proper system state using basic data. There is no > subsystem > for device providing basic data to devfreq device. > > The devfreq subsystem must need devfreq_event device(data-provider device) for > existing devfreq device. So, this patch add new devfreq_event class for > devfreq_event device which read various basic data(e.g, memory bus > utilization, > GPU utilization) and provide measured data to existing devfreq device through > standard APIs of devfreq_event class. > > The following description explains the feature of two kind of devfreq class: > - devfreq class (existing) > : devfreq consumer device use raw data from devfreq_event device for >determining proper current system state and change voltage/frequency >dynamically using various governors. > > - devfreq_event class (new) > : Provide measured raw data to devfreq device for governor > > Cc: MyungJoo Ham > Cc: Kyungmin Park > Signed-off-by: Chanwoo Choi > --- > drivers/devfreq/Kconfig | 2 + > drivers/devfreq/Makefile| 5 +- > drivers/devfreq/devfreq-event.c | 302 > > drivers/devfreq/event/Makefile | 1 + > include/linux/devfreq.h | 141 +++ > 5 files changed, 450 insertions(+), 1 deletion(-) > create mode 100644 drivers/devfreq/devfreq-event.c > create mode 100644 drivers/devfreq/event/Makefile > > diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig > index faf4e70..4d15b62 100644 > --- a/drivers/devfreq/Kconfig > +++ b/drivers/devfreq/Kconfig > @@ -87,4 +87,6 @@ config ARM_EXYNOS5_BUS_DEVFREQ > It reads PPMU counters of memory controllers and adjusts the > operating frequencies and voltages with OPP support. > > +comment "DEVFREQ Event Drivers" > + > endif # PM_DEVFREQ > diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile > index 16138c9..a1ffabe 100644 > --- a/drivers/devfreq/Makefile > +++ b/drivers/devfreq/Makefile > @@ -1,4 +1,4 @@ > -obj-$(CONFIG_PM_DEVFREQ) += devfreq.o > +obj-$(CONFIG_PM_DEVFREQ) += devfreq.o devfreq-event.o > obj-$(CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND)+= governor_simpleondemand.o > obj-$(CONFIG_DEVFREQ_GOV_PERFORMANCE)+= governor_performance.o > obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE) += governor_powersave.o > @@ -7,3 +7,6 @@ obj-$(CONFIG_DEVFREQ_GOV_USERSPACE) += governor_userspace.o > # DEVFREQ Drivers > obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ)+= exynos/ > obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ)+= exynos/ > + > +# DEVFREQ Event Drivers > +obj-$(CONFIG_PM_DEVFREQ) += event/ > diff --git a/drivers/devfreq/devfreq-event.c b/drivers/devfreq/devfreq-event.c > new file mode 100644 > index 000..b47329f > --- /dev/null > +++ b/drivers/devfreq/devfreq-event.c > @@ -0,0 +1,302 @@ > +/* > + * devfreq-event: Generic DEVFREQ Event class driver > + * > + * Copyright (C) 2014 Samsung Electronics > + * Chanwoo Choi > + * > + * 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 > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include "governor.h" > + > +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) > + > +struct devfreq_event_dev *devfreq_add_event_device(struct device *dev, > + struct devfreq_e
[PATCH 1/2] Documentation: dt-bindings: Add aliases information for Exynos7 pin controllers
Adding list of aliases for supported Exynos7 pin controller blocks.
Signed-off-by: Vivek Gautam
Cc: Tomasz Figa
Cc: Linus Walleij
---
.../devicetree/bindings/pinctrl/samsung-pinctrl.txt | 10 ++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
index 8425838..742e472 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
@@ -171,6 +171,16 @@ Aliases:
All the pin controller nodes should be represented in the aliases node using
the following format 'pinctrl{n}' where n is a unique number for the alias.
+Aliases for controllers compatible with "samsung,exynos7-pinctrl":
+- pinctrl0: pin controller of ALIVE block,
+- pinctrl1: pin controller of BUS0 block,
+- pinctrl2: pin controller of NFC block,
+- pinctrl3: pin controller of TOUCH block,
+- pinctrl4: pin controller of FF block,
+- pinctrl5: pin controller of ESE block,
+- pinctrl6: pin controller of FSYS0 block,
+- pinctrl7: pin controller of FSYS1 block,
+
Example: A pin-controller node with pin banks:
pinctrl_0: pinctrl@1140 {
--
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
[PATCH V3 2/2] pinctrl: exynos: Add BUS1 pin controller for exynos7
USB and Power regulator on Exynos7 require gpios available
in BUS1 pin controller block.
So adding the BUS1 pinctrl support.
Signed-off-by: Naveen Krishna Ch
Signed-off-by: Vivek Gautam
Cc: Tomasz Figa
Cc: Linus Walleij
---
Changes since V2:
- Added documentation on alias for BUS1 pin controller block.
Changes since V1:
- Added support for all pin banks which are part of BUS1 pin controller.
.../devicetree/bindings/pinctrl/samsung-pinctrl.txt |1 +
drivers/pinctrl/samsung/pinctrl-exynos.c| 19 +++
2 files changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
index 742e472..c88ba35 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
@@ -180,6 +180,7 @@ Aliases for controllers compatible with
"samsung,exynos7-pinctrl":
- pinctrl5: pin controller of ESE block,
- pinctrl6: pin controller of FSYS0 block,
- pinctrl7: pin controller of FSYS1 block,
+- pinctrl8: pin controller of BUS1 block,
Example: A pin-controller node with pin banks:
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index d5d4cfc..44e60dc 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -1300,6 +1300,20 @@ static const struct samsung_pin_bank_data
exynos7_pin_banks7[] __initconst = {
EXYNOS_PIN_BANK_EINTG(8, 0x060, "gpr3", 0x0c),
};
+/* pin banks of exynos7 pin-controller - BUS1 */
+static const struct samsung_pin_bank_data exynos7_pin_banks8[] __initconst = {
+ EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpf0", 0x00),
+ EXYNOS_PIN_BANK_EINTG(8, 0x040, "gpf1", 0x04),
+ EXYNOS_PIN_BANK_EINTG(4, 0x060, "gpf2", 0x08),
+ EXYNOS_PIN_BANK_EINTG(5, 0x080, "gpf3", 0x0c),
+ EXYNOS_PIN_BANK_EINTG(8, 0x0a0, "gpf4", 0x10),
+ EXYNOS_PIN_BANK_EINTG(8, 0x0c0, "gpf5", 0x14),
+ EXYNOS_PIN_BANK_EINTG(5, 0x0e0, "gpg1", 0x18),
+ EXYNOS_PIN_BANK_EINTG(5, 0x100, "gpg2", 0x1c),
+ EXYNOS_PIN_BANK_EINTG(6, 0x120, "gph1", 0x20),
+ EXYNOS_PIN_BANK_EINTG(3, 0x140, "gpv6", 0x24),
+};
+
const struct samsung_pin_ctrl exynos7_pin_ctrl[] __initconst = {
{
/* pin-controller instance 0 Alive data */
@@ -1342,5 +1356,10 @@ const struct samsung_pin_ctrl exynos7_pin_ctrl[]
__initconst = {
.pin_banks = exynos7_pin_banks7,
.nr_banks = ARRAY_SIZE(exynos7_pin_banks7),
.eint_gpio_init = exynos_eint_gpio_init,
+ }, {
+ /* pin-controller instance 8 BUS1 data */
+ .pin_banks = exynos7_pin_banks8,
+ .nr_banks = ARRAY_SIZE(exynos7_pin_banks8),
+ .eint_gpio_init = exynos_eint_gpio_init,
},
};
--
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: [PATCH V2 1/2] pinctrl: exynos: Add BUS1 pin controller for exynos7
Hi Tomasz, On Mon, Dec 1, 2014 at 9:37 PM, Tomasz Figa wrote: > Hi Vivek, > > Please see my comments below. > > 2014-11-24 22:02 GMT+09:00 Vivek Gautam : >> USB and Power regulator on Exynos7 require gpios available >> in BUS1 pin controller block. >> So adding the BUS1 pinctrl support. >> >> Signed-off-by: Naveen Krishna Ch >> Signed-off-by: Vivek Gautam >> Cc: Linus Walleij >> --- >> >> This patch was part of series: >> "[PATCH 00/11] Exynos7: Adding USB 3.0 support" >> https://lkml.org/lkml/2014/11/21/247 >> >> Changes since V1: >> - Added support for all pin banks which are part of BUS1 pin controller. >> >> drivers/pinctrl/samsung/pinctrl-exynos.c | 19 +++ >> 1 file changed, 19 insertions(+) > > I have missed this with previous patch, but DT bindings documentation > should list all aliases for all supported compatible strings, because > they are required for correct operation. There is a small section > about aliases in [1] already, so please add there information about > aliases for Exynos7 pin controllers along with their names, e.g. > > Aliases for controllers compatible with "samsung,exynos7-pinctrl": > - pinctrl0: pin controller of ALIVE block, > - pinctrl1: pin controller of BUS0 block, > [...] > - pinctrl8: pin controller of BUS1 block. > > [1] Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt > > I guess you can do this in separate patch or respin this one with this added. Sure, i will add the aliases in a separate patch. I missed to update the patch in this cycle :-( So we can queue up the reworked version for 3.20. -- Best Regards Vivek Gautam Samsung R&D Institute, Bangalore India -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
