> +
>>
>> Are you planning to reimplement most of these two files in C as per
>> Wolfgang's comments on the TRATS board, or is that a separate issue?
> Not as of now. We have 14K for spl. Using C style it might not fit into
> that.
I
tzpc {
> +struct s5p_tzpc {
I think 'exynos' is preferable. Even though each SOC has different
number of tzpc. It can be covered one exynos_tzpc. or we can define
it for each SoC.
Thank you,
Kyungmin Park
> unsigned int r0size;
> char res1[0x7FC];
> un
/prime support has already been reviewed
> by a lot of folks, and tested with a few different drivers (exynos,
> omapdrm, i915, nouveau, udl) with some driver support that could be
> pushed for 3.5 cycle if the core support makes it in for 3.4 cycle.
Yes,
This patches are tested on samsung exynos4 platform.
Acked-by: Kyungmin Park
On Tue, Jun 28, 2011 at 5:11 PM, Per Forlin wrote:
> How significant is the cache maintenance over head?
> It depends, the eMMC are much faster now
> compared to a few years ago and cache maintenance cost mo
Hi Angus,
Thank you for working on MALI drivers. BTW, do you have a plan to post
these patches to mainline?
See comments below.
Thank you,
Kyungmin Park
On Sat, Jul 16, 2011 at 3:54 AM, Angus Ainslie wrote:
> The mali driver needs an SoC specific config file to build. This
> is f
bout to add the clock control here?
1. Register chipid clk
2. Get the chipid clk
3. Read CHPIID,
4. Put tht chipid clk.
Then you can save some power.
Thank you,
Kyungmin Park
> +
> + return subrev;
> +}
> +
> int __init exynos4_init(void)
> {
> printk(KERN_INFO
BTW, does it same as other ARM cpus?. e.g., exynos4 has same codes as this.
How to you think it? Need to modify the same way?
Thank you,
Kyungmin Park
>>
>> Signed-off-by: Vincent Guittot
>
> Acked-by: Linus Walleij
>
> Yours,
> Linus Walleij
>
>
n my PL310 Spec., it's reserved bit
and should be zero (SBZ).
Thank you,
Kyungmin Park
On Tue, Sep 13, 2011 at 3:07 PM, Siarhei Siamashka
wrote:
> Setting "Double linefill enable" bit improves memcpy performance
> from ~750 MB/s to ~1150 MB/s when working with large buffers and
On Wed, Sep 14, 2011 at 4:43 PM, Siarhei Siamashka
wrote:
> On Wed, Sep 14, 2011 at 9:08 AM, Kyungmin Park wrote:
>> Hi Siarhei,
>>
>> Interesting feature, and it's not samsung soc issue, so add the arm
>> mailing list.
>> It checked and the see the read
; Second, I think there could be use for a common low level display
> framework. Currently the lower level code (display HW handling, etc.)
> and higher level code (buffer management, policies, etc) seem to be
> usually tied together, like the fb framework or the drm. Granted, the
>
Hi,
exynos4 tmu is already merged 3.2-rc
you can find it at below message and latest git kernel
http://www.spinics.net/lists/lm-sensors/msg33872.html
Thank you,
Kyungmin Park
On Wed, Oct 26, 2011 at 8:36 PM, Amit Daniel Kachhap
wrote:
> This patch adds support for thermal sensor driver.
Please split the two patches.
1. Add TMU Kconfig
2. board support
On Wed, Oct 26, 2011 at 8:36 PM, Amit Daniel Kachhap
wrote:
> Signed-off-by: Amit Daniel Kachhap
> ---
> arch/arm/mach-exynos4/Kconfig | 5 +
> arch/arm/mach-exynos4/mach-origen.c | 10 ++
> 2 files changed
Hi,
New Cortex-A15 also uses the armv7. So it's better to use the exynos itself.
Just remove the number 4.
Thank you,
Kyungmin Park
On 11/25/11, Chander Kashyap wrote:
> As per new conventions Samsung SoC's are named as Exynos.
> Cortex-A9 based Soc's are named as exynos4.
1\n"
> + " orr %0, %0, %2\n"
> + " mcr p15, 0, %0, c1, c0, 1\n"
> + : "=&r" (v)
> + : "Ir" (CR_C), "Ir" (0x40)
> + : "cc");
> +}
> +
> +void cp
Hi,
It's interesting.
Can you send the your working codes to test it in our environment. Samsung SoC.
Thank you,
Kyungmin Park
On Sat, Dec 18, 2010 at 12:38 AM, Per Forlin wrote:
> Hi again,
>
> I made a mistake in my double buffering implementation.
> I assumed dma_unmap did
Need to investigate it.
Thank you,
Kyungmin Park
On Sat, Dec 18, 2010 at 11:19 PM, Per Forlin wrote:
> Hi,
>
> Thanks for your interest. I am in the middle of rewriting parts due to
> my findings about dma_unmap. If everything goes well I should have a
> new prototype ready on Tue
his.
> I'm not sure of the latest status of this series.
Still ARM maintainer doesn't agree these patches since it's not solve
the ARM memory different attribute mapping problem.
but try to send the CMA v9 patch soon.
We need really require the physical memory management module. Each
chi
there's no way to solve the ARM issue.
We really need the memory solution for multimedia.
Thank you,
Kyungmin Park
>
> Yours,
> Linus Walleij
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
&
Dear Jonghun,
It's also helpful to explain what's the original purpose of UMP (for
GPU, MALI) and what's the goal of UMP usage for multimedia stack.
Especially, what's the final goal of UMP from LSI.
Also consider the previous GPU memory management program, e.g., SGX.
Than
Hi,
CCed updated Michal email address,
One note, As Michal moved to google, Marek is works on CMA. We are
also studying the hwmem and GEM.
Thank you,
Kyungmin Park
On Wed, Mar 9, 2011 at 9:18 PM, wrote:
> Hello everyone,
>
> The following patchset implements a "hardware memor
current frameworks are enough.
The missing is that no generic memory passing mechanism. We need the
generic memory passing interface. that's all.
3. Linaro (5/9~5/13): ARM, SoC vendors and v4l2 persons.
I hope several person are anticipated and made a small step for final goal.
Thank yo
Hi,
BTW, Are there reason to omit the sdhci-s3c.c? Maybe Mr. Jung will handle it.
Thank you,
Kyungmin Park
On Tue, Apr 19, 2011 at 7:20 PM, Wolfram Sang wrote:
> Hi Shawn,
>
> On Fri, Mar 25, 2011 at 04:48:46PM +0800, Shawn Guo wrote:
>> Here are what the patch set does.
>&g
On Wed, Apr 20, 2011 at 2:47 AM, Wolfram Sang wrote:
>
>> BTW, Are there reason to omit the sdhci-s3c.c? Maybe Mr. Jung will handle it.
>
> The difference is that sdhci-s3c.c was more like a fork of sdhci-pltfm while
> the others were users of it. With the new interface, s3c can be converted
> us
23 matches
Mail list logo
