RE: [PATCH v3 0/6] ARM: EXYNOS: Add secure firmware support
Tomasz Figa wrote: > > Some Exynos-based boards are running with secure firmware running in > TrustZone secure world, which changes the way some things have to be > initialized. > > This series adds support for specifying firmware operations, implements > some firmware operations for Exynos secure firmware and adds a method of > enabling secure firmware operations on Exynos-based boards through board > file and device tree. > > Changes since v2 > ( http://thread.gmane.org/gmane.linux.kernel.samsung-soc/12848 ) > - Made Exynos firmware binding require address > - Minor style fixes > > Changes since v1 > ( http://thread.gmane.org/gmane.linux.kernel.samsung- > soc/12583/focus=12820 ) > - Changed return types of all operations to int > - Defined all operations to return 0 on success, -ENOSYS when not > implemented or appropriate error code on error > > Tomasz Figa (6): > ARM: Add interface for registering and calling firmware-specific > operations > ARM: EXYNOS: Add support for secure monitor calls > ARM: EXYNOS: Add IO mapping for non-secure SYSRAM. > ARM: EXYNOS: Add support for Exynos secure firmware > ARM: EXYNOS: Add support for secondary CPU bring-up on Exynos4412 > ARM: EXYNOS: Add secure firmware support to secondary CPU bring-up > > .../devicetree/bindings/arm/samsung-boards.txt | 10 > arch/arm/common/Makefile | 2 + > arch/arm/common/firmware.c | 18 ++ > arch/arm/include/asm/firmware.h| 31 ++ > arch/arm/mach-exynos/Makefile | 6 ++ > arch/arm/mach-exynos/common.c | 35 +++ > arch/arm/mach-exynos/common.h | 2 + > arch/arm/mach-exynos/exynos-smc.S | 22 +++ > arch/arm/mach-exynos/firmware.c| 67 > ++ > arch/arm/mach-exynos/include/mach/map.h| 3 + > arch/arm/mach-exynos/mach-exynos4-dt.c | 1 + > arch/arm/mach-exynos/platsmp.c | 37 ++-- > arch/arm/mach-exynos/smc.h | 31 ++ > arch/arm/plat-samsung/include/plat/map-s5p.h | 1 + > 14 files changed, 260 insertions(+), 6 deletions(-) > create mode 100644 arch/arm/common/firmware.c > create mode 100644 arch/arm/include/asm/firmware.h > create mode 100644 arch/arm/mach-exynos/exynos-smc.S > create mode 100644 arch/arm/mach-exynos/firmware.c > create mode 100644 arch/arm/mach-exynos/smc.h > > -- > 1.7.12 (+ Russell King) As we discussed, let me pick up this series into Samsung tree. If any objections, please kindly let me know. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- 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 1/4] thermal: Add new thermal trend type to support quick cooling
> -Original Message-
> From: Zhang, Rui
> Sent: Monday, November 12, 2012 12:03 PM
> To: R, Durgadoss
> Cc: Amit Kachhap; linux...@lists.linux-foundation.org; linux-samsung-
> s...@vger.kernel.org; linux-ker...@vger.kernel.org; l...@kernel.org; linux-
> a...@vger.kernel.org; jonghwa3@samsung.com
> Subject: RE: [PATCH 1/4] thermal: Add new thermal trend type to support
> quick cooling
>
> On Sun, 2012-11-11 at 22:55 -0700, R, Durgadoss wrote:
> > Hi Amit/Rui,
> >
> > > -Original Message-
> > > From: Amit Kachhap [mailto:amit.kach...@linaro.org]
> > > Sent: Friday, November 09, 2012 11:52 AM
> > > To: Zhang, Rui
> > > Cc: linux...@lists.linux-foundation.org; linux-samsung-
> > > s...@vger.kernel.org; linux-ker...@vger.kernel.org; R, Durgadoss;
> > > l...@kernel.org; linux-a...@vger.kernel.org;
> jonghwa3@samsung.com
> > > Subject: Re: [PATCH 1/4] thermal: Add new thermal trend type to
> support
> > > quick cooling
> > >
> > > On 9 November 2012 09:21, Zhang Rui wrote:
> > > > On Thu, 2012-11-08 at 11:56 +0530, Amit Kachhap wrote:
> > > >> On 8 November 2012 11:31, Zhang Rui wrote:
> > > >> > On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
> > > >> >> This modification adds 2 new thermal trend type
> > > THERMAL_TREND_RAISE_FULL
> > > >> >> and THERMAL_TREND_DROP_FULL. This thermal trend can be used
> to
> > > quickly
> > > >> >> jump to the upper or lower cooling level instead of incremental
> > > increase
> > > >> >> or decrease.
> > > >> >
> > > >> > IMO, what we need is a new more aggressive cooling governor
> which
> > > always
> > > >> > uses upper limit when the temperature is raising and lower limit
> when
> > > >> > the temperature is dropping.
> > > >> Yes I agree that a new aggressive governor is the best approach but
> > > >> then i thought adding a new trend type is a simple solution to achieve
> > > >> this and since most of the governor logic might be same as the
> > > >> step-wise governor. I have no objection in doing it through governor.
> > > >> >
> > > > hmmm,
> > > > I think a more proper way is to set the cooling state to upper limit
> > > > when it overheats and reduce the cooling state step by step when the
> > > > temperature drops.
> > >
> > > No actually I was thinking of having a simple governor with a feature
> > > like it only sets to upper level and lower level. Also since the
> > > temperature sensor is capable of interrupting for both increase in
> > > threshold(say 100C) and fall in threshold (say 90C), so polling or
> > > step increments is not needed at all.
> > > Currently stepwise governor governor does that so we might change the
> > > macro name as,
> > > THERMAL_TREND_RAISE_STEP,
> > > THERMAL_TREND_DROP_STEP,
> > > THERMAL_TREND_RAISE_MAX,
> > > THERMAL_TREND_DROP_MAX,
> > >
> > > and file step_wise.c can be named as state_wise.c or trend_wise.c.
> >
> > Yes, in this particular case, we neither need to poll nor do step wise
> > operations. But, most of the other sensors need at least one of them.
> >
> > So, I think we can try it this way:
> > if (sensor supports interrupt) {
> > 'always' use RAISE_MAX and DROP_MAX;
> > } else {
> > Do Step wise operations
> > }
> >
> why should the generic thermal layer be aware of this?
>
> IMO, it is the platform thermal driver that is responsible for returning
> THERMAL_TREND_RAISE_STEP or THERMAL_TREND_RAISE_MAX.
>
> and the step_wise governor just takes action based on the return value
> of .get_trend() callback.
Yes, agree with the flow ..
Thanks,
Durga
N�r��yb�X��ǧv�^�){.n�+{�x,�ȧ���ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf
RE: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
On Sun, 2012-11-11 at 22:55 -0700, R, Durgadoss wrote:
> Hi Amit/Rui,
>
> > -Original Message-
> > From: Amit Kachhap [mailto:amit.kach...@linaro.org]
> > Sent: Friday, November 09, 2012 11:52 AM
> > To: Zhang, Rui
> > Cc: linux...@lists.linux-foundation.org; linux-samsung-
> > s...@vger.kernel.org; linux-ker...@vger.kernel.org; R, Durgadoss;
> > l...@kernel.org; linux-a...@vger.kernel.org; jonghwa3@samsung.com
> > Subject: Re: [PATCH 1/4] thermal: Add new thermal trend type to support
> > quick cooling
> >
> > On 9 November 2012 09:21, Zhang Rui wrote:
> > > On Thu, 2012-11-08 at 11:56 +0530, Amit Kachhap wrote:
> > >> On 8 November 2012 11:31, Zhang Rui wrote:
> > >> > On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
> > >> >> This modification adds 2 new thermal trend type
> > THERMAL_TREND_RAISE_FULL
> > >> >> and THERMAL_TREND_DROP_FULL. This thermal trend can be used to
> > quickly
> > >> >> jump to the upper or lower cooling level instead of incremental
> > increase
> > >> >> or decrease.
> > >> >
> > >> > IMO, what we need is a new more aggressive cooling governor which
> > always
> > >> > uses upper limit when the temperature is raising and lower limit when
> > >> > the temperature is dropping.
> > >> Yes I agree that a new aggressive governor is the best approach but
> > >> then i thought adding a new trend type is a simple solution to achieve
> > >> this and since most of the governor logic might be same as the
> > >> step-wise governor. I have no objection in doing it through governor.
> > >> >
> > > hmmm,
> > > I think a more proper way is to set the cooling state to upper limit
> > > when it overheats and reduce the cooling state step by step when the
> > > temperature drops.
> >
> > No actually I was thinking of having a simple governor with a feature
> > like it only sets to upper level and lower level. Also since the
> > temperature sensor is capable of interrupting for both increase in
> > threshold(say 100C) and fall in threshold (say 90C), so polling or
> > step increments is not needed at all.
> > Currently stepwise governor governor does that so we might change the
> > macro name as,
> > THERMAL_TREND_RAISE_STEP,
> > THERMAL_TREND_DROP_STEP,
> > THERMAL_TREND_RAISE_MAX,
> > THERMAL_TREND_DROP_MAX,
> >
> > and file step_wise.c can be named as state_wise.c or trend_wise.c.
>
> Yes, in this particular case, we neither need to poll nor do step wise
> operations. But, most of the other sensors need at least one of them.
>
> So, I think we can try it this way:
> if (sensor supports interrupt) {
> 'always' use RAISE_MAX and DROP_MAX;
> } else {
> Do Step wise operations
> }
>
why should the generic thermal layer be aware of this?
IMO, it is the platform thermal driver that is responsible for returning
THERMAL_TREND_RAISE_STEP or THERMAL_TREND_RAISE_MAX.
and the step_wise governor just takes action based on the return value
of .get_trend() callback.
thanks,
rui
--
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 1/4] thermal: Add new thermal trend type to support quick cooling
Hi Amit/Rui,
> -Original Message-
> From: Amit Kachhap [mailto:amit.kach...@linaro.org]
> Sent: Friday, November 09, 2012 11:52 AM
> To: Zhang, Rui
> Cc: linux...@lists.linux-foundation.org; linux-samsung-
> s...@vger.kernel.org; linux-ker...@vger.kernel.org; R, Durgadoss;
> l...@kernel.org; linux-a...@vger.kernel.org; jonghwa3@samsung.com
> Subject: Re: [PATCH 1/4] thermal: Add new thermal trend type to support
> quick cooling
>
> On 9 November 2012 09:21, Zhang Rui wrote:
> > On Thu, 2012-11-08 at 11:56 +0530, Amit Kachhap wrote:
> >> On 8 November 2012 11:31, Zhang Rui wrote:
> >> > On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
> >> >> This modification adds 2 new thermal trend type
> THERMAL_TREND_RAISE_FULL
> >> >> and THERMAL_TREND_DROP_FULL. This thermal trend can be used to
> quickly
> >> >> jump to the upper or lower cooling level instead of incremental
> increase
> >> >> or decrease.
> >> >
> >> > IMO, what we need is a new more aggressive cooling governor which
> always
> >> > uses upper limit when the temperature is raising and lower limit when
> >> > the temperature is dropping.
> >> Yes I agree that a new aggressive governor is the best approach but
> >> then i thought adding a new trend type is a simple solution to achieve
> >> this and since most of the governor logic might be same as the
> >> step-wise governor. I have no objection in doing it through governor.
> >> >
> > hmmm,
> > I think a more proper way is to set the cooling state to upper limit
> > when it overheats and reduce the cooling state step by step when the
> > temperature drops.
>
> No actually I was thinking of having a simple governor with a feature
> like it only sets to upper level and lower level. Also since the
> temperature sensor is capable of interrupting for both increase in
> threshold(say 100C) and fall in threshold (say 90C), so polling or
> step increments is not needed at all.
> Currently stepwise governor governor does that so we might change the
> macro name as,
> THERMAL_TREND_RAISE_STEP,
> THERMAL_TREND_DROP_STEP,
> THERMAL_TREND_RAISE_MAX,
> THERMAL_TREND_DROP_MAX,
>
> and file step_wise.c can be named as state_wise.c or trend_wise.c.
Yes, in this particular case, we neither need to poll nor do step wise
operations. But, most of the other sensors need at least one of them.
So, I think we can try it this way:
if (sensor supports interrupt) {
'always' use RAISE_MAX and DROP_MAX;
} else {
Do Step wise operations
}
And this could be plugged into step wise. I don't think we need a
complete new governor just to get this case working.
For this to work, we need a way for the governor to know 'whether the
sensor can work on interrupt mode'. May be introducing a new field in
tzd structure can help us here.
I am fine with any name for the governor :-)
Thanks,
Durga
--
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 1/4] thermal: Add new thermal trend type to support quick cooling
On Fri, 2012-11-09 at 11:51 +0530, Amit Kachhap wrote:
> On 9 November 2012 09:21, Zhang Rui wrote:
> > On Thu, 2012-11-08 at 11:56 +0530, Amit Kachhap wrote:
> >> On 8 November 2012 11:31, Zhang Rui wrote:
> >> > On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
> >> >> This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
> >> >> and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
> >> >> jump to the upper or lower cooling level instead of incremental increase
> >> >> or decrease.
> >> >
> >> > IMO, what we need is a new more aggressive cooling governor which always
> >> > uses upper limit when the temperature is raising and lower limit when
> >> > the temperature is dropping.
> >> Yes I agree that a new aggressive governor is the best approach but
> >> then i thought adding a new trend type is a simple solution to achieve
> >> this and since most of the governor logic might be same as the
> >> step-wise governor. I have no objection in doing it through governor.
> >> >
> > hmmm,
> > I think a more proper way is to set the cooling state to upper limit
> > when it overheats and reduce the cooling state step by step when the
> > temperature drops.
>
> No actually I was thinking of having a simple governor with a feature
> like it only sets to upper level and lower level. Also since the
> temperature sensor is capable of interrupting for both increase in
> threshold(say 100C) and fall in threshold (say 90C), so polling or
> step increments is not needed at all.
> Currently stepwise governor governor does that so we might change the
> macro name as,
> THERMAL_TREND_RAISE_STEP,
> THERMAL_TREND_DROP_STEP,
> THERMAL_TREND_RAISE_MAX,
> THERMAL_TREND_DROP_MAX,
>
> and file step_wise.c can be named as state_wise.c or trend_wise.c.
>
> I am not sure if it is the best way . How do you feel ?
>
this sounds good to me.
I'd like to see Durga' comments on this as well.
thanks,
rui
> > what do you think?
> >
> > thanks,
> > rui
> >
> >> > I can write such a governor if you do not have time to.
> >> ok. thanks
> >> >
> >> > thanks,
> >> > rui
> >> >> This is needed for temperature sensors which support rising/falling
> >> >> threshold interrupts and polling can be totally avoided.
> >> >>
> >> >
> >> >
> >> >> Signed-off-by: Amit Daniel Kachhap
> >> >> Signed-off-by: Amit Daniel Kachhap
> >> >> ---
> >> >> drivers/thermal/step_wise.c | 19 +++
> >> >> include/linux/thermal.h |2 ++
> >> >> 2 files changed, 17 insertions(+), 4 deletions(-)
> >> >>
> >> >> diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
> >> >> index 1242cff..0d2d8d6 100644
> >> >> --- a/drivers/thermal/step_wise.c
> >> >> +++ b/drivers/thermal/step_wise.c
> >> >> @@ -35,6 +35,10 @@
> >> >> * state for this trip point
> >> >> *b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
> >> >> * state for this trip point
> >> >> + *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
> >> >> + * state for this trip point
> >> >> + *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
> >> >> + * state for this trip point
> >> >> */
> >> >> static unsigned long get_target_state(struct thermal_instance
> >> >> *instance,
> >> >> enum thermal_trend trend)
> >> >> @@ -50,7 +54,10 @@ static unsigned long get_target_state(struct
> >> >> thermal_instance *instance,
> >> >> } else if (trend == THERMAL_TREND_DROPPING) {
> >> >> cur_state = cur_state > instance->lower ?
> >> >> (cur_state - 1) : instance->lower;
> >> >> - }
> >> >> + } else if (trend == THERMAL_TREND_RAISE_FULL)
> >> >> + cur_state = instance->upper;
> >> >> + else if (trend == THERMAL_TREND_DROP_FULL)
> >> >> + cur_state = instance->lower;
> >> >>
> >> >> return cur_state;
> >> >> }
> >> >> @@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct
> >> >> thermal_zone_device *tz,
> >> >> }
> >> >>
> >> >> static void update_instance_for_dethrottle(struct thermal_zone_device
> >> >> *tz,
> >> >> - int trip, enum thermal_trip_type
> >> >> trip_type)
> >> >> + int trip, enum thermal_trip_type
> >> >> trip_type,
> >> >> + enum thermal_trend trend)
> >> >> {
> >> >> struct thermal_instance *instance;
> >> >> struct thermal_cooling_device *cdev;
> >> >> @@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct
> >> >> thermal_zone_device *tz,
> >> >> cdev = instance->cdev;
> >> >> cdev->ops->get_cur_state(cdev, &cur_state);
> >> >>
> >> >> - instance->target = cur_state > instance->lower ?
> >> >> + if (trend == THERMAL_TREND_DROP_FULL)
> >> >> + instance->target = instance->lower;
> >> >> + else
RE: [PATCH 2/4] gpio: samsung: Skip registration if pinctrl driver is present on Exynos4x12
Linus Walleij wrote: > > > > > Can you drop above 3 commits in your tree? If many conflicts happens > during > > rebasing, how about that I merge your pinctrl/samsung branch into > Samsung > > tree?... > > Why not :-) > > I have removed the samsung branch from my for-next to avoid > clashes. > Thanks ;-) > So please bring the samsung branch into you tree and fix > everything up there. > I did. > Axel Lin has sent some tree-wide cleanups but let's hope they don't > hit samsung so much, or they will need to be postponed/dropped. > OK, I see. Thanks again. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- 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 2/2] ARM: S3C64XX: Staticly define parent clock of "camera" clock
Sylwester Nawrocki wrote: > > On 11/10/2012 10:13 PM, Sylwester Nawrocki wrote: > > On 11/10/2012 03:07 PM, dron0...@gmail.com wrote: > >> From: Andrey Gusakov > >> > >> The "camera" clock have only one parent. Define it staticly and > > Forgot to point out a small typo here: staticly -> statically. > Thanks for pointing out. I fixed it when I applied. > >> remove unused source clock list. > >> > >> Signed-off-by: Andrey Gusakov > > > > Reviewed-by: Sylwester Nawrocki Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- 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 1/2] ARM: S3C64XX: Remove duplicated camera clock
Sylwester Nawrocki wrote: > > On 11/10/2012 03:07 PM, dron0...@gmail.com wrote: > > From: Andrey Gusakov > > > > Camera clock defined two times. One in init_clocks_off array with > > "cam" name, second in clksrcs array with "camera" name. Leave > > second definition because clock have divider. > > > > Signed-off-by: Andrey Gusakov > > Reviewed-by: Sylwester Nawrocki Applied, thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- 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 v7 0/5] usb: phy: samsung: Introducing usb phy driver for samsung SoCs
Felipe Balbi wrote:
>
> Hi,
>
Hi :-)
[...]
> Sure, but I still need Kukjin's 'say-so' for the arch/arm/plat-samsung
> and arch/arm/mach-exynos part.
>
Basically, this approach looks OK to me.
BTW, I have some comments and need to update...
>From 4th patch...
> diff --git a/arch/arm/mach-s3c64xx/mach-smdk6410.c b/arch/arm/mach-
> s3c64xx/mach-smdk6410.c
[...]
> @@ -72,6 +73,8 @@
> #include
> #include
> #include
> +#include
Why? In addition, this causes build error with s3c6400_defconfig.
[...]
> diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
> index 03f654d..9cdb666 100644
[...]
> @@ -1370,6 +1371,30 @@ struct platform_device s5p_device_mixer = {
>
> /* USB */
>
> +#ifdef CONFIG_S3C_DEV_USB_HSOTG
> +/* USB PHY*/
> +static struct resource samsung_usbphy_resource[] = {
> + [0] = {
> + .start = S3C_PA_USB_PHY,
> + .end = S3C_PA_USB_PHY + SZ_16 - 1,
> + .flags = IORESOURCE_MEM,
> + },
> +};
+static struct resource samsung_usbphy_resource[] = {
+ [0] = DEFINED_RES_MEM(S3C_PA_USB_PHY, SZ_16),
+};
[...]
Happens build error with s5pv210_defconfig
arch/arm/plat-samsung/devs.c:1375: error: 'S3C_PA_USB_PHY' undeclared here
(not in a function)
make[2]: *** [arch/arm/plat-samsung/devs.o] Error 1
make[1]: *** [arch/arm/plat-samsung] Error 2
make[1]: *** Waiting for unfinished jobs
And another build error with exynos_defconfig...
arch/arm/mach-exynos/built-in.o: In function `.LANCHOR1':
setup-i2c0.c:(.data+0x8080): undefined reference to
`s5p_usb_phy_pmu_isolation'
>From 5th patch
If possible, please to use 'ARM: [sub-arch dir name]: [subject]' format.
So I preferred to use 'ARM: EXYNOS: Enabling samsung-usbphy driver for
EXYNOS4210' on that.
Please make sure your patch has no problem for kernel compilation before
submitting...
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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 2/4] gpio: samsung: Skip registration if pinctrl driver is present on Exynos4x12
On Fri, Nov 9, 2012 at 11:09 AM, Kukjin Kim wrote:
>> On Wed, Nov 7, 2012 at 5:41 AM, Kukjin Kim wrote:
>>
>> > A commit 1b6056d6 ("pinctrl: samsung: Include bank-specific eint offset
>> in
>> > bank struct") which is in your pinctrl tree (samsung branch) changed
>> > macro(EXYNOS_PIN_BANK_EINTG) to add offset. Eventually, this series(due
>> to
>> > 3rd patch, pinctrl: samsung: Add support for Exynos4x12) breaks
>> compilation
>> > without the commit. So if you don't have a plan to rebase samsung branch
>> of
>> > your pinctrl tree, I'd like to merge it in my tree. Is it ok to you?
>>
>> Sure tell me when you've merged it and I'll drop commit 1b6056d6
>> from my tree.
>>
>
> Thanks :-)
>
> (- some guys in Cc...)
>
> But having a problem, the 'it' means the commit 1b6056d6? If so, I couldn't
> cherry-pick only that because of dependency with other commits 40ba622 and
> 3a232ba.
>
> $ git cherry-pick -s 40ba622
> [next/dt-exynos4x12 3b1977c] pinctrl: samsung: Assing pin numbers
> dynamically
> Author: Tomasz Figa
> 3 files changed, 62 insertions(+), 54 deletions(-)
>
> $ git cherry-pick -s 3a232ba
> [next/dt-exynos4x12 7fa08a4] pinctrl: samsung: Remove static pin
> enumerations
> Author: Tomasz Figa
> 1 files changed, 96 insertions(+), 215 deletions(-)
> rewrite drivers/pinctrl/pinctrl-exynos.h (66%)
>
> $ git cherry-pick -s 1b6056d
> [next/dt-exynos4x12 86010aa] pinctrl: samsung: Include bank-specific eint
> offset in bank struct
> Author: Tomasz Figa
> 3 files changed, 30 insertions(+), 29 deletions(-)
>
> I could cherry-pick clearly with 2 more commits.
>
> Can you drop above 3 commits in your tree? If many conflicts happens during
> rebasing, how about that I merge your pinctrl/samsung branch into Samsung
> tree?...
Why not :-)
I have removed the samsung branch from my for-next to avoid
clashes.
So please bring the samsung branch into you tree and fix
everything up there.
Axel Lin has sent some tree-wide cleanups but let's hope they don't
hit samsung so much, or they will need to be postponed/dropped.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: S3C244X/S3C64XX SoC camera host interface driver questions
Hi. Patch v2 attached. Comments taken into account. >> I often get "VIDIOC_QUERYCAP: failed: Inappropriate ioctl for device" > This is an issue in the v4l2-ctl, it is going to be fixed by adding > VIDIOC_SUBDEV_QUERYCAP ioctl for subdevs. It has been just discussed today. > I guess you get it when running v4l2-ctl on /dev/v4l-subdev* ? Yes. >> or "system error: Inappropriate ioctl for device" > I think this one is caused by unimplemented VIDIOC_G/S_PARM ioctls > at the s3c-camif driver. >> Is it because of not implemented set/get framerate func? How this > Yes, I think so. ioctls as above. Ok. I'll implement this ioctls and see what happens. >> should work? I mean framerate heavy depend of sensor's settings. So >> set/get framerate call to fimc should get/set framerate from sensor. >> What is mechanism of such things? > > > With user space subdev API one should control frame interval directly > on the sensor subdev device node [1]. For Gstreamer to work with > VIDIOC_G/S_PARM ioctls we need a dedicated v4l2 library (possibly with > a plugin for s3c-camif, but that shouldn't be needed since it is very > simple driver) that will translate those video node ioctls into the > subdev node ioctls [2]. Unfortunately such library is still not available. > > >> And same question about synchronizing format of sensor and FIMC pads. >> I make ov2640 work, but if did not call media-ctl for sensor, format >> of FIMC sink pad and format of sensor source pad different. I think I >> missed something, but reading other sources did not help. > > > As I explained previously, s3c-fimc is supposed to synchronize format > with the sensor subdev. Have you got pad level get_fmt callback > implemented in the ov2640 driver ? Yes. > Could you post your 'media-ctl -p' output, run right after the system boot ? Looks like I messed up, after starting formats are the same: Opening media device /dev/media0ov2640: ov2640_open:1381 Enumerating entities Found 4 entities Enumerating pads and links Media controller API version 0.0.0 Media device information driver s3c-camif model SAMSUNG S3C6410 CAMIF serial bus infoplatform:%s hw revision 0x32 driver version 0.0.0 Device topology - entity 1: ov2640 (1 pad, 1 link) type V4L2 subdev subtype Sensor device node name /dev/v4l-subdev0 pad0: Source [YUYV2X8 176x144] -> "S3C-CAMIF":0 [ENABLED,IMMUTABLE] - entity 2: S3C-CAMIF (3 pads, 3 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev1 pad0: Sink [YUYV2X8 176x144 (0,0)/176x144] <- "ov2640":0 [ENABLED,IMMUTABLE] pad1: Source [YUYV2X8 176x144] -> "camif-codec":0 [ENABLED,IMMUTABLE] pad2: Source [YUYV2X8 176x144] -> "camif-preview":0 [ENABLED,IMMUTABLE] - entity 3: camif-codec (1 pad, 1 link) type Node subtype V4L device node name /dev/video0 pad0: Sink <- "S3C-CAMIF":1 [ENABLED,IMMUTABLE] - entity 4: camif-preview (1 pad, 1 link) type Node subtype V4L device node name /dev/video1 pad0: Sink <- "S3C-CAMIF":2 [ENABLED,IMMUTABLE] 0001-ARM-S3C-CAMIF-add-image-effect-controls.patch Description: Binary data
