RE: [RESEND][PATCH] ARM: EXYNOS: Add clocks for EXYNOS I2S and PCM I/F
On Fri, Feb 8, 2013 at 13:23 PM, Padma Venkat padma@gmail.com wrote:
On Wed, Feb 6, 2013 at 10:51 AM, Sangsu Park sangsu4u.p...@samsung.com
wrote:
+void __init exynos_register_audss_clocks(void)
+{
+ clk_audss_base = ioremap(EXYNOS_PA_AUDSS, SZ_4K);
+ if (clk_audss_base == NULL) {
Please run checkpatch. There should be space after if.
I mistakenly forgot checking patch with checkpatch.
I can find some errors and warnings about this patch.
I'll fix them. Thank you for your comment.
+ pr_err(unable to ioremap for gpio_base1\n);
Please fix the err message.
I'll change it. :)
Thanks.
Sangsu Park
--
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] ARM: EXYNOS: Add clocks for EXYNOS I2S and PCM I/F
Audio Subsystem has own clocks for I2S0 and PCM0 in all EXYNOS series.
This patch add clocks for I2S0 and PCM0 I/F.
Signed-off-by: Sangsu Park sangsu4u.p...@samsung.com
---
arch/arm/mach-exynos/Makefile |1 +
arch/arm/mach-exynos/clock-audss.c | 68
2 files changed, 69 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-exynos/clock-audss.c
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index 7e53a3a..5b6c7c0 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -13,6 +13,7 @@ obj- :=
# Core
obj-$(CONFIG_ARCH_EXYNOS) += common.o
+obj-$(CONFIG_ARCH_EXYNOS) += clock-audss.o
obj-$(CONFIG_ARCH_EXYNOS4) += clock-exynos4.o
obj-$(CONFIG_CPU_EXYNOS4210) += clock-exynos4210.o
obj-$(CONFIG_SOC_EXYNOS4212) += clock-exynos4212.o
diff --git a/arch/arm/mach-exynos/clock-audss.c
b/arch/arm/mach-exynos/clock-audss.c
new file mode 100644
index 000..31d01c3
--- /dev/null
+++ b/arch/arm/mach-exynos/clock-audss.c
@@ -0,0 +1,68 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Clock support for EXYNOS Audio Subsystem
+ *
+ * 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 linux/kernel.h
+#include linux/err.h
+#include linux/io.h
+
+#include plat/clock.h
+#include plat/s5p-clock.h
+
+#define EXYNOS_PA_AUDSS(0x0381)
+
+/* IP Clock Gate 0 Registers */
+#define EXYNOS_AUDSS_CLKGATE_I2SBUS(12)
+#define EXYNOS_AUDSS_CLKGATE_I2SSPECIAL(13)
+#define EXYNOS_AUDSS_CLKGATE_PCMBUS(14)
+#define EXYNOS_AUDSS_CLKGATE_PCMSPECIAL(15)
+#define EXYNOS_AUDSS_CLKGATE_GPIO (16)
+
+static void __iomem *clk_audss_base;
+
+static int exynos_clk_audss_ctrl(struct clk *clk, int enable)
+{
+ if (!clk_audss_base)
+ return -ENOMEM;
+
+ return s5p_gatectrl(clk_audss_base, clk, enable);
+}
+
+static struct clk exynos_init_audss_clocks[] = {
+ {
+ .name = iis,
+ .devname= samsung-i2s.0,
+ .enable = exynos_clk_audss_ctrl,
+ .ctrlbit= EXYNOS_AUDSS_CLKGATE_I2SSPECIAL
+ | EXYNOS_AUDSS_CLKGATE_I2SBUS
+ | EXYNOS_AUDSS_CLKGATE_GPIO,
+ }, {
+ .name = pcm,
+ .devname= samsung-pcm.0,
+ .enable = exynos_clk_audss_ctrl,
+ .ctrlbit= EXYNOS_AUDSS_CLKGATE_PCMSPECIAL
+ | EXYNOS_AUDSS_CLKGATE_PCMBUS
+ | EXYNOS_AUDSS_CLKGATE_GPIO,
+ },
+};
+
+void __init exynos_register_audss_clocks(void)
+{
+ clk_audss_base = ioremap(EXYNOS_PA_AUDSS, SZ_4K);
+ if (clk_audss_base == NULL) {
+ pr_err(unable to ioremap for audss base\n);
+ return;
+ }
+
+ s3c_register_clocks(exynos_init_audss_clocks,
+ ARRAY_SIZE(exynos_init_audss_clocks));
+ s3c_disable_clocks(exynos_init_audss_clocks,
+ ARRAY_SIZE(exynos_init_audss_clocks));
+}
--
1.7.4.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
Re: [PATCH] pinctrl: samsung: remove duplicated line of samsung_pinctrl_register()
On Friday 08 of February 2013 14:39:30 Jingoo Han wrote: This patch removes duplicated line of samsung_pinctrl_register(), because the number of pins is redundantly assigned twice. Signed-off-by: Jingoo Han jg1@samsung.com --- drivers/pinctrl/pinctrl-samsung.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/pinctrl/pinctrl-samsung.c b/drivers/pinctrl/pinctrl-samsung.c index 294bcdd..3d5cf63 100644 --- a/drivers/pinctrl/pinctrl-samsung.c +++ b/drivers/pinctrl/pinctrl-samsung.c @@ -716,7 +716,6 @@ static int samsung_pinctrl_register(struct platform_device *pdev, } ctrldesc-pins = pindesc; ctrldesc-npins = drvdata-ctrl-nr_pins; - ctrldesc-npins = drvdata-ctrl-nr_pins; /* dynamically populate the pin number and pin name for pindesc */ for (pin = 0, pdesc = pindesc; pin ctrldesc-npins; pin++, pdesc++) Reviewed-by: Tomasz Figa t.f...@samsung.com Best regards, -- Tomasz Figa Samsung Poland RD Center SW Solution Development, Linux Platform -- 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 PATCH 0/4] Common Display Framework-TF
Hi,
On 2013-02-03 21:17, Tomasz Figa wrote:
Hi Laurent,
On Saturday 02 of February 2013 11:39:59 Laurent Pinchart wrote:
Hi Tomasz,
Thank you for your RFC.
On Wednesday 30 January 2013 16:38:59 Tomasz Figa wrote:
Changes done to Tomi's edition of CDF:
- Replaced set_operation_mode, set_pixel_format and set_size video
source
operations with get_params display entity operation, as it was
originally in Laurent's version.
We have discussed this matter on the mailing list and decided that
it
would be better to have the source ask the sink for its parameter
structure and do whatever appropriate with it.
Could you briefly outline the rationale behind this ?
Display interfaces may be described by an arbitrary number of parameters.
Some will require just video timings, others like DSI will require a
significant number of additional bus-specific ones.
Separating all the parameters (all of which are usually set at the same
time) into a lot of ops setting single parameter will just add unnecessary
complexity.
I have nothing against combining the parameters that way. I think the
important thing here is just that we have to allow changing of the
parameters, whenever the display device needs that. So the bus
parameters cannot be a one time constant setting.
I'm wondering whether get_params could limit us if a device needs to
modify parameters at runtime. For instance a panel might need to change
clock frequencies or number of used data lane depending on various
runtime conditions. I don't have a real use case here, so it might just
be a bit of over-engineering.
Hmm, isn't it in the opposite direction (the user requests the display
interface to change, for example, video mode, which in turn reconfigures
the link and requests the panel to update its settings)?
Well, now, that's the question.
Let's consider a simplified case with DSI output from the SoC, and a DSI
panel. If the panel is a rather simple one, you could well call a method
in the API in the DSI output driver, which would do necessary
configuration and inform the panel driver to do any configuration it
needs to do, based on the parameters.
However, in my experience display devices, DSI devices in particular,
are often quite interesting. If the control of the operation in
question is in the DSI output side, we are limited about what kind of
DSI panels we can use, as the DSI output driver has to know all the
tricks needed to make the panels work.
I'm having hard time trying to explain this, so let's try an example.
Consider the initial powering up of the bus. If the DSI output driver is
in control, something like the following probably happens:
- output driver asks for the parameters from the panel driver
- output driver programs the DSI output according to these parameters
- output driver informs the panel that the bus is now up and running
Then consider a totally invented case, but which perhaps describes the
problem with the above approach: The DSI panel requires the DSI bus
first to be started in HS mode, but with a certain predefined bus speed,
and only one lane used. This predefined bus setup is used to send
configuration commands to the panel hardware, and only after that can
you reconfigure the bus with proper speed and lanes.
That kind of thing is a bit difficult to manage with the DSI output
driver is in control. However, if the DSI panel driver is in control,
it's simple:
- panel driver calls config methods in the DSI output driver, setting
the predefined speed and one lane
- panel driver sends configuration commands to the panel
- panel driver calls config methods in the DSI output driver, setting
the final bus config
5. Mask of used data lanes (each bit represents single lane).
From my experience with MIPI CSI (Camera Serial Interface, similar to
DSI) some transceivers can reroute data lanes internally. Is that true
for DSI as well ? In that case we would need a list of data lanes, not
just a mask.
Hmm, I don't remember at the moment, will have to look to the
specification. Exynos DSI master doesn't support such feature.
In OMAP you can configure the DSI pins quite freely. We have the
following struct:
struct omap_dsi_pin_config {
int num_pins;
/*
* pin numbers in the following order:
* clk+, clk-
* data1+, data1-
* data2+, data2-
* ...
*/
int pins[OMAP_DSS_MAX_DSI_PINS];
};
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [RFC PATCH 0/4] Common Display Framework-TF
On 02/08/2013 12:40 PM, Tomi Valkeinen wrote:
Hi,
On 2013-02-03 21:17, Tomasz Figa wrote:
Hi Laurent,
On Saturday 02 of February 2013 11:39:59 Laurent Pinchart wrote:
Hi Tomasz,
Thank you for your RFC.
On Wednesday 30 January 2013 16:38:59 Tomasz Figa wrote:
Changes done to Tomi's edition of CDF:
- Replaced set_operation_mode, set_pixel_format and set_size video
source
operations with get_params display entity operation, as it was
originally in Laurent's version.
We have discussed this matter on the mailing list and decided that
it
would be better to have the source ask the sink for its parameter
structure and do whatever appropriate with it.
Could you briefly outline the rationale behind this ?
Display interfaces may be described by an arbitrary number of parameters.
Some will require just video timings, others like DSI will require a
significant number of additional bus-specific ones.
Separating all the parameters (all of which are usually set at the same
time) into a lot of ops setting single parameter will just add unnecessary
complexity.
I have nothing against combining the parameters that way. I think the
important thing here is just that we have to allow changing of the
parameters, whenever the display device needs that. So the bus
parameters cannot be a one time constant setting.
I agree, but I think it should be
setup-enable-video_on-video_off-disable-setup-...
I don't think there is any interface parameters that should be changed
while link is enabled. And if there are, they should be identified and
split out into a separate operation.
I'm wondering whether get_params could limit us if a device needs to
modify parameters at runtime. For instance a panel might need to change
clock frequencies or number of used data lane depending on various
runtime conditions. I don't have a real use case here, so it might just
be a bit of over-engineering.
Hmm, isn't it in the opposite direction (the user requests the display
interface to change, for example, video mode, which in turn reconfigures
the link and requests the panel to update its settings)?
Well, now, that's the question.
Let's consider a simplified case with DSI output from the SoC, and a DSI
panel. If the panel is a rather simple one, you could well call a method
in the API in the DSI output driver, which would do necessary
configuration and inform the panel driver to do any configuration it
needs to do, based on the parameters.
However, in my experience display devices, DSI devices in particular,
are often quite interesting. If the control of the operation in
question is in the DSI output side, we are limited about what kind of
DSI panels we can use, as the DSI output driver has to know all the
tricks needed to make the panels work.
I'm having hard time trying to explain this, so let's try an example.
Consider the initial powering up of the bus. If the DSI output driver is
in control, something like the following probably happens:
- output driver asks for the parameters from the panel driver
- output driver programs the DSI output according to these parameters
- output driver informs the panel that the bus is now up and running
Then consider a totally invented case, but which perhaps describes the
problem with the above approach: The DSI panel requires the DSI bus
first to be started in HS mode, but with a certain predefined bus speed,
and only one lane used. This predefined bus setup is used to send
configuration commands to the panel hardware, and only after that can
you reconfigure the bus with proper speed and lanes.
That kind of thing is a bit difficult to manage with the DSI output
driver is in control. However, if the DSI panel driver is in control,
it's simple:
- panel driver calls config methods in the DSI output driver, setting
the predefined speed and one lane
- panel driver sends configuration commands to the panel
- panel driver calls config methods in the DSI output driver, setting
the final bus config
We have similar use cases and so I agree (and have implemented) the
latter approach where panel driver is in control. I think it is
important to separate the panel calling dispc (which it should not) from
panel calling bus/videosource ops. Compare to I2C, no one would expect
panel to call dispc to do I2C ops, instead panel call bus ops directly
in response to the CDF ops request panel is running.
5. Mask of used data lanes (each bit represents single lane).
From my experience with MIPI CSI (Camera Serial Interface, similar to
DSI) some transceivers can reroute data lanes internally. Is that true
for DSI as well ? In that case we would need a list of data lanes, not
just a mask.
Hmm, I don't remember at the moment, will have to look to the
specification. Exynos DSI master doesn't support such feature.
In OMAP you can configure the DSI pins quite freely. We have the
following struct:
struct omap_dsi_pin_config {
int num_pins;
/*
* pin
[PATCH] ARM: S5PV210: Fix early uart output in fifo mode
Enabling UART FIFO in bootloader caused the kernel infinite
loop on S5PV210 due to uninitialized fifo_max and fifo_mask global
variables. This patch adds the correct initialization.
Signed-off-by: Alexey Galakhov agalak...@gmail.com
---
arch/arm/mach-s5pv210/include/mach/uncompress.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-s5pv210/include/mach/uncompress.h
b/arch/arm/mach-s5pv210/include/mach/uncompress.h
index 08ff2fd..ef977ea 100644
--- a/arch/arm/mach-s5pv210/include/mach/uncompress.h
+++ b/arch/arm/mach-s5pv210/include/mach/uncompress.h
@@ -19,6 +19,8 @@
static void arch_detect_cpu(void)
{
/* we do not need to do any cpu detection here at the moment. */
+ fifo_mask = S5PV210_UFSTAT_TXMASK;
+ fifo_max = 63 S5PV210_UFSTAT_TXSHIFT;
}
#endif /* __ASM_ARCH_UNCOMPRESS_H */
--
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: [RFC PATCH 0/4] Common Display Framework-TF
On 2013-02-08 14:40, Marcus Lorentzon wrote:
I agree, but I think it should be
setup-enable-video_on-video_off-disable-setup-...
I don't think there is any interface parameters that should be changed
while link is enabled. And if there are, they should be identified and
split out into a separate operation.
Hmm. At least on OMAP and DSI video mode, it is possible to change at
least timings on the fly. But yes, generally the link has to be disabled
first before changing any parameters.
In OMAP you can configure the DSI pins quite freely. We have the
following struct:
struct omap_dsi_pin_config {
int num_pins;
/*
* pin numbers in the following order:
* clk+, clk-
* data1+, data1-
* data2+, data2-
* ...
*/
int pins[OMAP_DSS_MAX_DSI_PINS];
};
Do you reroute after boot? Or is this just board/product setup. We
have some pinmuxing as well and DPhy sharing, but we have never used it
after init/boot. If not runtime, I think this could be put in DT config
for product instead of under dynamic control from panel.
The pin config with the struct above is done later, when the panel
driver configures the DSI bus. So in OMAP we have two distinct things
that need to be configured:
- The actual pin muxing, i.e. selecting the functions for pin N on the
OMAP package. The functions for a single pin could be for example GPIO
70, DSI DX0, UART1_CTS, etc. This is normally done once during board init.
- DSI pin configuration in the display subsystem. This is used to map
the pins to DSI functions. I.e. DSI DX0 pin is mapped to DATA1+. This is
done by the DSS driver, when the panel driver gives it the parameters.
So the first muxing basically assigns the pin to DSI in general, and
then DSI will internally route the pin to a an actual DSI function.
Whether the muxing needs to changed during runtime... I'm not sure. On
OMAP the DSI pin config also tells how many lanes are used. So if a DSI
panel would first want to use only one lane, and later change it to n
lanes, we'd need this kind of function.
I think it conceptually fits better if the pin config data is passed to
the panel via DT data, and the panel then gives the config to the DSI
master. It's just a part of the DSI bus parameters, like, say, clock
speed or whether to use HS or LP. That way the DT node for the panel
contains the information about the panel. (versus having pin config data
in the DSI master, in which case the DSI master's node contains data
about a specific DSI panel).
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [RFC PATCH 0/4] Common Display Framework-TF
On 02/08/2013 02:04 PM, Tomi Valkeinen wrote:
On 2013-02-08 14:40, Marcus Lorentzon wrote:
I agree, but I think it should be
setup-enable-video_on-video_off-disable-setup-...
I don't think there is any interface parameters that should be changed
while link is enabled. And if there are, they should be identified and
split out into a separate operation.
Hmm. At least on OMAP and DSI video mode, it is possible to change at
least timings on the fly. But yes, generally the link has to be disabled
first before changing any parameters.
When we do that we stop-setup-start during blanking. So our DSS is
optimized to be able to do that without getting blocked. All DSI video
mode panels (and DPI) products we have done so far have not had any
issue with that (as long as DSI HS clock is set to continuous). I think
this approach is less platform dependant, as long as there is no SoC
that take more than a blanking period to reconfigure.
In OMAP you can configure the DSI pins quite freely. We have the
following struct:
struct omap_dsi_pin_config {
int num_pins;
/*
* pin numbers in the following order:
* clk+, clk-
* data1+, data1-
* data2+, data2-
* ...
*/
int pins[OMAP_DSS_MAX_DSI_PINS];
};
Do you reroute after boot? Or is this just board/product setup. We
have some pinmuxing as well and DPhy sharing, but we have never used it
after init/boot. If not runtime, I think this could be put in DT config
for product instead of under dynamic control from panel.
The pin config with the struct above is done later, when the panel
driver configures the DSI bus. So in OMAP we have two distinct things
that need to be configured:
- The actual pin muxing, i.e. selecting the functions for pin N on the
OMAP package. The functions for a single pin could be for example GPIO
70, DSI DX0, UART1_CTS, etc. This is normally done once during board init.
- DSI pin configuration in the display subsystem. This is used to map
the pins to DSI functions. I.e. DSI DX0 pin is mapped to DATA1+. This is
done by the DSS driver, when the panel driver gives it the parameters.
So the first muxing basically assigns the pin to DSI in general, and
then DSI will internally route the pin to a an actual DSI function.
Whether the muxing needs to changed during runtime... I'm not sure. On
OMAP the DSI pin config also tells how many lanes are used. So if a DSI
panel would first want to use only one lane, and later change it to n
lanes, we'd need this kind of function.
I think it conceptually fits better if the pin config data is passed to
the panel via DT data, and the panel then gives the config to the DSI
master. It's just a part of the DSI bus parameters, like, say, clock
speed or whether to use HS or LP. That way the DT node for the panel
contains the information about the panel. (versus having pin config data
in the DSI master, in which case the DSI master's node contains data
about a specific DSI panel).
I think it still is OMAP specifics and doesn't belong in the panel
drivers any longer. If you revisit this requirement in the CDF context
where DSI ifc parameters should describe how to interface with a panel
outside the SoC, there can't really be any dependencies on SoC internal
routing. As you say, this is inside pinmux, so how can that affect the
SoC external interface? I would suggest moving this to dispc-dsilink DT
settings that are activated on dsilink-enable/disable. At least that is
how I plan to solve similar STE SoC specific DSI config settings that
are not really CDF panel generic, like some DPhy trim settings. They do
depend on the panel and clock speed, but they are more product specific
than panel driver specific. Then if there are these type of settings
that every SoC have, then we could look at standardize those. But for
starters I would try to keep it in product/board-DT per DSI link. So we
should try to differentiate between DSI host and slave bus params and
keep slave params in panel driver.
/BR
/Marcus
--
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 PATCH 0/4] Common Display Framework-TF
On 2013-02-08 15:28, Marcus Lorentzon wrote:
When we do that we stop-setup-start during blanking. So our DSS is
optimized to be able to do that without getting blocked. All DSI video
mode panels (and DPI) products we have done so far have not had any
issue with that (as long as DSI HS clock is set to continuous). I think
this approach is less platform dependant, as long as there is no SoC
that take more than a blanking period to reconfigure.
So do you stop, setup and start the link with CPU, and this has to be
happen during blanking? Isn't that prone to errors? Or did you mean that
the hardware handles that automatically?
In OMAP DSS there are so called shadow registers, that can be programmed
at any time. The you set a bit (GO bit), which tells the hardware to
take the new settings into use at the next vblank.
From DSI driver's perspective the link is never stopped when
reconfiguring the video timings. However, many other settings have to be
configured when the link is disabled.
In OMAP you can configure the DSI pins quite freely. We have the
following struct:
struct omap_dsi_pin_config {
int num_pins;
/*
* pin numbers in the following order:
* clk+, clk-
* data1+, data1-
* data2+, data2-
* ...
*/
int pins[OMAP_DSS_MAX_DSI_PINS];
};
I think it still is OMAP specifics and doesn't belong in the panel
drivers any longer. If you revisit this requirement in the CDF context
where DSI ifc parameters should describe how to interface with a panel
outside the SoC, there can't really be any dependencies on SoC internal
routing. As you say, this is inside pinmux, so how can that affect the
SoC external interface? I would suggest moving this to dispc-dsilink DT
settings that are activated on dsilink-enable/disable. At least that is
how I plan to solve similar STE SoC specific DSI config settings that
are not really CDF panel generic, like some DPhy trim settings. They do
depend on the panel and clock speed, but they are more product specific
than panel driver specific. Then if there are these type of settings
that every SoC have, then we could look at standardize those. But for
starters I would try to keep it in product/board-DT per DSI link. So we
should try to differentiate between DSI host and slave bus params and
keep slave params in panel driver.
Ok, I think I was being a bit vague here. I explained the OMAP DSI
routing not because I meant that this API is specific to that, but
because it explains why this kind of routing info is needed, and a
bitmask is not enough.
If you look at the omap_dsi_pin_config struct, there's nothing OMAP
specific there (except the names =). All it tells is that this device
uses N DSI pins, and the device's clk+ function should be connected to
pin X on the DSI master, clk- should be connected to pin Y, etc. X and Y
are integers, and what they mean is specific to the DSI master.
When the DSI master is OMAP's DSI, the OMAP DSI driver does the pin
configuration as I explained. When the DSI master is something else,
say, a DSI bridge, it does whatever it needs to do (which could be
nothing) to assign a particular DSI function to a pin.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [RFC PATCH 0/4] Common Display Framework-TF
On 02/08/2013 03:02 PM, Tomi Valkeinen wrote:
On 2013-02-08 15:28, Marcus Lorentzon wrote:
When we do that we stop-setup-start during blanking. So our DSS is
optimized to be able to do that without getting blocked. All DSI video
mode panels (and DPI) products we have done so far have not had any
issue with that (as long as DSI HS clock is set to continuous). I think
this approach is less platform dependant, as long as there is no SoC
that take more than a blanking period to reconfigure.
So do you stop, setup and start the link with CPU, and this has to be
happen during blanking? Isn't that prone to errors? Or did you mean that
the hardware handles that automatically?
In OMAP DSS there are so called shadow registers, that can be programmed
at any time. The you set a bit (GO bit), which tells the hardware to
take the new settings into use at the next vblank.
From DSI driver's perspective the link is never stopped when
reconfiguring the video timings. However, many other settings have to be
configured when the link is disabled.
Yeah, you lucky guys with the GO bit ;). No, we actually do CPU
stop,setup,start. But since it is video mode, master is driving the sync
so it is not a hard deadline. It is enough to restart before pixels
start to degrade. On an LCD that is not so much time, but on an OLED it
could be 10 secs :). Anyway, we have had several mass products with this
soft solution and it has worked well.
In OMAP you can configure the DSI pins quite freely. We have the
following struct:
struct omap_dsi_pin_config {
int num_pins;
/*
* pin numbers in the following order:
* clk+, clk-
* data1+, data1-
* data2+, data2-
* ...
*/
int pins[OMAP_DSS_MAX_DSI_PINS];
};
I think it still is OMAP specifics and doesn't belong in the panel
drivers any longer. If you revisit this requirement in the CDF context
where DSI ifc parameters should describe how to interface with a panel
outside the SoC, there can't really be any dependencies on SoC internal
routing. As you say, this is inside pinmux, so how can that affect the
SoC external interface? I would suggest moving this to dispc-dsilink DT
settings that are activated on dsilink-enable/disable. At least that is
how I plan to solve similar STE SoC specific DSI config settings that
are not really CDF panel generic, like some DPhy trim settings. They do
depend on the panel and clock speed, but they are more product specific
than panel driver specific. Then if there are these type of settings
that every SoC have, then we could look at standardize those. But for
starters I would try to keep it in product/board-DT per DSI link. So we
should try to differentiate between DSI host and slave bus params and
keep slave params in panel driver.
Ok, I think I was being a bit vague here. I explained the OMAP DSI
routing not because I meant that this API is specific to that, but
because it explains why this kind of routing info is needed, and a
bitmask is not enough.
If you look at the omap_dsi_pin_config struct, there's nothing OMAP
specific there (except the names =). All it tells is that this device
uses N DSI pins, and the device's clk+ function should be connected to
pin X on the DSI master, clk- should be connected to pin Y, etc. X and Y
are integers, and what they mean is specific to the DSI master.
When the DSI master is OMAP's DSI, the OMAP DSI driver does the pin
configuration as I explained. When the DSI master is something else,
say, a DSI bridge, it does whatever it needs to do (which could be
nothing) to assign a particular DSI function to a pin.
I understand, but removing the omap prefix doesn't mean it has to go in
the panel slave port/bus settings. I still can't see why this should be
configuration on the panel driver and not the DSI master driver. Number
of pins might be useful since you might start with one lane and then
activate the rest. But partial muxing (pre pinmux) doesn't seem to be
something the panel should control or know anything about. Sounds like
normal platform/DT data per product/board.
/BR
/Marcus
--
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 3/3] dts: Add cpufreq controller node for Exynos5440 SoC
On 8 February 2013 00:03, amit kachhap amit.kach...@gmail.com wrote:
On Wed, Feb 6, 2013 at 8:49 PM, Inderpal Singh
inderpal.si...@linaro.org wrote:
On 7 February 2013 01:09, Amit Daniel Kachhap amit.dan...@samsung.com
wrote:
Add cpufreq controller device node for Exynos5440 SoC for passing
parameters like controller base address, interrupt and cpufreq
table.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
arch/arm/boot/dts/exynos5440.dtsi |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5440.dtsi
b/arch/arm/boot/dts/exynos5440.dtsi
index 024269d..b20b517 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -63,6 +63,15 @@
};
+ cpufreq@16 {
+ compatible = samsung,exynos5440-cpufreq;
+ reg = 0x16 0x1000;
+ interrupts = 0 57 0;
+ cpufreq_tbl = 120 1025000
+ 100 975000
+ 80 925000 ;
+ };
+
I think cpufreq_tbl should be part of the cpu node as it's the
property of the cpu.
Please refer cpufreq-cpu0 and spear-cpufreq.
http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/15364.
In this thread same discussion followed. I am not sure what is the
correct way but looks like Kukjin concluded this with a timer node
separate from the CPU code.
I am only talking about cpufreq_tbl and its nothing but operating
points for the cpus. It seems its agreed upon to add operating-points
to cpu node as being done by all other platforms like imx6q, am33xx,
cpufreq-cpu0 and spear.
Thanks,
Inder
Thanks,
Amit Daniel
serial@B {
compatible = samsung,exynos4210-uart;
reg = 0xB 0x1000;
--
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
--
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
--
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 v3 1/2] ARM: Exynos5250: Enabling ehci-s5p driver
On Fri, 21 Dec 2012 10:13:50 -0800, Doug Anderson diand...@chromium.org wrote:
Vivek,
On Fri, Dec 21, 2012 at 12:16 AM, Vivek Gautam
gautamvivek1...@gmail.com wrote:
Hi all,
On Wed, Dec 19, 2012 at 7:20 PM, Vivek Gautam gautamvivek1...@gmail.com
wrote:
CC: Doug Anderson
On Sat, Dec 15, 2012 at 12:53 PM, Grant Likely
grant.lik...@secretlab.ca wrote:
On Thu, 13 Dec 2012 22:06:01 +0530, Vivek Gautam
gautam.vi...@samsung.com wrote:
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index 462e5ac..b3b9af1 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -110,6 +110,8 @@ static const struct of_dev_auxdata
exynos5250_auxdata_lookup[] __initconst = {
samsung-i2s.1, NULL),
OF_DEV_AUXDATA(samsung,samsung-i2s, 0x12D7,
samsung-i2s.2, NULL),
+ OF_DEV_AUXDATA(samsung,exynos4210-ehci, EXYNOS5_PA_EHCI,
+ s5p-ehci, NULL),
I'm assuming the above change is temporary. What is left to be done to
drop the auxdata in theses two patches?
Otherwise the patch looks fine.
Acked-by: Grant Likely grant.lik...@secretlab.ca
Any more thought about this patch?
Or does this change seems fine?
I'm fairly certain we can just drop the OF_DEV_AUXDATA entry here. I
haven't been following this as closely as I should, but I know that
the comment for this table says that the whole purpose is to override
device names and that it should be temporary. We don't need to do any
overriding of device names here, do we?
When I drop this (and the ohci and phy) entries from my table I can
still boot and still can use USB. The big difference is what shows up
in dmesg
[1.605000] s5p-ehci s5p-ehci: S5P EHCI Host Controller
Becomes:
[1.55] s5p-ehci 1211.usb: S5P EHCI Host Controller
...and some sysfs paths change.
Right. Drop the AUXDATA then. :-)
g.
--
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] mmc: s3cmci: moved mach/regs-sdi.h into s3cmci device driver
Kukjin Kim wrote: Sylwester Nawrocki wrote: Hi, Hi, On 02/02/2013 01:45 AM, Kukjin Kim wrote: Since mach/regs-sdi.h is used only for s3cmci.c, so this moves the header file into the driver file, drivers/mmc/host/s3cmci.c file. Signed-off-by: Kukjin Kimkgene@samsung.com FIW, I have tested this patch on mini2440 board: Tested-by: Sylwester Nawrocki sylvester.nawro...@gmail.com Sylwester, thanks for your test :-) Chris, if you're ok on this, please take this in your tree. Or if you want, let me pick this up in Samsung tree. Applied into Samsung tree, thanks. - Kukjin -- 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 01/10] s5p-csis: Add device tree support
On 02/07/2013 12:36 AM, Stephen Warren wrote: On 02/01/2013 12:09 PM, Sylwester Nawrocki wrote: s5p-csis is platform device driver for MIPI-CSI frontend to the FIMC device. This patch support for binding the driver to the MIPI-CSIS devices instantiated from device tree and for parsing all SoC and board specific properties. diff --git a/Documentation/devicetree/bindings/media/soc/samsung-mipi-csis.txt b/Documentation/devicetree/bindings/media/soc/samsung-mipi-csis.txt +Optional properties: + +- clock-frequency : The IP's main (system bus) clock frequency in Hz, default + value when this property is not specified is 166 MHz; Shouldn't this be a clocks property, so that the driver can call clk_get(), clk_prepare_enable(), clk_get_rate(), etc. on it? Hi Stephen, Thanks for your review! I also use clocks and clock-names property, but didn't specify it here, because the Exynos SoCs clocks driver is not in the mainline yet. There are two clocks the driver needs to be aware of. One of them needs to have a specific parent clock set and the frequency set properly, so when it is put into a data pipeline with other IPs there is no overflows of their input/output FIFOs. devfreq may change those frequencies if enabled, however its another topic. I wanted to ensure the device has initially correct local clock frequency set, with which it can operate. -- Thanks, Sylwester -- 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 v5 1/4] ARM: Exynos5250: Enabling ehci-s5p driver
Vivek Gautam wrote:
Adding EHCI device tree node for Exynos5250 along with
the device base adress and gpio line for vbus.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Acked-by: Jingoo Han jg1@samsung.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
Changes from v4:
- Added gpio line for VBUS of USB2.0 on snow board.
.../devicetree/bindings/usb/exynos-usb.txt | 25
arch/arm/boot/dts/exynos5250-smdk5250.dts |4 +++
arch/arm/boot/dts/exynos5250-snow.dts |4 +++
arch/arm/boot/dts/exynos5250.dtsi |6
4 files changed, 39 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/exynos-
usb.txt
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
new file mode 100644
index 000..e8bbb47
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -0,0 +1,25 @@
+Samsung Exynos SoC USB controller
+
+The USB devices interface with USB controllers on Exynos SOCs.
+The device node has following properties.
+
+EHCI
+Required properties:
+ - compatible: should be samsung,exynos4210-ehci for USB 2.0
+ EHCI controller in host mode.
+ - reg: physical base address of the controller and length of memory
mapped
+ region.
+ - interrupts: interrupt number to the cpu.
+
+Optional properties:
+ - samsung,vbus-gpio: if present, specifies the GPIO that
+ needs to be pulled up for the bus to be powered.
+
+Example:
+
+ usb@1211 {
+ compatible = samsung,exynos4210-ehci;
+ reg = 0x1211 0x100;
+ interrupts = 0 71 0;
+ samsung,vbus-gpio = gpx2 6 1 3 3;
+ };
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 942d576..7363e14 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -204,4 +204,8 @@
samsung,mfc-r = 0x4300 0x80;
samsung,mfc-l = 0x5100 0x80;
};
+
+ usb@1211 {
+ samsung,vbus-gpio = gpx2 6 1 3 3;
+ };
};
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index 17dd951..47b6b84 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -40,4 +40,8 @@
gpc4 5 2 3 0, gpc4 6 2 3 0;
};
};
+
+ usb@1211 {
+ samsung,vbus-gpio = gpx1 1 1 3 3;
+ };
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 30485de..2cbe53e 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -275,6 +275,12 @@
#size-cells = 0;
};
+ usb@1211 {
+ compatible = samsung,exynos4210-ehci;
+ reg = 0x1211 0x100;
+ interrupts = 0 71 0;
+ };
+
amba {
#address-cells = 1;
#size-cells = 1;
--
1.7.6.5
Looks good to me and applied this and [PATCH v3 2/4] ARM: Exynos5250:
Enabling ohci-exynos driver in Samsung tree.
Note, I think, you need to implement to use pinctrl for this instead of old
gpio bindings next time, probably after release v3.9-rc1.
Ah, one more, please use subject lines appropriate like others, ARM: dts:
.
Thanks.
- Kukjin
--
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 RESEND v2] ARM: EXYNOS: dts: Set up power domain for MFC and G-scaler
Prasanna Kumar wrote:
This patch adds device tree nodes for MFC and G-scaler power
domains of exynos5250.It binds these power-domain nodes to repsective
device tree nodes
It also adds support to enable PM generic domains for exynos5250.
Signed-off-by: Prasanna Kumar prasanna...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi | 16
arch/arm/mach-exynos/Kconfig |1 +
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 30485de..e282fde 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -46,6 +46,16 @@
i2c8 = i2c_8;
};
+ pd_gsc: gsc-power-domain@0x10044000 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x10044000 0x20;
+ };
+
+ pd_mfc: mfc-power-domain@0x10044040 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x10044040 0x20;
+ };
+
gic:interrupt-controller@10481000 {
compatible = arm,cortex-a9-gic;
#interrupt-cells = 3;
@@ -85,6 +95,7 @@
compatible = samsung,mfc-v6;
reg = 0x1100 0x1;
interrupts = 0 96 0;
+ samsung,power-domain = pd_mfc;
};
rtc {
@@ -554,28 +565,33 @@
};
};
+
gsc_0: gsc@0x13e0 {
compatible = samsung,exynos5-gsc;
reg = 0x13e0 0x1000;
interrupts = 0 85 0;
+ samsung,power-domain = pd_gsc;
};
gsc_1: gsc@0x13e1 {
compatible = samsung,exynos5-gsc;
reg = 0x13e1 0x1000;
interrupts = 0 86 0;
+ samsung,power-domain = pd_gsc;
};
gsc_2: gsc@0x13e2 {
compatible = samsung,exynos5-gsc;
reg = 0x13e2 0x1000;
interrupts = 0 87 0;
+ samsung,power-domain = pd_gsc;
};
gsc_3: gsc@0x13e3 {
compatible = samsung,exynos5-gsc;
reg = 0x13e3 0x1000;
interrupts = 0 88 0;
+ samsung,power-domain = pd_gsc;
};
hdmi {
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-
exynos/Kconfig
index e103c29..96f4a9f 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -61,6 +61,7 @@ config SOC_EXYNOS5250
bool SAMSUNG EXYNOS5250
default y
depends on ARCH_EXYNOS5
+ select PM_GENERIC_DOMAINS if PM
select S5P_PM if PM
select S5P_SLEEP if PM
select S5P_DEV_MFC
--
1.7.5.4
Looks OK to me, applied.
Thanks.
- Kukjin
--
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] pinctrl: samsung: remove duplicated line of samsung_pinctrl_register()
Jingoo Han wrote: This patch removes duplicated line of samsung_pinctrl_register(), because the number of pins is redundantly assigned twice. Signed-off-by: Jingoo Han jg1@samsung.com Acked-by: Kukjin Kim kgene@samsung.com Thanks. - Kukjin --- drivers/pinctrl/pinctrl-samsung.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/pinctrl/pinctrl-samsung.c b/drivers/pinctrl/pinctrl- samsung.c index 294bcdd..3d5cf63 100644 --- a/drivers/pinctrl/pinctrl-samsung.c +++ b/drivers/pinctrl/pinctrl-samsung.c @@ -716,7 +716,6 @@ static int samsung_pinctrl_register(struct platform_device *pdev, } ctrldesc-pins = pindesc; ctrldesc-npins = drvdata-ctrl-nr_pins; - ctrldesc-npins = drvdata-ctrl-nr_pins; /* dynamically populate the pin number and pin name for pindesc */ for (pin = 0, pdesc = pindesc; pin ctrldesc-npins; pin++, pdesc++) -- 1.7.2.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: [PATCH] ARM: S3C24XX: osiris: add missing platform_device.h include
Heiko Stübner wrote: The missing include led to a implcit declaration warning. Yes, this fixes following: In file included from arch/arm/mach-s3c24xx/mach-osiris.c:34:0: include/linux/platform_data/i2c-s3c2410.h:37:26: warning: 'struct platform_device' declared inside parameter list [enabled by default] include/linux/platform_data/i2c-s3c2410.h:37:26: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default] include/linux/platform_data/i2c-s3c2410.h:66:38: warning: 'struct platform_device' declared inside parameter list [enabled by default] include/linux/platform_data/i2c-s3c2410.h:67:38: warning: 'struct platform_device' declared inside parameter list [enabled by default] include/linux/platform_data/i2c-s3c2410.h:68:38: warning: 'struct platform_device' declared inside parameter list [enabled by default] include/linux/platform_data/i2c-s3c2410.h:69:38: warning: 'struct platform_device' declared inside parameter list [enabled by default] include/linux/platform_data/i2c-s3c2410.h:70:38: warning: 'struct platform_device' declared inside parameter list [enabled by default] include/linux/platform_data/i2c-s3c2410.h:71:38: warning: 'struct platform_device' declared inside parameter list [enabled by default] include/linux/platform_data/i2c-s3c2410.h:72:38: warning: 'struct platform_device' declared inside parameter list [enabled by default] include/linux/platform_data/i2c-s3c2410.h:73:38: warning: 'struct platform_device' declared inside parameter list [enabled by default] Applied with adding fixed warning message. Thanks. - Kukjin Signed-off-by: Heiko Stuebner he...@sntech.de --- arch/arm/mach-s3c24xx/mach-osiris.c |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-s3c24xx/mach-osiris.c b/arch/arm/mach- s3c24xx/mach-osiris.c index c2dc032..7d73626 100644 --- a/arch/arm/mach-s3c24xx/mach-osiris.c +++ b/arch/arm/mach-s3c24xx/mach-osiris.c @@ -21,6 +21,7 @@ #include linux/clk.h #include linux/i2c.h #include linux/io.h +#include linux/platform_device.h #include linux/i2c/tps65010.h -- 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 1/1] ARM: dts: Add s5m8767 PMIC node to exynos4412-origen.dts
Sachin Kamat wrote: Added s5m8767 PMIC node to exynos4412-origen DT file. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- This patch is created against for-next branch of Kukjin Kim's tree. This patch is added on top of the following patch: http://www.spinics.net/lists/linux-samsung-soc/msg15423.html and based on the below patch: http://comments.gmane.org/gmane.linux.kernel/1434801 --- arch/arm/boot/dts/exynos4412-origen.dts | 330 +++ 1 files changed, 330 insertions(+), 0 deletions(-) Applied, thanks. - Kukjin -- 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: S3C24XX: let S3C2412_PM select S3C2412_PM_SLEEP
Heiko Stübner wrote: The code to enter sleep is used by both the s3c2412 and s3c2416 and was thus factored out into an extra config option. But it seems it was forgotten to add the appropriate select to the s3c2412 pm option, resulting in breakage when only compiling s3c2412 support. Signed-off-by: Heiko Stuebner he...@sntech.de --- arch/arm/mach-s3c24xx/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach- s3c24xx/Kconfig index 5e17e1d..ac61bb7 100644 --- a/arch/arm/mach-s3c24xx/Kconfig +++ b/arch/arm/mach-s3c24xx/Kconfig @@ -301,6 +301,7 @@ config S3C2412_DMA config S3C2412_PM bool + select S3C2412_PM_SLEEP help Internal config node to apply S3C2412 power management -- 1.7.10.4 Looks good to me, applied. Thanks - Kukjin -- 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: S5PV210: Fix early uart output in fifo mode
Alexey Galakhov wrote:
Enabling UART FIFO in bootloader caused the kernel infinite
loop on S5PV210 due to uninitialized fifo_max and fifo_mask global
variables. This patch adds the correct initialization.
Signed-off-by: Alexey Galakhov agalak...@gmail.com
---
arch/arm/mach-s5pv210/include/mach/uncompress.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-s5pv210/include/mach/uncompress.h
b/arch/arm/mach-s5pv210/include/mach/uncompress.h
index 08ff2fd..ef977ea 100644
--- a/arch/arm/mach-s5pv210/include/mach/uncompress.h
+++ b/arch/arm/mach-s5pv210/include/mach/uncompress.h
@@ -19,6 +19,8 @@
static void arch_detect_cpu(void)
{
/* we do not need to do any cpu detection here at the moment. */
+ fifo_mask = S5PV210_UFSTAT_TXMASK;
+ fifo_max = 63 S5PV210_UFSTAT_TXSHIFT;
}
#endif /* __ASM_ARCH_UNCOMPRESS_H */
--
1.7.10.4
Applied, thanks.
- Kukjin
--
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: smdk2410: Fix compile breakage
Alexander Shiyan wrote: Symbol S3C_DEV_USB_HOST should be defined to avoid this problem. LINKvmlinux LD vmlinux.o MODPOST vmlinux.o WARNING: modpost: Found 2 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' GEN .version CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o LD init/built-in.o arch/arm/mach-s3c24xx/built-in.o:(.init.data+0x660): undefined reference to `s3c_device_ohci' make: *** [vmlinux] Error 1 Signed-off-by: Alexander Shiyan shc_w...@mail.ru --- arch/arm/mach-s3c24xx/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach- s3c24xx/Kconfig index ba6c501..8080dc1 100644 --- a/arch/arm/mach-s3c24xx/Kconfig +++ b/arch/arm/mach-s3c24xx/Kconfig @@ -350,6 +350,7 @@ config MACH_QT2410 config ARCH_SMDK2410 bool SMDK2410/A9M2410 select S3C24XX_SMDK + select S3C_DEV_USB_HOST help Say Y here if you are using the SMDK2410 or the derived module A9M2410 http://www.fsforth.de -- 1.7.12.4 Applied, thanks. - Kukjin -- 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 02/10] s5p-fimc: Add device tree support for FIMC devices
On 02/07/2013 12:40 AM, Stephen Warren wrote: diff --git a/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt b/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt +Samsung S5P/EXYNOS SoC Camera Subsystem (FIMC) +-- + +The Exynos Camera subsystem comprises of multiple sub-devices that are +represented by separate platform devices. Some of the IPs come in different platform devices is a rather Linux-centric term, and DT bindings should be OS-agnostic. Perhaps use device tree nodes here? Indeed, thank you for the suggestion, I'll change it. +variants across the SoC revisions (FIMC) and some remain mostly unchanged +(MIPI CSIS, FIMC-LITE). + +All those sub-subdevices are defined as parent nodes of the common device s/parent nodes/child node/ I think? Yeah, 'parent nodes' doesn't really make sense. Thanks for catching it. +For every fimc node a numbered alias should be present in the aliases node. +Aliases are of the form fimcn, wheren is an integer (0...N) specifying +the IP's instance index. Why? Isn't it up to the DT author whether they care if each fimc node is assigned a specific identification v.s. whether identification is assigned automatically? There are at least three different kinds of IPs that come in multiple instances in an SoC. To activate data links between them each instance needs to be clearly identified. There are also differences between instances of same device. Hence it's important these aliases don't have random values. Some more details about the SoC can be found at [1]. The aliases are also already used in the Exynos5 GScaler bindings [2] in a similar way. +Optional properties + + - clock-frequency - maximum FIMC local clock (LCLK) frequency Again, I'd expect a clocks property here instead. Please see my comment to patch 01/10. Analogously, I needed this clock frequency to ensure reliable video data pipeline operation. [1] http://tinyurl.com/anw9udm [2] http://www.spinics.net/lists/arm-kernel/msg200036.html -- 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 02/10] s5p-fimc: Add device tree support for FIMC devices
On 02/08/2013 04:16 PM, Sylwester Nawrocki wrote: On 02/07/2013 12:40 AM, Stephen Warren wrote: diff --git a/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt b/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt +Samsung S5P/EXYNOS SoC Camera Subsystem (FIMC) +-- ... +For every fimc node a numbered alias should be present in the aliases node. +Aliases are of the form fimcn, wheren is an integer (0...N) specifying +the IP's instance index. Why? Isn't it up to the DT author whether they care if each fimc node is assigned a specific identification v.s. whether identification is assigned automatically? There are at least three different kinds of IPs that come in multiple instances in an SoC. To activate data links between them each instance needs to be clearly identified. There are also differences between instances of same device. Hence it's important these aliases don't have random values. Some more details about the SoC can be found at [1]. The aliases are also already used in the Exynos5 GScaler bindings [2] in a similar way. Hmmm. I'd expect explicit DT properties to represent the instance-specific configuration, or even different compatible values. Relying on the alias ID seems rather indirect; what if in e.g. Exynos6/... the mapping from instance/alias ID to feature set changes. With explicit DT properties, that'd just be a .dts change, whereas by requiring alias IDs now, you'd need a driver change to support this. -- 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 05/10] s5p-fimc: Add device tree based sensors registration
On 02/07/2013 12:42 AM, Stephen Warren wrote: On 02/01/2013 12:09 PM, Sylwester Nawrocki wrote: The sensor (I2C and/or SPI client) devices are instantiated by their corresponding control bus drivers. Since the I2C client's master clock is often provided by a video bus receiver (host interface) or other than I2C/SPI controller device, the drivers of those client devices are not accessing hardware in their driver's probe() callback. Instead, after enabling clock, the host driver calls back into a sub-device when it wants to activate them. This pattern is used by some in-tree drivers and this patch also uses it for DT case. This patch is intended as a first step for adding device tree support to the S5P/Exynos SoC camera drivers. The second one is adding support for asynchronous sub-devices registration and clock control from sub-device driver level. The bindings shall not change when asynchronous probing support is added. diff --git a/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt b/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt +The sensor device nodes should be added as their control bus controller I think as should be to? Yes, something is wrong here. Hopefully this is more correct: The sensor device nodes should be added to their control bus controller (e.g. I2C0) nodes and linked to a port node in the csis or parallel-ports +(e.g. I2C0) child nodes and linked to a port node in the csis or parallel-ports +node, using common the common video interfaces bindings, i.e. port/endpoint And this needs correction too. +node pairs. The implementation of this binding requires clock-frequency +property to be present in the sensor device nodes. -- 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 01/10] s5p-csis: Add device tree support
On 02/08/2013 03:29 PM, Sylwester Nawrocki wrote: On 02/07/2013 12:36 AM, Stephen Warren wrote: On 02/01/2013 12:09 PM, Sylwester Nawrocki wrote: s5p-csis is platform device driver for MIPI-CSI frontend to the FIMC device. This patch support for binding the driver to the MIPI-CSIS devices instantiated from device tree and for parsing all SoC and board specific properties. diff --git a/Documentation/devicetree/bindings/media/soc/samsung-mipi-csis.txt b/Documentation/devicetree/bindings/media/soc/samsung-mipi-csis.txt +Optional properties: + +- clock-frequency : The IP's main (system bus) clock frequency in Hz, default +value when this property is not specified is 166 MHz; Shouldn't this be a clocks property, so that the driver can call clk_get(), clk_prepare_enable(), clk_get_rate(), etc. on it? Hi Stephen, Thanks for your review! I also use clocks and clock-names property, but didn't specify it here, because the Exynos SoCs clocks driver is not in the mainline yet. I'm a bit sympathetic to this, since I've been trying to push Tegra towards the common clock framework and describing clock connectivity in DT, before adding new drivers that need clocks, specifically to avoid this kind of situation. The problem here is that if this gets merged now, then the clock driver comes along later, you'll have to change this binding definition to account for it, and DT bindings aren't supposed to be changed... Do you have any clock driver at all upstream yet? Or, could you add a dummy clock driver to satisfy the driver's clkl_get() needs? If you do, you can always set up some AUXDATA so that clk_get() works for your driver right now, and then remove that once the complete clock driver is in place with full device tree support. That's how we've ended up handling this for Tegra drivers. Anyway, this is all mainly food-for-thought rather than an objection to the patch; I'd leave that to Grant/Rob if applicable. -- 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 06/10] s5p-fimc: Use pinctrl API for camera ports configuration
On 02/07/2013 12:44 AM, Stephen Warren wrote: On 02/01/2013 12:09 PM, Sylwester Nawrocki wrote: Before the camera ports can be used the pinmux needs to be configured properly. This patch adds a function to set the camera ports pinctrl to a default state within the media driver's probe(). The camera port(s) are then configured for the video bus operation. diff --git a/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt b/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt +- pinctrl-names: pinctrl names for camera port pinmux control, at least +default needs to be specified. +- pinctrl-0...N : pinctrl properties corresponding to pinctrl-names + A reference to the binding document describing the pin control bindings would be appropriate here. Given that reference, I'm not sure if spelling out the property names makes sense since it feels a little like duplication; an alternative might be simply: The pinctrl bindings defined in ../../../pinctrl/pinctrl-bindings.txt must be used to define a pinctrl state named default. OK, I will add a reference to the pinctrl bindings instead. However, this isn't a big deal; it's fine either way. -- Thanks. Sylwester -- 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 02/10] s5p-fimc: Add device tree support for FIMC devices
On 02/09/2013 12:21 AM, Stephen Warren wrote: On 02/08/2013 04:16 PM, Sylwester Nawrocki wrote: On 02/07/2013 12:40 AM, Stephen Warren wrote: diff --git a/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt b/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt +Samsung S5P/EXYNOS SoC Camera Subsystem (FIMC) +-- ... +For every fimc node a numbered alias should be present in the aliases node. +Aliases are of the form fimcn, wheren is an integer (0...N) specifying +the IP's instance index. Why? Isn't it up to the DT author whether they care if each fimc node is assigned a specific identification v.s. whether identification is assigned automatically? There are at least three different kinds of IPs that come in multiple instances in an SoC. To activate data links between them each instance needs to be clearly identified. There are also differences between instances of same device. Hence it's important these aliases don't have random values. Some more details about the SoC can be found at [1]. The aliases are also already used in the Exynos5 GScaler bindings [2] in a similar way. Hmmm. I'd expect explicit DT properties to represent the instance-specific configuration, or even different compatible values. Relying on the alias ID seems rather indirect; what if in e.g. Exynos6/... the mapping from instance/alias ID to feature set changes. With explicit DT properties, that'd just be a .dts change, whereas by requiring alias IDs now, you'd need a driver change to support this. In the initial version of this patch series I used cell-index property, but then Grant pointed out in some other mail thread it should be avoided. Hence I used the node aliases. Different compatible values might not work, when for example there are 3 IPs out of 4 of one type and the fourth one of another type. It wouldn't even by really different types, just quirks/little differences between them, e.g. no data path routed to one of other IPs. Then to connect e.g. MIPI-CSIS.0 to FIMC.2 at run time an index of the MIPI-CSIS needs to be written to the FIMC.2 data input control register. Even though MIPI-CSIS.N are same in terms of hardware structure they still need to be distinguished as separate instances. -- 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 01/10] s5p-csis: Add device tree support
On 02/09/2013 12:27 AM, Stephen Warren wrote: On 02/08/2013 03:29 PM, Sylwester Nawrocki wrote: On 02/07/2013 12:36 AM, Stephen Warren wrote: On 02/01/2013 12:09 PM, Sylwester Nawrocki wrote: s5p-csis is platform device driver for MIPI-CSI frontend to the FIMC device. This patch support for binding the driver to the MIPI-CSIS devices instantiated from device tree and for parsing all SoC and board specific properties. diff --git a/Documentation/devicetree/bindings/media/soc/samsung-mipi-csis.txt b/Documentation/devicetree/bindings/media/soc/samsung-mipi-csis.txt +Optional properties: + +- clock-frequency : The IP's main (system bus) clock frequency in Hz, default +value when this property is not specified is 166 MHz; Shouldn't this be a clocks property, so that the driver can call clk_get(), clk_prepare_enable(), clk_get_rate(), etc. on it? Hi Stephen, Thanks for your review! I also use clocks and clock-names property, but didn't specify it here, because the Exynos SoCs clocks driver is not in the mainline yet. I'm a bit sympathetic to this, since I've been trying to push Tegra towards the common clock framework and describing clock connectivity in DT, before adding new drivers that need clocks, specifically to avoid this kind of situation. The problem here is that if this gets merged now, then the clock driver comes along later, you'll have to change this binding definition to account for it, and DT bindings aren't supposed to be changed... Yes, I wasn't quite sure if this is a really serious problem or not. There is already quite a few drivers for the Exynos SoC IPs that have DT support and their bindings will need to be changed when the new clocks driver gets upstreamed... Do you have any clock driver at all upstream yet? Or, could you add a dummy clock driver to satisfy the driver's clkl_get() needs? If you do, you can always set up some AUXDATA so that clk_get() works for your driver right now, and then remove that once the complete clock driver is in place with full device tree support. That's how we've ended up handling this for Tegra drivers. Yes, there is the clocks support upstream, only not using the common clock API. And I used indeed AUXDATA in v3 of these patches. The Exynos common clock API based driver was supposed to be merged in v3.9, but it seems it won't happen. These patches also won't make it to 3.9. Then hopefully both appear in 3.10 together. I will add the clock properties to relevant nodes, assuming the new clocks driver is available. Anyway, this is all mainly food-for-thought rather than an objection to the patch; I'd leave that to Grant/Rob if applicable. :-) OK, thanks for the suggestions. -- 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 02/10] s5p-fimc: Add device tree support for FIMC devices
On 02/08/2013 05:05 PM, Sylwester Nawrocki wrote: On 02/09/2013 12:21 AM, Stephen Warren wrote: On 02/08/2013 04:16 PM, Sylwester Nawrocki wrote: On 02/07/2013 12:40 AM, Stephen Warren wrote: diff --git a/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt b/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt +Samsung S5P/EXYNOS SoC Camera Subsystem (FIMC) +-- ... +For every fimc node a numbered alias should be present in the aliases node. +Aliases are of the form fimcn, wheren is an integer (0...N) specifying +the IP's instance index. Why? Isn't it up to the DT author whether they care if each fimc node is assigned a specific identification v.s. whether identification is assigned automatically? There are at least three different kinds of IPs that come in multiple instances in an SoC. To activate data links between them each instance needs to be clearly identified. There are also differences between instances of same device. Hence it's important these aliases don't have random values. Some more details about the SoC can be found at [1]. The aliases are also already used in the Exynos5 GScaler bindings [2] in a similar way. Hmmm. I'd expect explicit DT properties to represent the instance-specific configuration, or even different compatible values. Relying on the alias ID seems rather indirect; what if in e.g. Exynos6/... the mapping from instance/alias ID to feature set changes. With explicit DT properties, that'd just be a .dts change, whereas by requiring alias IDs now, you'd need a driver change to support this. In the initial version of this patch series I used cell-index property, but then Grant pointed out in some other mail thread it should be avoided. Hence I used the node aliases. To me, using cell-index is semantically equivalent to using the alias ID. Different compatible values might not work, when for example there are 3 IPs out of 4 of one type and the fourth one of another type. It wouldn't even by really different types, just quirks/little differences between them, e.g. no data path routed to one of other IPs. I was thinking of using feature-/quirk-oriented properties. For example, if there's a port on 3 of the 4 devices to connect to some other IP block, simply include a boolean property to indicate whether that port is present. It would be in 3 of the nodes but not the 4th. Then to connect e.g. MIPI-CSIS.0 to FIMC.2 at run time an index of the MIPI-CSIS needs to be written to the FIMC.2 data input control register. Even though MIPI-CSIS.N are same in terms of hardware structure they still need to be distinguished as separate instances. Oh, so you're using the alias ID as the value to write into the FIMC.2 register for that. I'm not 100% familiar with aliases, but they seem like a more user-oriented naming thing to me, whereas values for hooking up intra-SoC routing are an unrelated namespace semantically, even if the values happen to line up right now. Perhaps rather than a Boolean property I mentioned above, use a custom property to indicate the ID that the FIMC.2 object knows the MIPI-CSIS.0 object as? While this seems similar to using cell-index, my *guess* is that Grant's objection to using cell-index was more based on re-using cell-index for something other than its intended purpose than pushing you to use an alias ID rather than a property. After all, what happens in some later SoC where you have two different types of module that feed into the common module, such that type A sources have IDs 0..3 in the common module, and type B sources have IDs 4..7 in the common module - you wouldn't want to require alias ISs 4..7 for the type B DT nodes. -- 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
