RE: [PATCH] ARM: EXYNOS4: Add to support ORIGEN board
JeongHyeon Kim wrote: > > From: JeongHyeon Kim > > This patch adds to support Insignal's ORIGEN board. > > Signed-off-by: JeongHyeon Kim > --- > arch/arm/mach-exynos4/Kconfig | 10 +++ > arch/arm/mach-exynos4/Makefile |1 + > arch/arm/mach-exynos4/mach-origen.c | 108 > +++ > 3 files changed, 119 insertions(+), 0 deletions(-) > create mode 100644 arch/arm/mach-exynos4/mach-origen.c > Hi Jeonghyeon, Basically, adding board file cannot be merged(applied) into regarding ARM maintainer tree now even though your patch has no problem. You can easily find the reason when you read some threads in here. So I'm not sure when your patch can be merged. There is comment. But no need to re-submit, if required, I can fix it when I apply this. > diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig > index e849f67..0a61cf3 100644 > --- a/arch/arm/mach-exynos4/Kconfig > +++ b/arch/arm/mach-exynos4/Kconfig > @@ -177,6 +177,16 @@ config MACH_NURI > help > Machine support for Samsung Mobile NURI Board. > > +config MACH_ORIGEN > +bool "ORIGEN" > +select CPU_EXYNOS4210 > +select S3C_DEV_RTC > +select S3C_DEV_WDT > +select S3C_DEV_HSMMC2 > +select EXYNOS4_SETUP_SDHCI > +help > + Machine support for ORIGEN based on Samsung S5PV310 Should be tab... 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] ARM: SAMSUNG: Add support for pre-sleep/post-restore gpio control
Mark Brown wrote:
>
> From: Ben Dooks
>
> Add a callback so that per-arch can do pre-sleep and post-resume
> gpio configuration so that for the S3C64XX, the GPIO configuration
> is restored before the sleep mode is cleared.
>
> For the S3C64XX case, it means that the GPIOs get set back to normal
> operation after the restore code puts the original configurations
> back in after the
>
> Signed-off-by: Ben Dooks
> Signed-off-by: Mark Brown
> ---
> arch/arm/mach-s3c2410/include/mach/pm-core.h |3 +++
> arch/arm/mach-s3c64xx/include/mach/pm-core.h | 17 +
> arch/arm/mach-s5pv210/include/mach/pm-core.h |3 +++
> arch/arm/plat-samsung/pm.c |2 ++
> 4 files changed, 25 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-s3c2410/include/mach/pm-core.h b/arch/arm/mach-
> s3c2410/include/mach/pm-core.h
> index 70a83b2..45eea52 100644
> --- a/arch/arm/mach-s3c2410/include/mach/pm-core.h
> +++ b/arch/arm/mach-s3c2410/include/mach/pm-core.h
> @@ -62,3 +62,6 @@ static inline void s3c_pm_arch_update_uart(void __iomem
> *regs,
> struct pm_uart_save *save)
> {
> }
> +
> +static inline void s3c_pm_restored_gpios(void) { }
> +static inline void s3c_pm_saved_gpios(void) { }
> diff --git a/arch/arm/mach-s3c64xx/include/mach/pm-core.h b/arch/arm/mach-
> s3c64xx/include/mach/pm-core.h
> index 4ed0f58..38659be 100644
> --- a/arch/arm/mach-s3c64xx/include/mach/pm-core.h
> +++ b/arch/arm/mach-s3c64xx/include/mach/pm-core.h
> @@ -96,3 +96,20 @@ static inline void s3c_pm_arch_update_uart(void __iomem
> *regs,
> save->ucon = new_ucon;
> }
> }
> +
> +static inline void s3c_pm_restored_gpios(void)
> +{
> + /* ensure sleep mode has been cleared from the system */
> +
> + __raw_writel(0, S3C64XX_SLPEN);
> +}
> +
> +static inline void s3c_pm_saved_gpios(void)
> +{
> + /* turn on the sleep mode and keep it there, as it seems that during
> + * suspend the xCON registers get re-set and thus you can end up
with
> + * problems between going to sleep and resuming.
> + */
> +
> + __raw_writel(S3C64XX_SLPEN_USE_xSLP, S3C64XX_SLPEN);
> +}
> diff --git a/arch/arm/mach-s5pv210/include/mach/pm-core.h b/arch/arm/mach-
> s5pv210/include/mach/pm-core.h
> index e8d394f..3e22109 100644
> --- a/arch/arm/mach-s5pv210/include/mach/pm-core.h
> +++ b/arch/arm/mach-s5pv210/include/mach/pm-core.h
> @@ -41,3 +41,6 @@ static inline void s3c_pm_arch_update_uart(void __iomem
> *regs,
> {
> /* nothing here yet */
> }
> +
> +static inline void s3c_pm_restored_gpios(void) { }
> +static inline void s3c_pm_saved_gpios(void) { }
> diff --git a/arch/arm/plat-samsung/pm.c b/arch/arm/plat-samsung/pm.c
> index 5c0a440..4f9a951 100644
> --- a/arch/arm/plat-samsung/pm.c
> +++ b/arch/arm/plat-samsung/pm.c
> @@ -268,6 +268,7 @@ static int s3c_pm_enter(suspend_state_t state)
> /* save all necessary core registers not covered by the drivers */
>
> s3c_pm_save_gpios();
> + s3c_pm_saved_gpios();
> s3c_pm_save_uarts();
> s3c_pm_save_core();
>
> @@ -309,6 +310,7 @@ static int s3c_pm_enter(suspend_state_t state)
> s3c_pm_restore_core();
> s3c_pm_restore_uarts();
> s3c_pm_restore_gpios();
> + s3c_pm_restored_gpios();
>
> s3c_pm_debug_init();
>
> --
> 1.7.4.1
Ok, will apply.
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 v2] ARM: S3C64XX: Remove gpio-bank-X header files
Joonyoung Shim wrote: > > The gpio-bank-X header files of S3C64XX have defines which can be > substituted by more common API, so they can be removed. This is compile > tested only. > > Signed-off-by: Joonyoung Shim > Signed-off-by: Kyungmin Park > --- > arch/arm/mach-s3c64xx/dev-spi.c | 20 ++ > arch/arm/mach-s3c64xx/include/mach/gpio-bank-a.h | 48 -- > arch/arm/mach-s3c64xx/include/mach/gpio-bank-b.h | 60 - > arch/arm/mach-s3c64xx/include/mach/gpio-bank-c.h | 53 --- > arch/arm/mach-s3c64xx/include/mach/gpio-bank-d.h | 49 -- > arch/arm/mach-s3c64xx/include/mach/gpio-bank-e.h | 44 - > arch/arm/mach-s3c64xx/include/mach/gpio-bank-f.h | 71 > - > arch/arm/mach-s3c64xx/include/mach/gpio-bank-g.h | 42 > arch/arm/mach-s3c64xx/include/mach/gpio-bank-h.h | 74 > -- > arch/arm/mach-s3c64xx/include/mach/gpio-bank-i.h | 40 > arch/arm/mach-s3c64xx/include/mach/gpio-bank-j.h | 36 --- > arch/arm/mach-s3c64xx/include/mach/gpio-bank-n.h | 54 > arch/arm/mach-s3c64xx/include/mach/gpio-bank-o.h | 70 > arch/arm/mach-s3c64xx/include/mach/gpio-bank-p.h | 69 > arch/arm/mach-s3c64xx/include/mach/gpio-bank-q.h | 46 - > arch/arm/mach-s3c64xx/mach-smdk6410.c|1 - > arch/arm/mach-s3c64xx/pm.c | 34 ++- > arch/arm/mach-s3c64xx/setup-i2c0.c |7 +-- > arch/arm/mach-s3c64xx/setup-i2c1.c |7 +-- > arch/arm/mach-s3c64xx/sleep.S|8 ++- > 20 files changed, 37 insertions(+), 796 deletions(-) > delete mode 100644 arch/arm/mach-s3c64xx/include/mach/gpio-bank-a.h > delete mode 100644 arch/arm/mach-s3c64xx/include/mach/gpio-bank-b.h > delete mode 100644 arch/arm/mach-s3c64xx/include/mach/gpio-bank-c.h > delete mode 100644 arch/arm/mach-s3c64xx/include/mach/gpio-bank-d.h > delete mode 100644 arch/arm/mach-s3c64xx/include/mach/gpio-bank-e.h > delete mode 100644 arch/arm/mach-s3c64xx/include/mach/gpio-bank-f.h > delete mode 100644 arch/arm/mach-s3c64xx/include/mach/gpio-bank-g.h > delete mode 100644 arch/arm/mach-s3c64xx/include/mach/gpio-bank-h.h > delete mode 100644 arch/arm/mach-s3c64xx/include/mach/gpio-bank-i.h > delete mode 100644 arch/arm/mach-s3c64xx/include/mach/gpio-bank-j.h > delete mode 100644 arch/arm/mach-s3c64xx/include/mach/gpio-bank-n.h > delete mode 100644 arch/arm/mach-s3c64xx/include/mach/gpio-bank-o.h > delete mode 100644 arch/arm/mach-s3c64xx/include/mach/gpio-bank-p.h > delete mode 100644 arch/arm/mach-s3c64xx/include/mach/gpio-bank-q.h > Looks ok to me, will apply. 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 v4 3/3] v4l: Add v4l2 subdev driver for S5P/EXYNOS4 MIPI-CSI receivers
Hi Laurent, On 05/05/2011 02:25 PM, Laurent Pinchart wrote: > On Thursday 05 May 2011 11:33:27 Sylwester Nawrocki wrote: >> On 05/04/2011 02:00 PM, Laurent Pinchart wrote: >>> On Tuesday 03 May 2011 20:07:43 Sylwester Nawrocki wrote: On 05/03/2011 11:16 AM, Laurent Pinchart wrote: > On Thursday 21 April 2011 17:21:04 Sylwester Nawrocki wrote: >>> [snip] >>> >> +struct media_pad pads[CSIS_PADS_NUM]; >> +struct v4l2_subdev sd; >> +struct platform_device *pdev; >> +struct resource *regs_res; >> +void __iomem *regs; >> +struct clk *clock[NUM_CSIS_CLOCKS]; >> +int irq; >> +struct regulator *supply; >> +u32 flags; >> +/* Common format for the source and sink pad. */ >> +const struct csis_pix_format *csis_fmt; >> +struct v4l2_mbus_framefmt mf[CSIS_NUM_FMTS]; > > As try formats are stored in the file handle, and as the formats on the > sink and source pads are identical, a single v4l2_mbus_framefmt will do > here. Ok. How about a situation when the caller never provides a file handle? Is it not supposed to happen? >>> >>> Good question :-) The subdev pad-level operations have been designed with >>> a userspace interface in mind, so they require a file handle to store >>> try the formats (and crop rectangles). >>> For V4L2_SUBDEV_FORMAT_TRY, should set_fmt just abandon storing the format and should get_fmt just return -EINVAL when passed fh == NULL ? >>> >>> For such a simple subdev, that should work as a workaround, yes. You can >>> use it as a temporary solution at least. >>> Or should the host driver allocate the file handle just for the sake of set_fmt/get_fmt calls (assuming that cropping ops are not supported by the subdev) ? >>> >>> That's another solution. We could also pass an internal structure that >>> contains formats and crop rectangles to the pad operations handlers, >>> instead of passing the whole file handle. Do you think that would be >>> better ? >> >> So it would then be an additional argument for the pad-level operations ? > > It would replace the file handle argument. > >> Perhaps that would make sense when both format and crop information is >> needed at the same time in the subdev driver. However this would only be >> required for TRY formats/crop rectangles which wouldn't be supported anyway >> because of missing file handle.. or I missed something? > > The reason why we pass the file handle to the pad operations is to let > drivers > access formats/crop try settings that are stored in the file handle. If we > moved those settings to a separate structure, and embedded that structure > into > the file handle structure, we could pass &fh->settings instead of fh to the > pad operations. Drivers that want to call pad operations would then need to > allocate a settings structure, instead of a complete fake fh. I see, that sounds like a cleanest solution of the problem. > >> Furthermore I assume more complex pipelines will be handled in user space > > The pad-level API has been designed to get/set formats/crop settings directly > from userspace, not from inside the kernel, so that would certainly work. > >> and the host drivers could store format and crop information locally >> directly from v4l2_subdev_format and v4l2_subdev_crop data structures. > > I'm not sure to understand what you mean there. I meant that the adjusted format/crop rectangle is still returned in the pad operations, through the last argument; in struct v4l2_subdev_format::format or struct v4l2_subdev_crop::rect and these can be queried and interpreted by a host driver. But as you explain purpose of the fh is to aid subdev, not the host drivers. > >>> Quoting one of your comments below, >>> >>> x--- FIMC_0 (/dev/video1) >>> >>> SENSOR -> MIPI_CSIS --| >>> >>> x--- FIMC_1 (/dev/video3) >>> >>> How do you expect to configure the MIPI_CSIS block from the FIMC_0 and >>> FIMC_1 blocks, without any help from userspace ? Conflicts will need to >>> be handled, and the best way to handle them is to have userspace >>> configuring the MIPI_CSIS explicitly. >> >> My priority is to make work the configurations without device nodes at >> sensor and MIPI CSIS subdevs. >> >> I agree it would be best to leave the negotiation logic to user space, >> however I need to assure the regular V4L2 application also can use the >> driver. >> >> My idea was to only try format at CSI slave and sensor subdevs when S_FMT >> is called on a video node. So the sensor and CSIS constraints are taken >> into account. >> >> Then from VIDIOC_STREAMON, formats at pipeline elements would be set on >> subdevs without device node or validated on subdevs providing a device >> node. > > For subdevs without device nodes, why don't you set the active format > directly > when S_FMT is called,
Re: [PATCH v4 3/3] v4l: Add v4l2 subdev driver for S5P/EXYNOS4 MIPI-CSI receivers
Hi Sylwester, On Thursday 05 May 2011 11:33:27 Sylwester Nawrocki wrote: > On 05/04/2011 02:00 PM, Laurent Pinchart wrote: > > On Tuesday 03 May 2011 20:07:43 Sylwester Nawrocki wrote: > >> On 05/03/2011 11:16 AM, Laurent Pinchart wrote: > >>> On Thursday 21 April 2011 17:21:04 Sylwester Nawrocki wrote: > > [snip] > > > +struct media_pad pads[CSIS_PADS_NUM]; > +struct v4l2_subdev sd; > +struct platform_device *pdev; > +struct resource *regs_res; > +void __iomem *regs; > +struct clk *clock[NUM_CSIS_CLOCKS]; > +int irq; > +struct regulator *supply; > +u32 flags; > +/* Common format for the source and sink pad. */ > +const struct csis_pix_format *csis_fmt; > +struct v4l2_mbus_framefmt mf[CSIS_NUM_FMTS]; > >>> > >>> As try formats are stored in the file handle, and as the formats on the > >>> sink and source pads are identical, a single v4l2_mbus_framefmt will do > >>> here. > >> > >> Ok. How about a situation when the caller never provides a file handle? > >> Is it not supposed to happen? > > > > Good question :-) The subdev pad-level operations have been designed with > > a userspace interface in mind, so they require a file handle to store > > try the formats (and crop rectangles). > > > >> For V4L2_SUBDEV_FORMAT_TRY, should set_fmt just abandon storing the > >> format and should get_fmt just return -EINVAL when passed fh == NULL ? > > > > For such a simple subdev, that should work as a workaround, yes. You can > > use it as a temporary solution at least. > > > >> Or should the host driver allocate the file handle just for the sake of > >> set_fmt/get_fmt calls (assuming that cropping ops are not supported > >> by the subdev) ? > > > > That's another solution. We could also pass an internal structure that > > contains formats and crop rectangles to the pad operations handlers, > > instead of passing the whole file handle. Do you think that would be > > better ? > > So it would then be an additional argument for the pad-level operations ? It would replace the file handle argument. > Perhaps that would make sense when both format and crop information is > needed at the same time in the subdev driver. However this would only be > required for TRY formats/crop rectangles which wouldn't be supported anyway > because of missing file handle.. or I missed something? The reason why we pass the file handle to the pad operations is to let drivers access formats/crop try settings that are stored in the file handle. If we moved those settings to a separate structure, and embedded that structure into the file handle structure, we could pass &fh->settings instead of fh to the pad operations. Drivers that want to call pad operations would then need to allocate a settings structure, instead of a complete fake fh. > Furthermore I assume more complex pipelines will be handled in user space The pad-level API has been designed to get/set formats/crop settings directly from userspace, not from inside the kernel, so that would certainly work. > and the host drivers could store format and crop information locally > directly from v4l2_subdev_format and v4l2_subdev_crop data structures. I'm not sure to understand what you mean there. > > Quoting one of your comments below, > > > > x--- FIMC_0 (/dev/video1) > > > > SENSOR -> MIPI_CSIS --| > > > > x--- FIMC_1 (/dev/video3) > > > > How do you expect to configure the MIPI_CSIS block from the FIMC_0 and > > FIMC_1 blocks, without any help from userspace ? Conflicts will need to > > be handled, and the best way to handle them is to have userspace > > configuring the MIPI_CSIS explicitly. > > My priority is to make work the configurations without device nodes at > sensor and MIPI CSIS subdevs. > > I agree it would be best to leave the negotiation logic to user space, > however I need to assure the regular V4L2 application also can use the > driver. > > My idea was to only try format at CSI slave and sensor subdevs when S_FMT > is called on a video node. So the sensor and CSIS constraints are taken > into account. > > Then from VIDIOC_STREAMON, formats at pipeline elements would be set on > subdevs without device node or validated on subdevs providing a device > node. For subdevs without device nodes, why don't you set the active format directly when S_FMT is called, instead of postponing the operation until VIDIOC_STREAMON time ? You wouldn't need to use TRY formats then. > Another issue is v4l2 controls. The subdevs are now in my case registered > to a v4l2_device instance embedded in the media device driver. The video > node drivers (FIMC0...FIMC3) have their own v4l2_device instances. So the > control inheritance between video node and a subdevs is gone :/, i.e. I > couldn't find a standard way to remove back from a parent control handler > the con
Re: [PATCH v4 3/3] v4l: Add v4l2 subdev driver for S5P/EXYNOS4 MIPI-CSI receivers
Hi Laurent,
On 05/04/2011 02:00 PM, Laurent Pinchart wrote:
> Hi Sylwester,
>
> On Tuesday 03 May 2011 20:07:43 Sylwester Nawrocki wrote:
>> On 05/03/2011 11:16 AM, Laurent Pinchart wrote:
>>> On Thursday 21 April 2011 17:21:04 Sylwester Nawrocki wrote:
>
> [snip]
>
+ struct media_pad pads[CSIS_PADS_NUM];
+ struct v4l2_subdev sd;
+ struct platform_device *pdev;
+ struct resource *regs_res;
+ void __iomem *regs;
+ struct clk *clock[NUM_CSIS_CLOCKS];
+ int irq;
+ struct regulator *supply;
+ u32 flags;
+ /* Common format for the source and sink pad. */
+ const struct csis_pix_format *csis_fmt;
+ struct v4l2_mbus_framefmt mf[CSIS_NUM_FMTS];
>>>
>>> As try formats are stored in the file handle, and as the formats on the
>>> sink and source pads are identical, a single v4l2_mbus_framefmt will do
>>> here.
>>
>> Ok. How about a situation when the caller never provides a file handle?
>> Is it not supposed to happen?
>
> Good question :-) The subdev pad-level operations have been designed with a
> userspace interface in mind, so they require a file handle to store try the
> formats (and crop rectangles).
>
>> For V4L2_SUBDEV_FORMAT_TRY, should set_fmt just abandon storing the format
>> and should get_fmt just return -EINVAL when passed fh == NULL ?
>
> For such a simple subdev, that should work as a workaround, yes. You can use
> it as a temporary solution at least.
>
>> Or should the host driver allocate the file handle just for the sake of
>> set_fmt/get_fmt calls (assuming that cropping ops are not supported
>> by the subdev) ?
>
> That's another solution. We could also pass an internal structure that
> contains formats and crop rectangles to the pad operations handlers, instead
> of passing the whole file handle. Do you think that would be better ?
So it would then be an additional argument for the pad-level operations ?
Perhaps that would make sense when both format and crop information is
needed at the same time in the subdev driver. However this would only be
required for TRY formats/crop rectangles which wouldn't be supported anyway
because of missing file handle.. or I missed something?
Furthermore I assume more complex pipelines will be handled in user space
and the host drivers could store format and crop information locally
directly from v4l2_subdev_format and v4l2_subdev_crop data structures.
[snip]
> Quoting one of your comments below,
>
> x--- FIMC_0 (/dev/video1)
> SENSOR -> MIPI_CSIS --|
> x--- FIMC_1 (/dev/video3)
>
> How do you expect to configure the MIPI_CSIS block from the FIMC_0 and FIMC_1
> blocks, without any help from userspace ? Conflicts will need to be handled,
> and the best way to handle them is to have userspace configuring the
> MIPI_CSIS
> explicitly.
My priority is to make work the configurations without device nodes at sensor
and MIPI CSIS subdevs.
I agree it would be best to leave the negotiation logic to user space,
however I need to assure the regular V4L2 application also can use the driver.
My idea was to only try format at CSI slave and sensor subdevs when S_FMT is
called on a video node. So the sensor and CSIS constraints are taken into
account.
Then from VIDIOC_STREAMON, formats at pipeline elements would be set on subdevs
without device node or validated on subdevs providing a device node.
Another issue is v4l2 controls. The subdevs are now in my case registered
to a v4l2_device instance embedded in the media device driver. The video node
drivers (FIMC0...FIMC3) have their own v4l2_device instances. So the control
inheritance between video node and a subdevs is gone :/, i.e. I couldn't find
a standard way to remove back from a parent control handler the controls which
have been added to it with v4l2_ctrl_handler_add().
I've had similar issue with subdev -> v4l2_device notify callback. Before, when
the subdev was directly registered to a v4l2_instance associated with a video
node, v4l2_subdev_notify had been propagated straight to FIMC{N} device the
subdev
was attached to.
Now I just redirect notifications ending up in the media device driver to
relevant FIMC{N} device instance depending on link configuration.
[snip]
+#define csis_pad_valid(pad) (pad == CSIS_PAD_SOURCE || pad ==
CSIS_PAD_SINK) +
+static struct csis_state *sd_to_csis_state(struct v4l2_subdev *sdev)
+{
+ return container_of(sdev, struct csis_state, sd);
+}
+
+static const struct csis_pix_format *find_csis_format(
+ struct v4l2_mbus_framefmt *mf)
+{
+ int i = ARRAY_SIZE(s5pcsis_formats);
+
+ while (--i>= 0)
>>>
>>> I'm curious, why do you search backward instead of doing the usual
>>>
>>> for (i = 0; i< ARRAY_SIZE(s5pcsis_formats); ++i)
>>>
>>> (in that case 'i' could be unsigned) ?
>>
>> Perhaps doing it either way does not make any difference with the
>> toolchains we use, but the
