linaro-kernel

linaro-kernel@lists.linaro.org

10095 discussions

[PATCH] mmc: sdhci-s3c: Check if clk_set_rate() succeeds

by Mark Brown

From: Mark Brown <broonie(a)linaro.org> It is possible that we may fail to set the clock rate, if we do so then log the failure and don't bother reprogramming the IP. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- drivers/mmc/host/sdhci-s3c.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c index 926aaf6..d10de3f 100644 --- a/drivers/mmc/host/sdhci-s3c.c +++ b/drivers/mmc/host/sdhci-s3c.c @@ -295,6 +295,7 @@ static void sdhci_cmu_set_clock(struct sdhci_host *host, unsigned int clock) struct device *dev = &ourhost->pdev->dev; unsigned long timeout; u16 clk = 0; + int ret; /* don't bother if the clock is going off */ if (clock == 0) @@ -302,7 +303,12 @@ static void sdhci_cmu_set_clock(struct sdhci_host *host, unsigned int clock) sdhci_s3c_set_clock(host, clock); - clk_set_rate(ourhost->clk_bus[ourhost->cur_clk], clock); + ret = clk_set_rate(ourhost->clk_bus[ourhost->cur_clk], clock); + if (ret != 0) { + dev_err(dev, "%s: failed to set clock rate %uHz\n", + mmc_hostname(host->mmc), clock); + return; + } host->clock = clock; -- 1.8.4.rc3

12 years

[PATCH] video: exynos: Ensure definitions match prototypes

by Mark Brown

From: Mark Brown <broonie(a)linaro.org> Ensure that the definitions of functions match the prototypes used by other modules by including the header with the prototypes in the files with the definitions. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- drivers/video/exynos/exynos_mipi_dsi_lowlevel.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/video/exynos/exynos_mipi_dsi_lowlevel.c b/drivers/video/exynos/exynos_mipi_dsi_lowlevel.c index 15c5abd..c148d06 100644 --- a/drivers/video/exynos/exynos_mipi_dsi_lowlevel.c +++ b/drivers/video/exynos/exynos_mipi_dsi_lowlevel.c @@ -27,6 +27,7 @@ #include <video/exynos_mipi_dsim.h> #include "exynos_mipi_dsi_regs.h" +#include "exynos_mipi_dsi_lowlevel.h" void exynos_mipi_dsi_func_reset(struct mipi_dsim_device *dsim) { -- 1.8.3.1

12 years

Re: [PATCH 02/10] cpufreq: OMAP: Add SMP support for OMAP4+

by Viresh Kumar

On 30 August 2013 11:13, Viresh Kumar <viresh.kumar(a)linaro.org> wrote: > > On 29 August 2013 19:12, Santosh Shilimkar <santosh.shilimkar(a)ti.com> wrote: > > On Thursday 29 August 2013 09:39 AM, Viresh Kumar wrote: > >> On 29 August 2013 19:07, Santosh Shilimkar <santosh.shilimkar(a)ti.com> wrote: > >>> On Thursday 29 August 2013 06:02 AM, Viresh Kumar wrote: > >> > >>>> cpumask_setall(policy->cpus); > >>>> > >>> Thats should work I guess. Infact I changed this i downstream kernel > >>> a while back but forgot to send a patch. Just see if for some reason > >>> above can break UP machine since this driver is used on UP machines > >>> as well. Other than that, it should be fine > >> > >> Atleast I can't see why it will break on UP machines as that should set > >> masks to individual CPUs then... > >> > >> Okay I will fix that in my longest patchset ever... 230+ patches already :) > >> > > WoW !! > > Looks like you re-wrote most of the CPUFREQ drivers ;-) > > I am trying hard to get rid of redundancy of code wherever possible .. :) > > I am pasting my patch here for now (don't want to post > this separately) as most of the concerned people are following this chain.. > > I will include it in my patchset and will post it on lists with them (After > your Ack, which you will give now :) ) > > --------x-----------------x-------------- OMG, Gmail fucked up completely... What to do now :) Earlier (few days back): - We could have selected the plain text mode while sending emails, where emails are corrupted a bit and so patches couldn't be applied. - BUT they are atleast readable as it wasn't fucked up so badly.. But today I noticed that gmail has completely removed tabs from mails (Atleast while pasting code). And so all tabs used for alignments in mail are gone.. And so aren't even readable anymore.. Deselecting plain text mode, sends it in HTML and that's fucked up too.. Mails gets bounced from our lists (and even then gmail has eaten up the tabs from code)... For now see the attached patch, I will send it using git later.. Btw, this is the link to master patch that you may need during reviews.. https://lkml.org/lkml/2013/8/21/485 > From: Viresh Kumar <viresh.kumar(a)linaro.org> > Date: Wed, 21 Aug 2013 19:05:05 +0530 > Subject: [PATCH] cpufreq: omap: use cpufreq_generic_init() routine > > Use generic cpufreq_generic_init() routine instead of replicating the same code > here. > > This also rearranges the code a bit to make it more sensible. Also removes some > unnecessary checks. > > Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> > --- > drivers/cpufreq/omap-cpufreq.c | 41 +++++++++++------------------------------ > 1 file changed, 11 insertions(+), 30 deletions(-) > > diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c > index 09150fc..a94c4ef 100644 > --- a/drivers/cpufreq/omap-cpufreq.c > +++ b/drivers/cpufreq/omap-cpufreq.c > @@ -112,50 +112,31 @@ static inline void freq_table_free(void) > > static int omap_cpu_init(struct cpufreq_policy *policy) > { > - int result = 0; > + int result; > > policy->clk = clk_get(NULL, "cpufreq_ck"); > if (IS_ERR(policy->clk)) > return PTR_ERR(policy->clk); > > - if (policy->cpu >= NR_CPUS) { > - result = -EINVAL; > - goto fail_ck; > - } > - > - if (!freq_table) > + if (!freq_table) { > result = opp_init_cpufreq_table(mpu_dev, &freq_table); > - > - if (result) { > - dev_err(mpu_dev, "%s: cpu%d: failed creating freq table[%d]\n", > + if (result) { > + dev_err(mpu_dev, > + "%s: cpu%d: failed creating freq table[%d]\n", > __func__, policy->cpu, result); > - goto fail_ck; > + goto fail; > + } > } > > atomic_inc_return(&freq_table_users); > > - result = cpufreq_table_validate_and_show(policy, freq_table); > - if (result) > - goto fail_table; > - > - /* > - * On OMAP SMP configuartion, both processors share the voltage > - * and clock. So both CPUs needs to be scaled together and hence > - * needs software co-ordination. Use cpufreq affected_cpus > - * interface to handle this scenario. Additional is_smp() check > - * is to keep SMP_ON_UP build working. > - */ > - if (is_smp()) > - cpumask_setall(policy->cpus); > - > /* FIXME: what's the actual transition time? */ > - policy->cpuinfo.transition_latency = 300 * 1000; > - > - return 0; > + result = cpufreq_generic_init(policy, freq_table, 300 * 1000); > + if (!result) > + return 0; > > -fail_table: > freq_table_free(); > -fail_ck: > +fail: > clk_put(policy->clk); > return result; > } >

12 years

[PATCH] clk: wm831x: Provide is_prepared() rather than is_enabled()

by Mark Brown

From: Mark Brown <broonie(a)linaro.org> Since the driver was written an is_prepared() operation has been made possible. Since the driver uses I2C I/O only prepare operations are provided so move the is_enabled() operation over to is_prepared(). Signed-off-by: Mark Brown <broonie(a)linaro.org> --- drivers/clk/clk-wm831x.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/clk/clk-wm831x.c b/drivers/clk/clk-wm831x.c index 1d5af3f..805b4c3 100644 --- a/drivers/clk/clk-wm831x.c +++ b/drivers/clk/clk-wm831x.c @@ -31,7 +31,7 @@ struct wm831x_clk { bool xtal_ena; }; -static int wm831x_xtal_is_enabled(struct clk_hw *hw) +static int wm831x_xtal_is_prepared(struct clk_hw *hw) { struct wm831x_clk *clkdata = container_of(hw, struct wm831x_clk, xtal_hw); @@ -52,7 +52,7 @@ static unsigned long wm831x_xtal_recalc_rate(struct clk_hw *hw, } static const struct clk_ops wm831x_xtal_ops = { - .is_enabled = wm831x_xtal_is_enabled, + .is_prepared = wm831x_xtal_is_prepared, .recalc_rate = wm831x_xtal_recalc_rate, }; @@ -73,7 +73,7 @@ static const unsigned long wm831x_fll_auto_rates[] = { 24576000, }; -static int wm831x_fll_is_enabled(struct clk_hw *hw) +static int wm831x_fll_is_prepared(struct clk_hw *hw) { struct wm831x_clk *clkdata = container_of(hw, struct wm831x_clk, fll_hw); @@ -170,7 +170,7 @@ static int wm831x_fll_set_rate(struct clk_hw *hw, unsigned long rate, if (i == ARRAY_SIZE(wm831x_fll_auto_rates)) return -EINVAL; - if (wm831x_fll_is_enabled(hw)) + if (wm831x_fll_is_prepared(hw)) return -EPERM; return wm831x_set_bits(wm831x, WM831X_CLOCK_CONTROL_2, @@ -220,7 +220,7 @@ static u8 wm831x_fll_get_parent(struct clk_hw *hw) } static const struct clk_ops wm831x_fll_ops = { - .is_enabled = wm831x_fll_is_enabled, + .is_prepared = wm831x_fll_is_prepared, .prepare = wm831x_fll_prepare, .unprepare = wm831x_fll_unprepare, .round_rate = wm831x_fll_round_rate, @@ -237,7 +237,7 @@ static struct clk_init_data wm831x_fll_init = { .flags = CLK_SET_RATE_GATE, }; -static int wm831x_clkout_is_enabled(struct clk_hw *hw) +static int wm831x_clkout_is_prepared(struct clk_hw *hw) { struct wm831x_clk *clkdata = container_of(hw, struct wm831x_clk, clkout_hw); @@ -335,7 +335,7 @@ static int wm831x_clkout_set_parent(struct clk_hw *hw, u8 parent) } static const struct clk_ops wm831x_clkout_ops = { - .is_enabled = wm831x_clkout_is_enabled, + .is_prepared = wm831x_clkout_is_prepared, .prepare = wm831x_clkout_prepare, .unprepare = wm831x_clkout_unprepare, .get_parent = wm831x_clkout_get_parent, -- 1.8.4.rc3

12 years

perf: callchain feature on ARM - question about libunwind API

by Jean Pihet

Hi! I am looking for info and help on the libunwind API. What I am trying to achieve is to allow the callchain feature on perf for ARM (v7 to start with, then ARMv8), from the DWARF info found in the .debug_frame section. >From the source code in tools/perf I have added the call to dwarf_find_debug_frame to load and parse the debug info from .debug_frame. This works correctly, all IP ranges are found from the debug code (test program and libraries). Then at some point I get an assertion: 'perf: dwarf/Gparser.c:459: fetch_proc_info: Assertion `c->pi.unwind_info' failed.' At that point c->pi is NULL. Cf. below for more info. It looks like I am not using the libunwind API as it should, so that the perf code apparently builds a list of IP ranges to resolve but cannot use it later on to gather statistics on the runtime info. Any idea on how to progress? I am also looking at the *_proc_info API of libunwind. Here is the patch I am using below. Cheers, Jean --- Debug log: perf report --sort symbol --call-graph --stdio _Uarm_step: calling dwarf_step(ip=0x8464, c->dwarf@0xbee150f8, c->dwarf.pi@0xb2bc0008) unwind: find_proc_info dso /home/linaro/perf-libunwind/ test_app/stress_bt read_unwind_spec_debug_frame: .debug_frame offset=9304 opened file '/home/linaro/perf-libunwind/test_app/stress_bt'. Section header at offset 18152 read 3160 bytes of .debug_frame from offset 9304 ... _ULarm_step: calling dwarf_step(ip=0xb6e6e764, c->dwarf@0xbee07508, c->dwarf.pi@0xb6e955c0) _ULarm_find_proc_info: looking for IP=0xb6e6e763 opened file '/usr/lib/arm-linux-gnueabihf/libunwind.so.8'. Section header at offset 513260 read 17072 bytes of .debug_frame from offset 451836 _ULarm_dwarf_search_unwind_table: looking for IP=0xb6e6e763 _ULarm_find_proc_info returns 0 ... perf: dwarf/Gparser.c:459: fetch_proc_info: Assertion `c->pi.unwind_info' failed. --- Patch to the kernel source: diff --git a/tools/perf/util/unwind.c b/tools/perf/util/unwind.c index 958723b..dd97688 100644 --- a/tools/perf/util/unwind.c +++ b/tools/perf/util/unwind.c @@ -39,6 +39,14 @@ UNW_OBJ(dwarf_search_unwind_table) (unw_addr_space_t as, #define dwarf_search_unwind_table UNW_OBJ(dwarf_search_unwind_table) +extern int +UNW_OBJ(dwarf_find_debug_frame) (int found, unw_dyn_info_t *di_debug, + unw_word_t ip, unw_word_t segbase, + const char* obj_name, unw_word_t start, + unw_word_t end); + +#define dwarf_find_debug_frame UNW_OBJ(dwarf_find_debug_frame) + #define DW_EH_PE_FORMAT_MASK 0x0f /* format of the encoded value */ #define DW_EH_PE_APPL_MASK 0x70 /* how the value is to be applied */ @@ -245,8 +253,9 @@ static int unwind_spec_ehframe(struct dso *dso, struct machine *machine, return 0; } -static int read_unwind_spec(struct dso *dso, struct machine *machine, - u64 *table_data, u64 *segbase, u64 *fde_count) +static int read_unwind_spec_eh_frame(struct dso *dso, struct machine *machine, + u64 *table_data, u64 *segbase, + u64 *fde_count) { int ret = -EINVAL, fd; u64 offset; @@ -255,18 +264,40 @@ static int read_unwind_spec(struct dso *dso, struct machine *machine, if (fd < 0) return -EINVAL; + /* Check the .eh_frame section for unwinding info */ offset = elf_section_offset(fd, ".eh_frame_hdr"); close(fd); - if (offset) + if (offset) { + fprintf(stderr, "%s: .eh_frame offset=%llu\n", __func__, offset); ret = unwind_spec_ehframe(dso, machine, offset, table_data, segbase, fde_count); + } - /* TODO .debug_frame check if eh_frame_hdr fails */ return ret; } +static int read_unwind_spec_debug_frame(struct dso *dso, + struct machine *machine, + u64 *segbase) +{ + int fd = dso__data_fd(dso, machine); + if (fd < 0) + return -EINVAL; + + /* Check the .debug_frame section for unwinding info */ + *segbase = elf_section_offset(fd, ".debug_frame"); + close(fd); + + fprintf(stderr, "%s: .debug_frame offset=%llu\n", __func__, *segbase); + + if (!segbase) + return -EINVAL; + + return 0; +} + static struct map *find_map(unw_word_t ip, struct unwind_info *ui) { struct addr_location al; @@ -289,22 +320,32 @@ find_proc_info(unw_addr_space_t as, unw_word_t ip, unw_proc_info_t *pi, if (!map || !map->dso) return -EINVAL; - pr_debug("unwind: find_proc_info dso %s\n", map->dso->name); + fprintf(stderr, "unwind: find_proc_info dso %s\n", map->dso->name); + + /* Check the .eh_frame section for unwinding info */ + if (!read_unwind_spec_eh_frame(map->dso, ui->machine, + &table_data, &segbase, &fde_count)) { + memset(&di, 0, sizeof(di)); + di.format = UNW_INFO_FORMAT_REMOTE_TABLE; + di.start_ip = map->start; + di.end_ip = map->end; + di.u.rti.segbase = map->start + segbase; + di.u.rti.table_data = map->start + table_data; + di.u.rti.table_len = fde_count * sizeof(struct table_entry) + / sizeof(unw_word_t); + return dwarf_search_unwind_table(as, ip, &di, pi, + need_unwind_info, arg); + } - if (read_unwind_spec(map->dso, ui->machine, - &table_data, &segbase, &fde_count)) - return -EINVAL; + /* Check the .debug_frame section for unwinding info */ + if (!read_unwind_spec_debug_frame(map->dso, ui->machine, &segbase)) { + memset(&di, 0, sizeof(di)); + if (dwarf_find_debug_frame(0, &di, ip, segbase, map->dso->name, + map->start, map->end)) + return 0; + } - memset(&di, 0, sizeof(di)); - di.format = UNW_INFO_FORMAT_REMOTE_TABLE; - di.start_ip = map->start; - di.end_ip = map->end; - di.u.rti.segbase = map->start + segbase; - di.u.rti.table_data = map->start + table_data; - di.u.rti.table_len = fde_count * sizeof(struct table_entry) - / sizeof(unw_word_t); - return dwarf_search_unwind_table(as, ip, &di, pi, - need_unwind_info, arg); + return -EINVAL; } static int access_fpreg(unw_addr_space_t __maybe_unused as,

12 years

[PATCH 00/16] cpufreq: create & use cpufreq_generic_get() routine

by Viresh Kumar

CPUFreq drivers that use clock frameworks interface,i.e. clk_get_rate(), to get CPUs clk rate, has similar sort of code used for most of them. This patchset adds a generic ->get() which will do the same thing for them. All those drivers are required to now is to set .get to cpufreq_generic_get() and set their clk pointer in policy->clk during ->init(). Later part of this patchset fixes 17 drivers with this change. That's part 7 of my generic cleanups for CPUFreq core, first six are here: 1: cpufreq: Introduce cpufreq_table_validate_and_show() https://lkml.org/lkml/2013/8/8/263 2: cpufreq: define generic routines for cpufreq drivers https://lkml.org/lkml/2013/8/10/48 3. CPUFreq: Implement light weight ->target(): for 3.13 https://lkml.org/lkml/2013/8/13/349 4. CPUFreq: set policy->cur in cpufreq core instead of drivers https://lkml.org/lkml/2013/8/14/288 5. CPUFreq: Move freq change notifications out of drivers https://lkml.org/lkml/2013/8/15/506 6. cpufreq: create & use cpufreq_generic_init() routine http://lkml.org/lkml/2013/8/21/352 All these are pushed here: https://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/… Viresh Kumar (16): cpufreq: create cpufreq_generic_get() routine cpufreq: arm_big_little: use cpufreq_generic_get() routine cpufreq: at32ap: use cpufreq_generic_get() routine cpufreq: cpu0: use cpufreq_generic_get() routine cpufreq: davinci: use cpufreq_generic_get() routine cpufreq: dbx500: use cpufreq_generic_get() routine cpufreq: exynos: use cpufreq_generic_get() routine cpufreq: imx6q: use cpufreq_generic_get() routine cpufreq: loongson2: use cpufreq_generic_get() routine cpufreq: omap: use cpufreq_generic_get() routine cpufreq: ppc: use cpufreq_generic_get() routine cpufreq: s3c: use cpufreq_generic_get() routine cpufreq: s5pv210: use cpufreq_generic_get() routine cpufreq: spear: use cpufreq_generic_get() routine cpufreq: tegra: use cpufreq_generic_get() routine cpufreq: unicore2: use cpufreq_generic_get() routine drivers/cpufreq/arm_big_little.c | 10 ++-------- drivers/cpufreq/at32ap-cpufreq.c | 17 +++++------------ drivers/cpufreq/cpufreq-cpu0.c | 8 ++------ drivers/cpufreq/cpufreq.c | 26 ++++++++++++++++++++------ drivers/cpufreq/davinci-cpufreq.c | 13 +++---------- drivers/cpufreq/dbx500-cpufreq.c | 19 ++----------------- drivers/cpufreq/exynos-cpufreq.c | 10 +++------- drivers/cpufreq/exynos5440-cpufreq.c | 33 ++++++++++++++------------------- drivers/cpufreq/imx6q-cpufreq.c | 8 ++------ drivers/cpufreq/loongson2_cpufreq.c | 15 +++++---------- drivers/cpufreq/omap-cpufreq.c | 32 ++++++++++---------------------- drivers/cpufreq/ppc-corenet-cpufreq.c | 17 ++++------------- drivers/cpufreq/s3c24xx-cpufreq.c | 10 +++------- drivers/cpufreq/s3c64xx-cpufreq.c | 33 ++++++++++++--------------------- drivers/cpufreq/s5pv210-cpufreq.c | 21 ++++++--------------- drivers/cpufreq/spear-cpufreq.c | 8 ++------ drivers/cpufreq/tegra-cpufreq.c | 16 +++------------- drivers/cpufreq/unicore2-cpufreq.c | 21 ++++++++------------- include/linux/cpufreq.h | 3 +++ 19 files changed, 109 insertions(+), 211 deletions(-) -- 1.7.12.rc2.18.g61b472e

12 years

[RESEND RFC 0/2] ARM: mm: HugeTLB + THP support for non-LPAE

by Steve Capper

Hello, I'm resending this series to try and provoke some discussion. -- The following patches bring both HugeTLB support and Transparent HugePage (THP) support to ARM for 2 levels of paging (i.e. without LPAE). This code has been tested on an Arndale board (Exynos 5250), and is based on 3.11-rc1, with the hugepage simplification patch: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/184117.html HugeTLB and THP support for LPAE has already been merged in 3.11-rc1. Hugepages can give nice performance boosts to workloads that put pressure on the TLBs. I've observed uplifts of ~5% to some tasks just by enabling hugepages via the libhugetlbfs tools. Other people have observed decent performance boosts when huge pages are enabled: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-February/148835.… I would appreciate any discussion on these patches, as there are people who have an interest in having huge page support in non-LPAE kernels. Cheers, -- Steve Steve Capper (2): ARM: mm: HugeTLB support for non-LPAE systems. ARM: mm: Transparent huge page support for non-LPAE systems. arch/arm/Kconfig | 4 +- arch/arm/include/asm/hugetlb-2level.h | 126 +++++++++++++++++++++++++ arch/arm/include/asm/hugetlb.h | 4 + arch/arm/include/asm/pgtable-2level.h | 170 ++++++++++++++++++++++++++++++++++ arch/arm/include/asm/pgtable-3level.h | 6 ++ arch/arm/include/asm/pgtable.h | 7 +- arch/arm/include/asm/tlb.h | 10 +- arch/arm/kernel/head.S | 10 +- arch/arm/mm/fault.c | 13 --- arch/arm/mm/fsr-2level.c | 4 +- arch/arm/mm/hugetlbpage.c | 2 +- arch/arm/mm/mmu.c | 27 ++++++ 12 files changed, 360 insertions(+), 23 deletions(-) create mode 100644 arch/arm/include/asm/hugetlb-2level.h -- 1.8.1.4

12 years

[PATCH v8 0/2] Introduce buffer synchronization framework

by Inki Dae

Hi all, This patch set introduces a buffer synchronization framework based on DMA BUF[1] and based on ww-mutexes[2] for lock mechanism, and has been rebased on linux-next. The purpose of this framework is to provide not only buffer access control to CPU and CPU, and CPU and DMA, and DMA and DMA but also easy-to-use interfaces for device drivers and user application. In addtion, this patch set suggests a way for enhancing performance. Changelog v8: Consider the write-and-then-read ordering pointed out by David Herrmann, - The ordering issue means that a task don't take a lock to the dmabuf so this task would be stalled even though this task requested a lock to the dmabuf between other task unlocked and tries to lock the dmabuf again. For this, we have added a wait event mechanism using only generic APIs, wait_event_timeout and wake_up functions. The below is how to handle the ordering issue using this mechanism: 1. Check if there is a sync object added prior to current task's one. 2. If exists, it unlocks the dmabuf so that other task can take a lock to the dmabuf first. 3. Wait for the wake up event from other task: current task will be waked up when other task unlocks the dmabuf. 4. Take a lock to the dmabuf again. - Code cleanups. Changelog v7: Fix things pointed out by Konrad Rzeszutek Wilk, - Use EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL. - Make sure to unlock and unreference all dmabuf objects when dmabuf_sync_fini() is called. - Add more comments. - Code cleanups. Changelog v6: - Fix sync lock to multiple reads. - Add select system call support. . Wake up poll_wait when a dmabuf is unlocked. - Remove unnecessary the use of mutex lock. - Add private backend ops callbacks. . This ops has one callback for device drivers to clean up their sync object resource when the sync object is freed. For this, device drivers should implement the free callback properly. - Update document file. Changelog v5: - Rmove a dependence on reservation_object: the reservation_object is used to hook up to ttm and dma-buf for easy sharing of reservations across devices. However, the dmabuf sync can be used for all dma devices; v4l2 and drm based drivers, so doesn't need the reservation_object anymore. With regared to this, it adds 'void *sync' to dma_buf structure. - All patches are rebased on mainline, Linux v3.10. Changelog v4: - Add user side interface for buffer synchronization mechanism and update descriptions related to the user side interface. Changelog v3: - remove cache operation relevant codes and update document file. Changelog v2: - use atomic_add_unless to avoid potential bug. - add a macro for checking valid access type. - code clean. For generic user mode interface, we have used fcntl and select system call[3]. As you know, user application sees a buffer object as a dma-buf file descriptor. So fcntl() call with the file descriptor means to lock some buffer region being managed by the dma-buf object. And select() call means to wait for the completion of CPU or DMA access to the dma-buf without locking. For more detail, you can refer to the dma-buf-sync.txt in Documentation/ There are some cases user-space process needs this buffer synchronization framework. One of which is to primarily enhance GPU rendering performance in case that 3D app draws somthing in a buffer using CPU, and other process composes the buffer with its own backbuffer using GPU. In case of 3D app, the app calls glFlush to submit 3d commands to GPU driver instead of glFinish for more performance. The reason, we call glFlush, is that glFinish blocks caller's task until the execution of the 3d commands is completed. So that makes GPU and CPU more idle. As a result, 3d rendering performance with glFinish is quite lower than glFlush. However, the use of glFlush has one issue that the the buffer shared with GPU could be broken when CPU accesses the buffer just after glFlush because CPU cannot be aware of the completion of GPU access to the buffer. Of course, the app can be aware of that time using eglWaitGL but this function is valid only in case of the same context. The below summarizes how app's window is displayed on Tizen[4] platform: 1. X client requests a window buffer to Xorg. 2. X client draws something in the window buffer using CPU. 3. X client requests SWAP to Xorg. 4. Xorg notifies a damage event to Composite Manager. 5. Composite Manager gets the window buffer (front buffer) through DRI2GetBuffers. 6. Composite Manager composes the window buffer and its own back buffer using GPU. At this time, eglSwapBuffers is called: internally, 3d commands are flushed to gpu driver. 7. Composite Manager requests SWAP to Xorg. 8. Xorg performs drm page flip. At this time, the window buffer is displayed on screen. Web app based on HTML5 also has the same issue. Web browser and Web app are different process. The Web app can draw something in its own buffer using CPU, and then the Web Browser can compose the buffer with its own back buffer. Thus, in such cases, a shared buffer could be broken as one process draws something in a buffer using CPU, when other process composes the buffer with its own buffer using GPU without any locking mechanism. That is why we need user land locking interface, fcntl system call. And last one is a deferred page flip issue. This issue is that a window buffer rendered can be displayed on screen in about 32ms in worst case: assume that the gpu rendering is completed within 16ms. That can be incurred when compositing a pixmap buffer with a window buffer using GPU and when vsync is just started. At this time, Xorg waits for a vblank event to get a window buffer so 3d rendering will be delayed up to about 16ms. As a result, the window buffer would be displayed in about two vsyncs (about 32ms) and in turn, that would show slow responsiveness. For this, we could enhance the responsiveness with locking mechanism: skipping one vblank wait. I guess Android, Chrome OS, and other platforms are using their own locking mechanisms with similar reason; Android sync driver, KDS, and DMA fence. The below shows the deferred page flip issue in worst case: |------------ <- vsync signal |<------ DRI2GetBuffers | | | |------------ <- vsync signal |<------ Request gpu rendering time | | |<------ Request page flip (deferred) |------------ <- vsync signal |<------ Displayed on screen | | | |------------ <- vsync signal Thanks, Inki Dae References: [1] http://lwn.net/Articles/470339/ [2] https://patchwork.kernel.org/patch/2625361/ [3] http://linux.die.net/man/2/fcntl [4] https://www.tizen.org/ Inki Dae (2): dmabuf-sync: Add a buffer synchronization framework dma-buf: Add user interfaces for dmabuf sync support Documentation/dma-buf-sync.txt | 286 ++++++++++++ drivers/base/Kconfig | 7 + drivers/base/Makefile | 1 + drivers/base/dma-buf.c | 85 ++++ drivers/base/dmabuf-sync.c | 943 ++++++++++++++++++++++++++++++++++++++++ include/linux/dma-buf.h | 16 + include/linux/dmabuf-sync.h | 257 +++++++++++ 7 files changed, 1595 insertions(+), 0 deletions(-) create mode 100644 Documentation/dma-buf-sync.txt create mode 100644 drivers/base/dmabuf-sync.c create mode 100644 include/linux/dmabuf-sync.h -- 1.7.5.4

12 years

[PATCH 0/2] Add GPLL, APLL, KPLL, EPLL and VPLL freq table for exynos5420 and exynos5250

by Vikas Sajjan

Adds GPLL, APLL, KPLL, EPLL and VPLL freq table for exynos5420 and exynos5250. is rebased on Mike's https://git.linaro.org/gitweb?p=people/mturquette/linux.git;a=shortlog;h=re… Vikas Sajjan (2): clk: samsung: Add GPLL freq table for exynos5250 SoC clk: samsung: Add APLL, KPLL, EPLL and VPLL freq table for exynos5420 SoC drivers/clk/samsung/clk-exynos5250.c | 19 +++++++- drivers/clk/samsung/clk-exynos5420.c | 81 ++++++++++++++++++++++++++++++++++ 2 files changed, 99 insertions(+), 1 deletion(-) -- 1.7.9.5

12 years

panda rcu stall on 3.10.1

by Christian Hoffmann

Hi, current linaro kernel on 13.07 (3.10.1.0-1-linaro-omap) shows stack below. Full dmesg here: https://dl.dropboxusercontent.com/u/21820416/rcu.stall.panda Rgds, Chris [ 4538.880432] INFO: rcu_sched detected stalls on CPUs/tasks: { 1} (detected by 0, t=2103 jiffies, g=1649, c=1648, q=18) [ 4538.891723] Backtrace for cpu 0 (current): [ 4538.891723] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.1.0-1-linaro-omap #1ubuntu1~ci+130723003933-Ubuntu [ 4538.891754] [<c001175d>] (unwind_backtrace+0x1/0x9c) from [<c000f625>] (show_stack+0x11/0x14) [ 4538.891815] [<c000f625>] (show_stack+0x11/0x14) from [<c00106d5>] (smp_send_all_cpu_backtrace+0x49/0x98) [ 4538.891815] [<c00106d5>] (smp_send_all_cpu_backtrace+0x49/0x98) from [<c007c755>] (rcu_check_callbacks+0x439/0x4ac) [ 4538.891815] [<c007c755>] (rcu_check_callbacks+0x439/0x4ac) from [<c0036599>] (update_process_times+0x2d/0x4c) [ 4538.891876] [<c0036599>] (update_process_times+0x2d/0x4c) from [<c005fcfd>] (tick_sched_handle+0x35/0x40) [ 4538.891906] [<c005fcfd>] (tick_sched_handle+0x35/0x40) from [<c005feed>] (tick_sched_timer+0x31/0x54) [ 4538.891937] [<c005feed>] (tick_sched_timer+0x31/0x54) from [<c004532b>] (__run_hrtimer+0x5b/0x138) [ 4538.891937] [<c004532b>] (__run_hrtimer+0x5b/0x138) from [<c0045bcb>] (hrtimer_interrupt+0xdb/0x22c) [ 4538.891967] [<c0045bcb>] (hrtimer_interrupt+0xdb/0x22c) from [<c0010e13>] (twd_handler+0x1b/0x28) [ 4538.891998] [<c0010e13>] (twd_handler+0x1b/0x28) from [<c00783b9>] (handle_percpu_devid_irq+0x4d/0xac) [ 4538.891998] [<c00783b9>] (handle_percpu_devid_irq+0x4d/0xac) from [<c0075ead>] (generic_handle_irq+0x19/0x24) [ 4538.892028] [<c0075ead>] (generic_handle_irq+0x19/0x24) from [<c000d16d>] (handle_IRQ+0x29/0x68) [ 4538.892059] [<c000d16d>] (handle_IRQ+0x29/0x68) from [<c00084db>] (gic_handle_irq+0x27/0x50) [ 4538.892059] [<c00084db>] (gic_handle_irq+0x27/0x50) from [<c045315b>] (__irq_svc+0x3b/0x5c) [ 4538.892059] Exception stack(0xc06e3f68 to 0xc06e3fb0) [ 4538.892059] 3f60: 00000000 00000000 00000000 00000000 c06e2000 c075f130 [ 4538.892120] 3f80: c06e2000 c075ea93 c075f130 c06ea594 c045c2e0 c06e2000 c0fe5908 c06e3fb0 [ 4538.892120] 3fa0: c007bab1 c0058b48 400f0133 ffffffff [ 4538.892120] [<c045315b>] (__irq_svc+0x3b/0x5c) from [<c0058b48>] (cpu_startup_entry+0xbc/0x164) [ 4538.892120] [<c0058b48>] (cpu_startup_entry+0xbc/0x164) from [<c06735f9>] (start_kernel+0x251/0x2ac) [ 4538.892120] [ 4538.892120] sending IPI to all other CPUs: [ 4538.892211] IPI backtrace for cpu 1 [ 4538.892211] [ 4538.892242] CPU: 1 PID: 2064 Comm: clamd Not tainted 3.10.1.0-1-linaro-omap #1ubuntu1~ci+130723003933-Ubuntu [ 4538.892242] task: edb09500 ti: ec91e000 task.ti: ec91e000 [ 4538.892272] PC is at 0xb6e2f0d4 [ 4538.892272] LR is at 0xb6eeec01 [ 4538.892272] pc : [<b6e2f0d4>] lr : [<b6eeec01>] psr: 000f0130 [ 4538.892272] sp : be8b472c ip : 62323337 fp : 0000684a [ 4538.892303] r10: 0084d750 r9 : 00000200 r8 : e86d6a2f [ 4538.892303] r7 : 0a0a0a0a r6 : 69393e32 r5 : 0080bf24 r4 : 0080bf28 [ 4538.892333] r3 : 81010100 r2 : 63333438 r1 : 0000000a r0 : 0080bf24 [ 4538.892333] Flags: nzcv IRQs on FIQs on Mode USER_32 ISA Thumb Segment user [ 4538.892333] Control: 50c5387d Table: acbd404a DAC: 55555555 [ 4538.892364] [ 4538.892364] R8: 0xe86d69af: [ 4538.892364] 69ac 6a6f7254 412e6e61 746e6567 3939332d 00303934 b1aa3270 25060000 47a83ca7 [ 4538.892395] 69cc e4ebc453 91ad979e 23363f8b fd49d9d0 773b48ba ad58f7d3 04c351eb 96e4414f [ 4538.892395] 69ec 7e1a3ac7 f39072a5 e362cedb b119b3e0 b595375e b2137762 b19f99a8 b10dc638 [ 4538.892395] 6a0c 18060000 2e6e6957 6a6f7254 412e6e61 746e6567 3939332d 00303534 b23ade28 [ 4538.892395] 6a2c 18060000 2e6e6957 6a6f7254 462e6e61 61656b61 37342d76 00373131 ac58376e [ 4538.892395] 6a4c 72542e6e 6e616a6f 3434382e 35313336 3e55c600 412e6eb2 72617764 61472e65 [ 4538.892517] 6a6c 6176656d 2d65636e 34393132 55b20037 1604b173 2e6e6957 6a6f7254 462e6e61 [ 4538.892547] 6a8c 61656b61 37342d76 00343131 b652e2c0 72542e6e 6e616a6f 7075532e 756a7265 [ 4538.892547] 6aac 322d6e61 fb003731 15b23a2b 2e6e6957 6a6f7254 412e6e61 746e6567 3939332d [ 4538.892547] CPU: 1 PID: 2064 Comm: clamd Not tainted 3.10.1.0-1-linaro-omap #1ubuntu1~ci+130723003933-Ubuntu [ 4538.892547] [<c001175d>] (unwind_backtrace+0x1/0x9c) from [<c000f625>] (show_stack+0x11/0x14) [ 4538.892639] [<c000f625>] (show_stack+0x11/0x14) from [<c0010819>] (handle_IPI+0xd5/0x158) [ 4538.892669] [<c0010819>] (handle_IPI+0xd5/0x158) from [<c00084ff>] (gic_handle_irq+0x4b/0x50) [ 4538.892669] [<c00084ff>] (gic_handle_irq+0x4b/0x50) from [<c0453369>] (__irq_usr+0x49/0x60) [ 4538.892700] Exception stack(0xec91ffb0 to 0xec91fff8) [ 4538.892700] ffa0: 0080bf24 0000000a 63333438 81010100 [ 4538.892730] ffc0: 0080bf28 0080bf24 69393e32 0a0a0a0a e86d6a2f 00000200 0084d750 0000684a [ 4538.892730] ffe0: 62323337 be8b472c b6eeec01 b6e2f0d4 000f0130 ffffffff

12 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel