Re: [PATCHv2 0/3] Add support for DRM display subsystem
On 5/10/12, Kukjin Kim kgene@samsung.com wrote: Marek Szyprowski wrote: Hello, This patch set adds support for Exynos DRM display subsystem for Universal C210 and NURI boards. Exynos DRM driver has been merged to 3.3 kernel tree and provides unified and more powerful alternative for s3c-fb and s5p-tv drivers. V2 includes update for the latest changes in platform data structure (added 'panel' entry). Best regards Marek Szyprowski Samsung Poland RD Center Patch summary: Marek Szyprowski (3): ARM: Exynos: add platform device for core DRM subsystem ARM: Exynos: Add DRM core device support for Universal C210 board ARM: Exynos: Add DRM core support for NURI board arch/arm/mach-exynos/Kconfig |7 ++ arch/arm/mach-exynos/Makefile |1 + arch/arm/mach-exynos/dev-drm.c | 29 arch/arm/mach-exynos/mach-nuri.c | 33 arch/arm/mach-exynos/mach-universal_c210.c | 33 arch/arm/plat-samsung/include/plat/devs.h |2 + 6 files changed, 105 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-exynos/dev-drm.c -- 1.7.1.569.g6f426 Well, 2nd and 3rd patches can break multi-platform for EXYNOS SoCs with one kernel image. And I won't apply new feature for non-dt board file from now on. I think, we need to support DT in mach-exynos/ instead of non-DT and DT together, so please consider to move on dt supporting for Samsung mobile boards. Probably you misunderstand Arnd word. From the statements made so far, I can see no clear policy that we can apply to everyone. My take on this is that for any work I spend on multiplatform kernel, I concentrate on the DT-based board files and get them to work together first, but leave it up to the individual subarch maintainers whether they want to add other board files into the mix. It doesn't mean add new feature to non-DT board. don't add new board file. In this case, DRM is not yet ready to support DT. Okay, you can just drop this patches. but please note that this patches are posted at Mar 13 before you decide. BR, Kyungmin Park Note that I have a plan to replace board files with DT supporting in mach-exynos/ next time. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, 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 -- 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/7] mmc: dw_mmc: add device tree support
On 5/10/12, Thomas Abraham thomas.abra...@linaro.org wrote:
Dear Mr. Park,
On 2 May 2012 12:25, Kyungmin Park kmp...@infradead.org wrote:
Hi,
On 5/2/12, Thomas Abraham thomas.abra...@linaro.org wrote:
Add device tree based discovery support.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
.../devicetree/bindings/mmc/synposis-dw-mshc.txt | 85 +
drivers/mmc/host/dw_mmc-pltfm.c| 24 +++
drivers/mmc/host/dw_mmc.c | 181
+++-
drivers/mmc/host/dw_mmc.h | 10 +
include/linux/mmc/dw_mmc.h |2 +
5 files changed, 296 insertions(+), 6 deletions(-)
create mode 100644
Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
diff --git a/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
new file mode 100644
index 000..c1ed70e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
@@ -0,0 +1,85 @@
+* Synopsis Designware Mobile Storage Host Controller
+
+The Synopsis designware mobile storage host controller is used to
interface
+a SoC with storage medium such as eMMC or SD/MMC cards.
+
+Required Properties:
+
+* compatible: should be one of the following
+ - synopsis,dw-mshc: for controllers compliant with synopsis
dw-mshc.
I googled the Synopsis Designware Mobile Storage Host Controller and
Synopsis released it as this name. but still I like the 'dw-mmc'
instead of'dw-mshc'.
Ok. Synopsis abbreviates this controller as MSHC in their datasheets
available online. Since device tree is more about describing the
hardware, using MSHC as the abbreviation will help with correlating
hardware specs with the dts file. So I would prefer to continue using
mshc as the abbreviation.
Then why author of this file uses dw-mmc instead of dw-mshc? and
it uses 'dw_mci' prefix at functions. I just worried and don't want to
give confusion to users who uses this device.
+
+* reg: physical base address of the dw-mshc controller and size of its
memory
+ region.
+
+* interrupts: interrupt specifier for the controller. The format and
value
of
+ the interrupt specifier depends on the interrupt parent for the
controller.
+
+# Slots: The slot specific information are contained within child-nodes
with
+ each child-node representing a supported slot. There should be
atleast
one
+ child node representing a card slot. The name of the slot child node
should
+ be 'slot{n}' where n is the unique number of the slot connnected to
the
+ controller. The following are optional properties which can be
included
in
+ the slot child node.
+
+ * bus-width: specifies the width of the data bus connected from
the
+ controller to the card slot. The value should be 1, 4 or 8. In
case
+ this property is not specified, a default value of 1 is assumed
for
+ this property.
+
+ * cd-gpios: specifies the card detect gpio line. The format of the
+ gpio specifier depends on the gpio controller.
+
+ * wp-gpios: specifies the write protect gpio line. The format of
the
+ gpio specifier depends on the gpio controller.
+
+ * gpios: specifies a list of gpios used for command, clock and
data
+ bus. The first gpio is the command line and the second gpio is
the
+ clock line. The rest of the gpios (depending on the bus-width
+ property) are the data lines in no particular order. The format
of
+ the gpio specifier depends on the gpio controller.
+
+Optional properties:
+
+* fifo-depth: The maximum size of the tx/rx fifo's. If this property is
not
+ specified, the default value of the fifo size is determined from the
+ controller registers.
+
+* card-detect-delay: Delay in milli-seconds before detecting card
after
card
+ insert event. The default value is 0.
+
+* supports-highspeed: Enables support for high speed cards (upto 50MHz)
+
+* card-detection-broken: The card detection functionality is not
available
on
+ any of the slots.
+
+* no-write-protect: The write protect pad of the controller is not
connected
+ to the write protect pin on the slot.
+
+Example:
+
+ The MSHC controller node can be split into two portions, SoC specific
and
+ board specific portions as listed below.
+
+ dwmmc0@1220 {
+ compatible = synopsis,dw-mshc;
+ reg = 0x1220 0x1000;
+ interrupts = 0 75 0;
+ };
+
+ dwmmc0@1220 {
+ supports-highspeed;
+ card-detection-broken;
+ no-write-protect;
+ fifo-depth = 0x80;
+ card-detect-delay = 200;
+
+ slot0 {
+ bus-width = 8;
+ cd-gpios = gpc0 2 2 3 3;
+ gpios = gpc0 0 2 0 3, gpc0 1 2 0 3
Re: [PATCHv2 0/3] Add support for DRM display subsystem
On Thu, May 10, 2012 at 10:48 PM, Arnd Bergmann a...@arndb.de wrote: On Thursday 10 May 2012, Kyungmin Park wrote: And I won't apply new feature for non-dt board file from now on. I think, we need to support DT in mach-exynos/ instead of non-DT and DT together, so please consider to move on dt supporting for Samsung mobile boards. Probably you misunderstand Arnd word. From the statements made so far, I can see no clear policy that we can apply to everyone. My take on this is that for any work I spend on multiplatform kernel, I concentrate on the DT-based board files and get them to work together first, but leave it up to the individual subarch maintainers whether they want to add other board files into the mix. It doesn't mean add new feature to non-DT board. don't add new board file. This is a completely separate discussion, the problem at hand doesn't have anything to do with building a kernel for multiple mach-* directories combined that I was referring to in the text you quote. In this case, DRM is not yet ready to support DT. Okay, you can just drop this patches. but please note that this patches are posted at Mar 13 before you decide. I think it's a good idea to make new features DT-only because this way we don't get any regressions and everyone who want to use the new feature will be able to test the DT support on his board. The 'new feature' is some misleading word. In this case DRM drivers are used from v3.2 at drivers. but not registered it at board file. Basically agree to move DT and used it finally. Before that bring up the board using DRM based graphics. This of course requires that basic DT support is available for the systems in question so we don't regress when moving away from the old board files. My impression is that we're getting close to that point on exynos thanks to Thomas' work on this. AFAICT we don't have a DT binding for screen timings yet, so you will still have to use auxdata for that or put the timings into the driver. I'm also thanks to Thomas, he did a lot of works for eyxnos. but most parts are missing at least exynos platform. e.g., Please see the origen.dts. I wonder it's booted with any graphical user interface platform, android or ubuntu. Maybe not. Anyway, as discussed in multi-platform support mail threads, we're also moving to DT in the big picture. but still want to use existing boards as is. Thank you, Kyungmin 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
Re: [PATCH v3 0/2] regulator: Add initial suport for max77686
Hi Mark, BTW, do you know that you're reviewing the same device driver patch from different person? One from Mr. Lee and another from Yadwinder. I wonder how to handle it finally. which one is choose? Thank you, Kyungmin Park On 5/22/12, yadi.bra...@gmail.com yadi.bra...@gmail.com wrote: From: Yadwinder Singh Brar yadi.b...@samsung.com This patch series adds support for max77686 which is a multifunction device which includes regulator (pmic), rtc and charger sub-blocks within it. The support for mfd driver and regulator driver are added by this patch series. This patch series also includes device tree and irqdomain support for mfd and regulator portions. Implemented the required modification, stated in the recieved review comments. changes since v1: -added regmap support. -implemented .get_voltage_sel, .set_voltage_sel and .set_voltage_time_sel after removing .get_voltage and .set_voltage in regulator driver. -used of_regulator_match() for parsing DT. -added Documentation for Devive Tree binding. changes since v2: -converted to use regulator_get_voltage_sel_regmap, regulator_set_voltage_sel_regmap, regulator_enable_regmap, regulator_disable_regmap, regulator_is_enabled_regmap. This patch series is based on mark_regulator/for-next and has been tested on GAIA board. Yadwinder Singh Brar (2): mfd: Add support for MAX77686. regulator: Add support for MAX77686. Documentation/devicetree/bindings/mfd/max77686.txt | 61 +++ drivers/mfd/Kconfig| 21 + drivers/mfd/Makefile |1 + drivers/mfd/max77686-irq.c | 255 + drivers/mfd/max77686.c | 322 drivers/regulator/Kconfig |9 + drivers/regulator/Makefile |1 + drivers/regulator/max77686.c | 389 include/linux/mfd/max77686-private.h | 282 ++ include/linux/mfd/max77686.h | 100 + 10 files changed, 1441 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/max77686.txt create mode 100644 drivers/mfd/max77686-irq.c create mode 100644 drivers/mfd/max77686.c create mode 100644 drivers/regulator/max77686.c create mode 100644 include/linux/mfd/max77686-private.h create mode 100644 include/linux/mfd/max77686.h -- 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 05/20] ARM: EXYNOS: Redefine IRQ_MCT_L0,1 definition
Hi,
On Tue, May 1, 2012 at 4:14 AM, Thomas Abraham
thomas.abra...@linaro.org wrote:
From: Changhwan Youn chaos.y...@samsung.com
Redefine IRQ_MCT_L0,1 irq definition as it is changed in rev1 of EXYNOS5.
Signed-off-by: Changhwan Youn chaos.y...@samsung.com
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
Signed-off-by: Kukjin Kim kgene@samsung.com
---
arch/arm/mach-exynos/include/mach/irqs.h | 4 ++--
arch/arm/mach-exynos/mct.c | 17 +++--
2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-exynos/include/mach/irqs.h
b/arch/arm/mach-exynos/include/mach/irqs.h
index 591e7852..ef52f61 100644
--- a/arch/arm/mach-exynos/include/mach/irqs.h
+++ b/arch/arm/mach-exynos/include/mach/irqs.h
@@ -331,6 +331,8 @@
#define EXYNOS5_IRQ_SATA IRQ_SPI(115)
#define EXYNOS5_IRQ_NFCON IRQ_SPI(116)
+#define EXYNOS5_IRQ_MCT_L0 IRQ_SPI(120)
+#define EXYNOS5_IRQ_MCT_L1 IRQ_SPI(121)
#define EXYNOS5_IRQ_MMC44 IRQ_SPI(123)
#define EXYNOS5_IRQ_MDMA1 IRQ_SPI(124)
#define EXYNOS5_IRQ_FIMC_LITE0 IRQ_SPI(125)
@@ -410,8 +412,6 @@
#define EXYNOS5_IRQ_FIMD1_SYSTEM COMBINER_IRQ(18, 6)
#define EXYNOS5_IRQ_EINT0 COMBINER_IRQ(23, 0)
-#define EXYNOS5_IRQ_MCT_L0 COMBINER_IRQ(23, 1)
-#define EXYNOS5_IRQ_MCT_L1 COMBINER_IRQ(23, 2)
#define EXYNOS5_IRQ_MCT_G0 COMBINER_IRQ(23, 3)
#define EXYNOS5_IRQ_MCT_G1 COMBINER_IRQ(23, 4)
#define EXYNOS5_IRQ_MCT_G2 COMBINER_IRQ(23, 5)
diff --git a/arch/arm/mach-exynos/mct.c b/arch/arm/mach-exynos/mct.c
index 897d9a9..b601fb8 100644
--- a/arch/arm/mach-exynos/mct.c
+++ b/arch/arm/mach-exynos/mct.c
@@ -388,6 +388,7 @@ static int __cpuinit exynos4_local_timer_setup(struct
clock_event_device *evt)
{
struct mct_clock_event_device *mevt;
unsigned int cpu = smp_processor_id();
+ int mct_lx_irq;
mevt = this_cpu_ptr(percpu_mct_tick);
mevt-evt = evt;
@@ -414,14 +415,18 @@ static int __cpuinit exynos4_local_timer_setup(struct
clock_event_device *evt)
if (mct_int_type == MCT_INT_SPI) {
if (cpu == 0) {
+ mct_lx_irq = soc_is_exynos4210() ? EXYNOS4_IRQ_MCT_L0
:
+ EXYNOS5_IRQ_MCT_L0;
Does it still valid for exynos4x12?. It means exynos4x12 uses
EXYNOS5_IRQ_MCT_L0?
mct_tick0_event_irq.dev_id = mevt;
- evt-irq = EXYNOS4_IRQ_MCT_L0;
- setup_irq(EXYNOS4_IRQ_MCT_L0, mct_tick0_event_irq);
+ evt-irq = mct_lx_irq;
+ setup_irq(mct_lx_irq, mct_tick0_event_irq);
} else {
+ mct_lx_irq = soc_is_exynos4210() ? EXYNOS4_IRQ_MCT_L1
:
+ EXYNOS5_IRQ_MCT_L1;
ditto
mct_tick1_event_irq.dev_id = mevt;
- evt-irq = EXYNOS4_IRQ_MCT_L1;
- setup_irq(EXYNOS4_IRQ_MCT_L1, mct_tick1_event_irq);
- irq_set_affinity(EXYNOS4_IRQ_MCT_L1, cpumask_of(1));
+ evt-irq = mct_lx_irq;
+ setup_irq(mct_lx_irq, mct_tick1_event_irq);
+ irq_set_affinity(mct_lx_irq, cpumask_of(1));
}
} else {
enable_percpu_irq(EXYNOS_IRQ_MCT_LOCALTIMER, 0);
@@ -473,7 +478,7 @@ static void __init exynos4_timer_resources(void)
static void __init exynos4_timer_init(void)
{
- if (soc_is_exynos4210())
+ if ((soc_is_exynos4210()) || (soc_is_exynos5250()))
mct_int_type = MCT_INT_SPI;
else
mct_int_type = MCT_INT_PPI;
BTW exynos4x12 uses MCT_INT_PPI?
Kyungmin Park
--
1.7.5.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
Re: [PATCH v5 5/5] ARM: exynos: add thermal sensor driver platform data support
On Fri, Jul 13, 2012 at 8:10 PM, Amit Daniel Kachhap
amit.kach...@linaro.org wrote:
Add necessary default platform data support needed for TMU driver. This
dt/non-dt values are tested for origen exynos4210 and smdk exynos5250
platforms.
Looks good to me.
just nitpicks below.
Thank you,
Kyungmin Park
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
Cc: Donggeun Kim dg77@samsung.com
Acked-by: Guenter Roeck guenter.ro...@ericsson.com
Cc: SangWook Ju sw...@samsung.com
Cc: Durgadoss durgados...@intel.com
Cc: Len Brown l...@kernel.org
Cc: Jean Delvare kh...@linux-fr.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
drivers/thermal/exynos_thermal.c | 111
+-
1 files changed, 110 insertions(+), 1 deletions(-)
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
index 9ef8c37..07736ea 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -662,14 +662,121 @@ static irqreturn_t exynos_tmu_irq(int irq, void *id)
static struct thermal_sensor_conf exynos_sensor_conf = {
.name = exynos-therm,
.read_temperature = (int (*)(void *))exynos_tmu_read,
+};
+
+#if defined(CONFIG_CPU_EXYNOS4210)
BTW, doesn't it same as exynos4412? does it different from exynos4412?
If it's same, it's better to use CONFIG_SOC_EXYNOS4?
+static struct exynos_tmu_platform_data const exynos4_default_tmu_data = {
+ .threshold = 80,
+ .trigger_levels[0] = 5,
+ .trigger_levels[1] = 20,
+ .trigger_levels[2] = 30,
+ .trigger_level0_en = 1,
+ .trigger_level1_en = 1,
+ .trigger_level2_en = 1,
+ .trigger_level3_en = 0,
+ .gain = 15,
+ .reference_voltage = 7,
+ .cal_type = TYPE_ONE_POINT_TRIMMING,
+ .freq_tab[0] = {
+ .freq_clip_max = 800 * 1000,
+ .temp_level = 85,
+ },
+ .freq_tab[1] = {
+ .freq_clip_max = 200 * 1000,
+ .temp_level = 100,
+ },
+ .freq_tab_count = 2,
+ .type = SOC_ARCH_EXYNOS4,
+};
+#define EXYNOS4_TMU_DRV_DATA (exynos4_default_tmu_data)
+#else
+#define EXYNOS4_TMU_DRV_DATA (NULL)
+#endif
+
+#if defined(CONFIG_SOC_EXYNOS5250)
similar.
+static struct exynos_tmu_platform_data const exynos5_default_tmu_data = {
+ .trigger_levels[0] = 85,
+ .trigger_levels[1] = 103,
+ .trigger_levels[2] = 110,
+ .trigger_level0_en = 1,
+ .trigger_level1_en = 1,
+ .trigger_level2_en = 1,
+ .trigger_level3_en = 0,
+ .gain = 8,
+ .reference_voltage = 16,
+ .noise_cancel_mode = 4,
+ .cal_type = TYPE_ONE_POINT_TRIMMING,
+ .efuse_value = 55,
+ .freq_tab[0] = {
+ .freq_clip_max = 800 * 1000,
+ .temp_level = 85,
+ },
+ .freq_tab[1] = {
+ .freq_clip_max = 200 * 1000,
+ .temp_level = 103,
+ },
+ .freq_tab_count = 2,
+ .type = SOC_ARCH_EXYNOS5,
+};
+#define EXYNOS5_TMU_DRV_DATA (exynos5_default_tmu_data)
+#else
+#define EXYNOS5_TMU_DRV_DATA (NULL)
+#endif
+
+#ifdef CONFIG_OF
+static const struct of_device_id exynos_tmu_match[] = {
+ {
+ .compatible = samsung,exynos4-tmu,
+ .data = (void *)EXYNOS4_TMU_DRV_DATA,
+ },
+ {
+ .compatible = samsung,exynos5-tmu,
+ .data = (void *)EXYNOS5_TMU_DRV_DATA,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, exynos_tmu_match);
+#else
+#define exynos_tmu_match NULL
+#endif
+
+static struct platform_device_id exynos_tmu_driver_ids[] = {
+ {
+ .name = exynos4-tmu,
+ .driver_data= (kernel_ulong_t)EXYNOS4_TMU_DRV_DATA,
+ },
+ {
+ .name = exynos5-tmu,
+ .driver_data= (kernel_ulong_t)EXYNOS5_TMU_DRV_DATA,
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(platform, exynos4_tmu_driver_ids);
+
+static inline struct exynos_tmu_platform_data *exynos_get_driver_data(
+ struct platform_device *pdev)
+{
+#ifdef CONFIG_OF
+ if (pdev-dev.of_node) {
+ const struct of_device_id *match;
+ match = of_match_node(exynos_tmu_match, pdev-dev.of_node);
+ if (!match)
+ return NULL;
+ return (struct exynos_tmu_platform_data *) match-data;
+ }
+#endif
+ return (struct exynos_tmu_platform_data *)
+ platform_get_device_id(pdev)-driver_data;
}
-;
static int __devinit exynos_tmu_probe(struct platform_device *pdev)
{
struct exynos_tmu_data *data;
struct exynos_tmu_platform_data *pdata = pdev-dev.platform_data;
int ret, i;
+ if (!pdata)
+ pdata = exynos_get_driver_data(pdev
Re: 회신: 회신: [PATCH] ODROID-X: hkdk4412: Add new hardware based on Exynos4412
On 8/7/12, Thomas Abraham thomas.abra...@linaro.org wrote: On 7 August 2012 07:58, Olof Johansson o...@lixom.net wrote: Hi, On Mon, Aug 6, 2012 at 7:05 PM, Dongjin Kim dongjin@agreeyamobility.net wrote: Hello, I am trying to understand what I have to do for device tree. In order to create dts file for ODROID-X hardware, it seems I may need dts file of EXYNOS4412 SoC. But maybe exynos4412.dtsi is not merged yet or not exist, like exynos4210.dtsi or exynos5250.dtsi. Obviously it seems not easy to create such a file without SoC datasheet, and I do not have it. So do I wait for the file to be merged by Samsung or better to create initial dts file cloned from exynos4210.dtsi and modify to have verified nodes with the source/header files? Ideally they already have one waiting to be submitted, but that might not be the case. Given that the origenboard design with 4412 is not yet shipping, I'm guessing the Linaro Samsung engineers might not have done much work on 4412 yet. Kukjin? Thomas? What's your suggestion? The alternative is to use the data you have available -- i.e. sources and patches, and craft the device tree from there. The design of 4412 is a derivative from 4210, so that's a good start. Next step would be to describe the board on top of the SoC, peripherals, etc. Take a look at how the origen board support was added, and so on. I ordered an odroid-x several weeks ago but I haven't have a confirmed shipping date yet. :( I'm not sure how long it'll be before I can help out, unfortunately. -Olof Most of the Exynos4210 device tree support can be reused for Exynos4412 as well. Looking at the hardware differences between the two, it might be better to create a new exynos4.dtsi file (kind of creating it out of the existing exynos4210.dtsi) which will have all the common bits across all SoC's in the Exynos4 family. Further, there can be exynos4210.dtsi and exynos4412.dtsi which would specify SoC specific differences such as the GIC cpu-offset property and the additional groups available in the interrupt combiner. There are differences in the gpio/pinmux controllers as well which have to be described using device tree. The current gpio/pinmux device tree support depends entirely on the gpio-samsung driver which handles both gpio and pinmux but requires listing all the banks available in Exynos4412. I would prefer not to do that since we are switching over to using a pin controller driver and I am currently working on this driver. The pin controller driver is important without which the gpio/pinmux/pinconf setting for devices such as i2c and sdhci controller cannot be setup. The basic pinctrl driver for Exynos4 has already been posted and now I am working on adding gpio and wakeup interrupt support into that driver (hoping to complete it this week). So the probable steps in getting started with using device tree for Exynos4412 would be 1. Create a new exynos4.dtsi file with all the Exynos4 common properties for all dt supported controllers. 2. Update the exynos4210.dtsi file accordingly and add the new exynos4412.dtsi file. 3. With this, it will be possible to boot the kernel and test peripherals that do not depend on gpio/pinmux (rtc, wdt, etc). 4. When the Exynos4 pinctrl driver is available, start adding device nodes for i2c and sdhci controllers. 5. Incrementally add device tree coverage for the board and other peripherals on Exynos4412. Nice! Good plan as I thnk. Thank you, Kyungmin 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
Re: [PATCH 1/3] ARM: EXYNOS: Use EXYNOS4210_GPEx instead of EXYNOS4_GPEx
On 8/29/12, Kukjin Kim kgene@samsung.com wrote:
On 08/28/12 03:06, Tomasz Figa wrote:
The GPEx gpios are specific to Exynos4210 and do not exist on Exynos4x12.
Redefine them to use the exact SoC name.
Based on ARM: EXYYNOS: Use EXYNOS4210_GPEx instead of EXYNOS4_GPEx by
Joonyoung Shim, see:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-May/100738.html
Signed-off-by: Tomasz Figat.f...@samsung.com
---
arch/arm/mach-exynos/include/mach/gpio.h | 32
+++---
arch/arm/mach-exynos/mach-nuri.c | 16 +++
arch/arm/mach-exynos/mach-origen.c | 6 +++---
arch/arm/mach-exynos/mach-trats.c | 4 ++--
arch/arm/mach-exynos/mach-universal_c210.c | 32
+++---
arch/arm/mach-exynos/setup-fimc.c | 4 ++--
drivers/gpio/gpio-samsung.c| 20 +--
7 files changed, 57 insertions(+), 57 deletions(-)
diff --git a/arch/arm/mach-exynos/include/mach/gpio.h
b/arch/arm/mach-exynos/include/mach/gpio.h
index eb24f1e..21c9bf1 100644
--- a/arch/arm/mach-exynos/include/mach/gpio.h
+++ b/arch/arm/mach-exynos/include/mach/gpio.h
@@ -26,11 +26,11 @@
#define EXYNOS4_GPIO_C1_NR (5)
#define EXYNOS4_GPIO_D0_NR (4)
#define EXYNOS4_GPIO_D1_NR (4)
-#define EXYNOS4_GPIO_E0_NR (5)
-#define EXYNOS4_GPIO_E1_NR (8)
-#define EXYNOS4_GPIO_E2_NR (6)
-#define EXYNOS4_GPIO_E3_NR (8)
-#define EXYNOS4_GPIO_E4_NR (8)
+#define EXYNOS4210_GPIO_E0_NR (5)
+#define EXYNOS4210_GPIO_E1_NR (8)
+#define EXYNOS4210_GPIO_E2_NR (6)
+#define EXYNOS4210_GPIO_E3_NR (8)
+#define EXYNOS4210_GPIO_E4_NR (8)
Please see my comments on Joonyoung Shim's previous patch...
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-May/101522.html
It's perference issue. some person like this style. others doesn't.
Moreever vender, System LSI, provided codes have whole different style.
It lists up whole gpios for each SoCs.
EXYNOS4210_{A0, Z}
EXYNOS4412_{A0, V4}
EXYNOS5250_{A0, Z}
anyway, just remain it as broken, and try to use pinctl as Thomas mentioned.
Thank you,
Kyungmin Park
[...]
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, 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
--
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: EXYNOS: Use non-secure MDMA1
On 8/29/12, Kukjin Kim kgene@samsung.com wrote:
On 08/28/12 04:08, Tomasz Figa wrote:
Using secure MDMA1 on TrustZone-enabled boards causes early boot crash,
so use non-secure instead.
Signed-off-by: Tomasz Figat.f...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
arch/arm/mach-exynos/dma.c | 2 +-
arch/arm/mach-exynos/include/mach/map.h | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/dma.c b/arch/arm/mach-exynos/dma.c
index f60b66d..8858df5 100644
--- a/arch/arm/mach-exynos/dma.c
+++ b/arch/arm/mach-exynos/dma.c
@@ -261,7 +261,7 @@ static struct dma_pl330_platdata exynos_mdma1_pdata =
{
};
static AMBA_AHB_DEVICE(exynos_mdma1, dma-pl330.2, 0x00041330,
-EXYNOS4_PA_MDMA1, {EXYNOS4_IRQ_MDMA1},exynos_mdma1_pdata);
+EXYNOS4_PA_NS_MDMA1, {EXYNOS4_IRQ_MDMA1},exynos_mdma1_pdata);
static int __init exynos_dma_init(void)
{
diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-
exynos/include/mach/map.h
index 51943f2..5df5910 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -89,7 +89,8 @@
#define EXYNOS4_PA_L2CC0x10502000
#define EXYNOS4_PA_MDMA0 0x1081
-#define EXYNOS4_PA_MDMA10x1284
+#define EXYNOS4_PA_S_MDMA1 0x1284
+#define EXYNOS4_PA_NS_MDMA1 0x1285
#define EXYNOS4_PA_PDMA0 0x1268
#define EXYNOS4_PA_PDMA1 0x1269
#define EXYNOS5_PA_MDMA0 0x1080
Cc'ed Boojin Kim.
Well, just fix the address is enough like exynos5 stuff? I don't have
any idea why we need secure mdma and non-secure mdma both here...
Did you see the datasheet and your team codes?
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index c72b675..c941053 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -89,7 +89,7 @@
#define EXYNOS4_PA_L2CC0x10502000
#define EXYNOS4_PA_MDMA00x1081
-#define EXYNOS4_PA_MDMA1 0x1284
+#define EXYNOS4_PA_MDMA1 0x1285
#define EXYNOS4_PA_PDMA00x1268
#define EXYNOS4_PA_PDMA10x1269
#define EXYNOS5_PA_MDMA00x1080
--
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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 0/6] ARM: EXYNOS: Add support for Trats board using device tree
+ Thomas Abraham, -Original Message- From: Tomasz Figa [mailto:t.f...@samsung.com] Sent: Wednesday, August 29, 2012 10:13 PM To: linux-samsung-soc@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org; kyungmin.p...@samsung.com; kgene@samsung.com; jy0922.s...@samsung.com; Tomasz Figa Subject: [PATCH 0/6] ARM: EXYNOS: Add support for Trats board using device tree This patch series adds basic device tree support for Samsung Trats board along with any necessary prerequisites. In addition it refactors Exynos4 dts include files to split parts common to the whole Exynos4 part from parts specific to Exynos4210 to allow further extension of Exynos4210 dts include file and addition of include files for other SoCs from Exynos4 line. Dependencies: - [PATCH v5] mmc: sdhci-s3c: Add device tree support http://www.spinics.net/lists/linux-samsung-soc/msg12056.html - [PATCH v5 2/2] regulator: add device tree support for max8997 http://www.spinics.net/lists/kernel/msg1328117.html Tomasz Figa (6): ARM: dts: Move parts common to Exynos4 from Exynos4210.dtsi to Exynos4.dtsi ARM: EXYNOS: exynos4-dt: Use exynos4 prefix instead of exynos4210 ARM: Exynos4: dts: Specify address and size cells for i2c controllers ARM: Exynos4: Add OF compatibility lookups for Exynos4 i2c adapters ARM: EXYNOS: Increase maximum possible memory bank size to 512MiB ARM: Exynos: Add basic dts file for Samsung Trats board arch/arm/boot/dts/exynos4.dtsi | 418 + arch/arm/boot/dts/exynos4210-trats.dts | 287 arch/arm/boot/dts/exynos4210.dtsi | 377 +- arch/arm/mach-exynos/Makefile.boot | 2 +- arch/arm/mach-exynos/include/mach/memory.h | 4 +- arch/arm/mach-exynos/mach-exynos4-dt.c | 34 ++- 6 files changed, 734 insertions(+), 388 deletions(-) create mode 100644 arch/arm/boot/dts/exynos4.dtsi create mode 100644 arch/arm/boot/dts/exynos4210-trats.dts -- 1.7.12 -- 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: exynos: delete redundant HAVE_SCHED_CLOCK option in Kconfig
Hi, then where select it HAVE_SCHED_CLOCK? apart from other exynos board, universal have to use another clock. Thank you, Kyungmin Park On 8/31/12, Barry Song barry.s...@csr.com wrote: From: Barry Song baohua.s...@csr.com Signed-off-by: Barry Song baohua.s...@csr.com --- arch/arm/mach-exynos/Kconfig |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index b5b4c8c..3fd4ab3 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -243,7 +243,6 @@ config MACH_UNIVERSAL_C210 select CPU_EXYNOS4210 select S5P_HRT select CLKSRC_MMIO - select HAVE_SCHED_CLOCK select S5P_GPIO_INT select S5P_DEV_FIMC0 select S5P_DEV_FIMC1 -- 1.7.0.4 Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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: exynos: delete redundant HAVE_SCHED_CLOCK option in Kconfig
Acked-by: Kyungmin Park kyungmin.p...@samsung.com # git grep HAVE_SCHED_CLOCK arch/arm/ arch/arm/Kconfig: select HAVE_SCHED_CLOCK arch/arm/mach-exynos/Kconfig: select HAVE_SCHED_CLOCK On 8/31/12, Barry Song 21cn...@gmail.com wrote: 2012/8/31 Kyungmin Park kmp...@infradead.org: Hi, then where select it HAVE_SCHED_CLOCK? apart from other exynos board, universal have to use another clock. The old arch/arm/kernel/Makefile: obj-$(CONFIG_HAVE_SCHED_CLOCK) += sched_clock.o has become: obj-y += sched_clock.o Thank you, Kyungmin Park On 8/31/12, Barry Song barry.s...@csr.com wrote: From: Barry Song baohua.s...@csr.com Signed-off-by: Barry Song baohua.s...@csr.com --- arch/arm/mach-exynos/Kconfig |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index b5b4c8c..3fd4ab3 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -243,7 +243,6 @@ config MACH_UNIVERSAL_C210 select CPU_EXYNOS4210 select S5P_HRT select CLKSRC_MMIO - select HAVE_SCHED_CLOCK select S5P_GPIO_INT select S5P_DEV_FIMC0 select S5P_DEV_FIMC1 -- 1.7.0.4 -barry -- 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 V4 2/2] video: drm: exynos: Add device tree support
Hi,
On Thu, Sep 6, 2012 at 12:39 AM, Leela Krishna Amudala
l.kris...@samsung.com wrote:
Add device tree based discovery support for DRM-FIMD driver.
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
---
Documentation/devicetree/bindings/fb/drm-fimd.txt | 80 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 95
-
2 files changed, 173 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/fb/drm-fimd.txt
diff --git a/Documentation/devicetree/bindings/fb/drm-fimd.txt
b/Documentation/devicetree/bindings/fb/drm-fimd.txt
new file mode 100644
index 000..4ff1829
--- /dev/null
+++ b/Documentation/devicetree/bindings/fb/drm-fimd.txt
@@ -0,0 +1,80 @@
+* Samsung Display Controller using DRM frame work
+
+The display controller is used to transfer image data from memory to an
+external LCD driver interface. It supports various color formats such as
+rgb and yuv.
+
+Required properties:
+ - compatible: Should be samsung,exynos5-fimd or samsung,exynos4-fb for
Doesn't better to use single word? fimd or fb?. I think 'fb' is used
for framebuffer historically.
but now it's used both fb and drm, so fimd is neutral and architecture
specific.
To do this, Modify arch-exynos first and update it at each drivers it properly.
Thank you,
Kyungmin Park
+ fimd using DRM frame work.
+ - reg: physical base address of the controller and length of memory
+ mapped region.
+ - interrupts: Three interrupts should be specified. The interrupts should be
+ specified in the following order.
+ - VSYNC interrupt
+ - FIFO level interrupt
+ - FIMD System Interrupt
+
+ - samsung,fimd-display: This property should specify the phandle of the
+ display device node which holds the video interface timing with the
+ below mentioned properties.
+
+ - lcd-htiming: Specifies the horizontal timing for the overlay. The
+ horizontal timing includes four parameters in the following order.
+
+ - horizontal back porch (in number of lcd clocks)
+ - horizontal front porch (in number of lcd clocks)
+ - hsync pulse width (in number of lcd clocks)
+ - Display panels X resolution.
+
+ - lcd-vtiming: Specifies the vertical timing for the overlay. The
+ vertical timing includes four parameters in the following order.
+
+ - vertical back porch (in number of lcd lines)
+ - vertical front porch (in number of lcd lines)
+ - vsync pulse width (in number of lcd clocks)
+ - Display panels Y resolution.
+
+
+ - samsung,default-window: Specifies the default window number of the fimd
controller.
+
+ - samsung,fimd-win-bpp: Specifies the bits per pixel.
+
+Optional properties:
+ - samsung,fimd-vidout-rgb: Video output format is RGB.
+ - samsung,fimd-inv-vclk: invert video clock polarity.
+ - samsung,fimd-frame-rate: Number of video frames per second.
+
+Example:
+
+ The following is an example for the fimd controller is split into
+ two portions. The SoC specific portion can be specified in the SoC
+ specific dts file. The board specific portion can be specified in the
+ board specific dts file.
+
+ - SoC Specific portion
+
+ fimd {
+ compatible = samsung,exynos5-fimd;
+ interrupt-parent = combiner;
+ reg = 0x1440 0x4;
+ interrupts = 18 5, 18 4, 18 6;
+ };
+
+ - Board Specific portion
+
+ lcd_fimd0: lcd_panel0 {
+ lcd-htiming = 4 4 4 480;
+ lcd-vtiming = 4 4 4 320;
+ supports-mipi-panel;
+ };
+
+ fimd {
+ samsung,fimd-display = lcd_fimd0;
+ samsung,fimd-vidout-rgb;
+ samsung,fimd-inv-vclk;
+ samsung,fimd-frame-rate = 60;
+ samsung,default-window = 0;
+ samsung,fimd-win-bpp = 32;
+ };
+
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 3701fbe..a4fa8e9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -18,6 +18,7 @@
#include linux/platform_device.h
#include linux/clk.h
#include linux/pm_runtime.h
+#include linux/of.h
#include video/samsung_fimd.h
#include drm/exynos_drm.h
@@ -103,9 +104,18 @@ struct fimd_context {
struct exynos_drm_panel_info *panel;
};
+static const struct of_device_id fimd_dt_match[];
+
static inline struct fimd_driver_data *drm_fimd_get_driver_data(
struct platform_device *pdev)
{
+#ifdef CONFIG_OF
+ if (pdev-dev.of_node) {
+ const struct of_device_id *match;
+ match = of_match_ptr(fimd_dt_match);
+ return (struct fimd_driver_data *)match-data;
+ }
+#endif
return (struct fimd_driver_data
Re: [PATCH 0/5] ARM: EXYNOS: Add secure firmware support
On 9/19/12, Tomasz Figa t.f...@samsung.com wrote: Hi, On Thursday 13 of September 2012 10:13:33 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. This is a continuation of the patch series by Kyungmin Park: [PATCH v5 1/2] ARM: Make a compile firmware conditionally http://thread.gmane.org/gmane.linux.ports.arm.kernel/183607 [PATCH v5 2/2] ARM: EXYNOS: SMC instruction (aka firmware) support http://thread.gmane.org/gmane.linux.ports.arm.kernel/183608/focus=184109 Tomasz Figa (5): ARM: EXYNOS: Add IO mapping for non-secure SYSRAM. ARM: Add interface for registering and calling firmware-specific operations ARM: EXYNOS: Add support for secure monitor calls ARM: EXYNOS: Add support for Exynos secure firmware ARM: EXYNOS: Add secure firmware support to secondary CPU bring-up .../devicetree/bindings/arm/samsung-boards.txt | 8 arch/arm/common/Makefile | 2 + arch/arm/common/firmware.c | 18 arch/arm/include/asm/firmware.h| 30 + arch/arm/mach-exynos/Makefile | 6 +++ arch/arm/mach-exynos/common.c | 34 ++ arch/arm/mach-exynos/common.h | 2 + arch/arm/mach-exynos/exynos-smc.S | 22 + arch/arm/mach-exynos/firmware.c| 52 ++ arch/arm/mach-exynos/include/mach/map.h | 3 ++ arch/arm/mach-exynos/mach-exynos4-dt.c | 1 + arch/arm/mach-exynos/platsmp.c | 8 arch/arm/mach-exynos/smc.h | 31 + arch/arm/plat-samsung/include/plat/map-s5p.h | 1 + 14 files changed, 218 insertions(+) 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 Any further comments for this series? Maybe we could merge it for 3.7? Hi Arnd, Olof, Can you merge it for 3.7? If exynos implementation still has issues, it's okay only merge firmware implementation. Can you give your opinions? Thank you, Kyungmin 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
Re: [PATCH 4/5] ARM: EXYNOS: Add support for Exynos secure firmware
On 9/22/12, Olof Johansson o...@lixom.net wrote:
On Wed, Sep 19, 2012 at 3:10 AM, Tomasz Figa t.f...@samsung.com wrote:
Hi Olof,
On Saturday 15 of September 2012 17:44:55 Olof Johansson wrote:
On Thu, Sep 13, 2012 at 10:13:37AM +0200, Tomasz Figa wrote:
+static void __iomem *exynos_cpu_boot_reg(int cpu)
+{
+ return S5P_VA_SYSRAM_NS + 0x1c + 4*cpu;
+}
This communication area in sysram should probably be seen as a part of
the firmware interface. It should thus be defined as part of the binding
instead, i.e. through a reg property or similar there. That also would
make it easy to convert to using ioremap() instead of iodesc tables,
which always a nice thing.
The problem with SYSRAM_NS is that it might be also used in other code,
not
related to firmware only. I don't know exactly all the use cases for it.
If you don't know the use cases, and the use cases are not in the
kernel tree that we care about here (upstream), then there's really
nothing to worry about. It's after all just a define that's moved to
an ioremap, if there's some out of tree code that needs the old legacy
define then it can be added in whatever out-of-tree code that uses it.
Right?
Now this address is used at cpu boot, cpuidle, inform at this time.
As it touched at several places, it's defined at iodesc. if it changed
with ioremap, it has to export remaped address and each codes should
use it.
As I wrote at cover letter, if you want to use ioremap, it can be
modified. however can you merge firmware codes itself? since ioremap
is not related with trustzone or firmware issues and it's exynos
specific implementation issues. Right?
Thank you,
Kyungmin Park
Is it really a big problem or we could let it be for now, merge the
patches
for firmware and then convert SYSRAM_NS to dynamic mapping when its
situation clarifies?
What do you expect is required to clarify the situation, and when do
you expect that to happen?
-Olof
--
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 2/5] ARM: Add interface for registering and calling firmware-specific operations
On 9/22/12, Olof Johansson o...@lixom.net wrote:
On Thu, Sep 13, 2012 at 10:13:35AM +0200, Tomasz Figa wrote:
Some boards are running with secure firmware running in TrustZone secure
world, which changes the way some things have to be initialized.
This patch adds an interface for platforms to specify available firmware
operations and call them.
A wrapper macro, call_firmware_op(), checks if the operation is provided
and calls it if so, otherwise returns 0.
By default no operations are provided.
This is a follow-up on the patch by Kyungmin Park:
[PATCH v5 1/2] ARM: Make a compile firmware conditionally
http://thread.gmane.org/gmane.linux.ports.arm.kernel/183607/focus=183988
Example of use:
In code using firmware ops:
__raw_writel(virt_to_phys(exynos4_secondary_startup),
CPU1_BOOT_REG);
/* Call Exynos specific smc call */
do_firmware_op(cpu_boot, cpu);
gic_raise_softirq(cpumask_of(cpu), 1);
In board-/platform-specific code:
static int platformX_do_idle(void)
{
/* tell platformX firmware to enter idle */
return 0;
}
static void platformX_cpu_boot(int i)
{
/* tell platformX firmware to boot CPU i */
}
static const struct firmware_ops platformX_firmware_ops __initdata = {
.do_idle= exynos_do_idle,
.cpu_boot = exynos_cpu_boot,
/* cpu_boot_reg not available on platformX */
};
static void __init board_init_early(void)
{
register_firmware_ops(platformX_firmware_ops);
}
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/common/Makefile| 2 ++
arch/arm/common/firmware.c | 18 ++
arch/arm/include/asm/firmware.h | 30 ++
3 files changed, 50 insertions(+)
create mode 100644 arch/arm/common/firmware.c
create mode 100644 arch/arm/include/asm/firmware.h
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index e8a4e58..55d4182 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -2,6 +2,8 @@
# Makefile for the linux kernel.
#
+obj-y += firmware.o
+
obj-$(CONFIG_ARM_GIC) += gic.o
obj-$(CONFIG_ARM_VIC) += vic.o
obj-$(CONFIG_ICST) += icst.o
diff --git a/arch/arm/common/firmware.c b/arch/arm/common/firmware.c
new file mode 100644
index 000..27ddccb
--- /dev/null
+++ b/arch/arm/common/firmware.c
@@ -0,0 +1,18 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics.
+ * Kyungmin Park kyungmin.p...@samsung.com
+ * Tomasz Figa t.f...@samsung.com
+ *
+ * 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/suspend.h
+
+#include asm/firmware.h
+
+static const struct firmware_ops default_firmware_ops;
+
+const struct firmware_ops *firmware_ops = default_firmware_ops;
diff --git a/arch/arm/include/asm/firmware.h
b/arch/arm/include/asm/firmware.h
new file mode 100644
index 000..ed51b02
--- /dev/null
+++ b/arch/arm/include/asm/firmware.h
@@ -0,0 +1,30 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics.
+ * Kyungmin Park kyungmin.p...@samsung.com
+ * Tomasz Figa t.f...@samsung.com
+ *
+ * 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.
+ */
+
+#ifndef __ASM_ARM_FIRMWARE_H
+#define __ASM_ARM_FIRMWARE_H
+
+struct firmware_ops {
+int (*do_idle)(void);
+void (*cpu_boot)(int cpu);
+void __iomem *(*cpu_boot_reg)(int cpu);
+};
+
+extern const struct firmware_ops *firmware_ops;
+
+#define call_firmware_op(op, ...) \
+((firmware_ops-op) ? firmware_ops-op(__VA_ARGS__) : 0)
I think this will cause sparse warnings for call_firmware_op(cpu_boot_reg)
if there are no ops defined, since the '0' isn't annotated as __iomem. And
you can't annotate it since the other function pointers don't need it.
I think you might be better off with stub functions as fallbacks instead of
allowing and checking for NULL here.
do you mean like this?
#Ifdef CONFIG_ARM_FIRMWARE
#define call_firmware_op(op, ...) ((firmware_ops-op) ?
firmware_ops-op(__VA_ARGS__) : 0)
#else
#define call_firmware_op(op, ...) do { } while (0)
#endif
No problem to modify it.
Thank you,
Kyungmin Park
-Olof
--
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
Re: [PATCH 4/5] ARM: EXYNOS: Add support for Exynos secure firmware
On 9/22/12, Olof Johansson o...@lixom.net wrote:
On Fri, Sep 21, 2012 at 10:57 PM, Kyungmin Park
kyungmin.p...@samsung.com wrote:
On 9/22/12, Olof Johansson o...@lixom.net wrote:
On Wed, Sep 19, 2012 at 3:10 AM, Tomasz Figa t.f...@samsung.com wrote:
Hi Olof,
On Saturday 15 of September 2012 17:44:55 Olof Johansson wrote:
On Thu, Sep 13, 2012 at 10:13:37AM +0200, Tomasz Figa wrote:
+static void __iomem *exynos_cpu_boot_reg(int cpu)
+{
+ return S5P_VA_SYSRAM_NS + 0x1c + 4*cpu;
+}
This communication area in sysram should probably be seen as a part of
the firmware interface. It should thus be defined as part of the
binding
instead, i.e. through a reg property or similar there. That also
would
make it easy to convert to using ioremap() instead of iodesc tables,
which always a nice thing.
The problem with SYSRAM_NS is that it might be also used in other code,
not
related to firmware only. I don't know exactly all the use cases for
it.
If you don't know the use cases, and the use cases are not in the
kernel tree that we care about here (upstream), then there's really
nothing to worry about. It's after all just a define that's moved to
an ioremap, if there's some out of tree code that needs the old legacy
define then it can be added in whatever out-of-tree code that uses it.
Right?
Now this address is used at cpu boot, cpuidle, inform at this time.
As it touched at several places, it's defined at iodesc. if it changed
with ioremap, it has to export remaped address and each codes should
use it.
Won't you have to push down all the references to VA_SYSRAM vs
VA_SYSRAM_NS into the firmware interface anyway, since you will need
to use different addresses for whether you have firmware enabled or
not? I.e. you'll have a firmware call at the appropriate level for
the non-trustzone cases that uses the equivalent of VA_SYSRAM, and for
the trustzone firmware op you'll use VA_SYSRAM_NS?
Right, in case of no firmware, it uses VA_SYSRAM, but VA_SYSRAM_NS is
used at firmware case.
As I wrote at cover letter, if you want to use ioremap, it can be
modified. however can you merge firmware codes itself? since ioremap
is not related with trustzone or firmware issues and it's exynos
specific implementation issues. Right?
I'm not quite sure which part you are asking me to merge, if it's the
infrastructure pieces or the exynos-specific pieces.
Either way, one isn't really usable without the other, and it doesn't
make sense to merge code that can't be used. Infrastructure is best
merged together with the first user of it.
Okay, we will fix it.
Thank you,
Kyungmin 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
Re: [PATCH 6/8] arm: exynos: config exynos5 hdmi-hpd gpio
On 10/5/12, Rahul Sharma rahul.sha...@samsung.com wrote:
This patch adds support for the configuration of exynos5 hdmi-hpd gpio.
It sets the gpio fucntion to EINT which is required for recieving
external hpd interrupt in drm hdmi driver.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
arch/arm/mach-exynos/mach-exynos5-dt.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index 003963c..9a6d569 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -11,6 +11,7 @@
#include linux/of_platform.h
#include linux/serial_core.h
+#include linux/gpio.h
#include asm/mach/arch.h
#include asm/hardware/gic.h
@@ -18,6 +19,7 @@
#include plat/cpu.h
#include plat/regs-serial.h
+#include plat/gpio-cfg.h
#include common.h
@@ -81,10 +83,17 @@ static void __init exynos5250_dt_map_io(void)
s3c24xx_init_clocks(2400);
}
+static void smdk_hpd_setup(void)
+{
+ s3c_gpio_cfgpin(EXYNOS5_GPX3(7), S3C_GPIO_SFN(0xf));
+ s3c_gpio_setpull(EXYNOS5_GPX3(7), S3C_GPIO_PULL_DOWN);
+}
these should be described at dts file instead of here. and name is not
good. smdk...
Thank you,
Kyungmin Park
+
static void __init exynos5250_dt_machine_init(void)
{
of_platform_populate(NULL, of_default_bus_match_table,
exynos5250_auxdata_lookup, NULL);
+ smdk_hpd_setup();
}
static char const *exynos5250_dt_compat[] __initdata = {
--
1.7.0.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
Re: [Linaro-mm-sig] [PATCHv9 00/25] Integration of videobuf2 with DMABUF
On 10/10/12, Mauro Carvalho Chehab mche...@redhat.com wrote: Hi, Em Tue, 02 Oct 2012 16:27:11 +0200 Tomasz Stanislawski t.stanisl...@samsung.com escreveu: Hello everyone, This patchset adds support for DMABUF [2] importing and exporting to V4L2 stack. v9: - rebase on 3.6 - change type for fs to __s32 - add support for vb2_ioctl_expbuf - remove patch 'v4l: vb2: add support for DMA_ATTR_NO_KERNEL_MAPPING', it will be posted as a separate patch - fix typos and style in Documentation (from Hans Verkuil) - only vb2-core and vb2-dma-contig selects DMA_SHARED_BUFFER in Kconfig - use data_offset and length while queueing DMABUF - return the most recently used fd at VIDIOC_DQBUF - use (buffer-type, index, plane) tuple instead of mem_offset to identify a for exporting (from Hans Verkuil) - support for DMABUF mmap in vb2-dma-contig (from Laurent Pinchart) - add testing alignment of vaddr and size while verifying userptr against DMA capabilities (from Laurent Pinchart) - substitute VM_DONTDUMP with VM_RESERVED - simplify error handling in vb2_dc_get_dmabuf (from Laurent Pinchart) For now, NACK. See below. Sad news! It's failed to merge by very poor samsung board support at mainline. CC arm samsung mailing list. Thank you, Kyungmin Park I spent 4 days trying to setup an environment that would allow testing DMABUF with video4linux without success (long story, see below). Also, Laurent tried the same without any luck, and it seems that it even corrupted his test machine. Basically Samsung generously donated me two boards that it could be used on this test (Origen and SMDK310). None of them actually worked with the upstream kernel: patches are needed to avoid OOPSes on Origen; both Origen/SMDK310 defconfigs are completely broken, and drivers don't even boot if someone tries to use the Kernel's defconfigs. Even after spending _days_ trying to figure out the needed .config options (as the config files are not easily available), both boards have... issues: - lack of any display output driver at SMDK310; - lack of any network driver at Origen: it seems that none of the available network options on Origen was upstreamed: no Bluetooth, no OTG, no Wifi. The only test I was able to do (yesterday, late night), the DMABUF caused an OOPS at the Origen board. So, for sure it is not ready for upstream. It is now, too late for 3.7. I might consider it to 3.8, if something can be done to fix the existing issues, and setup a proper setup, using the upstream Kernel. Regards, Mauro ___ Linaro-mm-sig mailing list linaro-mm-...@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-mm-sig -- 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 0/6] ARM: EXYNOS: Add secure firmware support
Hi Arnd or Olof, Can you pick up for v3.7? To Tomasz, Can you rebase it on the latest arm-soc tree? Thank you, Kyungmin Park On Tue, Oct 2, 2012 at 6:13 PM, Tomasz Figa t.f...@samsung.com wrote: Hi, On Monday 24 of September 2012 16:28:27 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 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 support for secondary CPU bring-up on Exynos4412 ARM: EXYNOS: Add IO mapping for non-secure SYSRAM. ARM: EXYNOS: Add support for Exynos secure firmware ARM: EXYNOS: Add secure firmware support to secondary CPU bring-up .../devicetree/bindings/arm/samsung-boards.txt | 8 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 | 34 ++ arch/arm/mach-exynos/common.h | 2 + arch/arm/mach-exynos/exynos-smc.S | 22 + arch/arm/mach-exynos/firmware.c| 54 ++ arch/arm/mach-exynos/include/mach/map.h | 3 ++ arch/arm/mach-exynos/mach-exynos4-dt.c | 1 + arch/arm/mach-exynos/platsmp.c | 36 --- arch/arm/mach-exynos/smc.h | 31 + arch/arm/plat-samsung/include/plat/map-s5p.h | 1 + 14 files changed, 243 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 Any comments, nitpicks or acks on this patchset? Best regards, -- Tomasz Figa Samsung Poland RD Center -- 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 v2 00/15] pinctrl: samsung: Usability and extensibiltiy improvements
Hi, On Thu, Oct 11, 2012 at 5:11 PM, Tomasz Figa t.f...@samsung.com wrote: This patch series is a work on improving usability and extensibiltiy of the pinctrl-samsung driver. It consists of three main parts: - improving flexibility of SoC-specific data specification - converting the driver to one GPIO chip and IRQ domain per pin bank - improving wake-up IRQ setup and handling Really good job! and it solved mess GPIOs H/W configurations of Samsung SoC. Basically Samsung SoC GPIOs don't have generic rules. Even worse, pin name is mixed but offset is still increased. With DT support. we can solve this issue and use generic pinctrl drivers. For all series. Reviewed-by: Kyungmin Park kyungmin.p...@samsung.com 1) What the first part does, in addition to various related fixes, is removing any unnecessary static data from pinctrl-exynos driver. This is achieved mostly thanks to assigning pin numbers dynamically, with help of only pin counts of particular banks. It also simplifies adding next SoC variants, since much less static data needs to be specified. 2) The second part attempts to simplify usage of the driver and fix several problems of current implementation, in particular: - Simplifies GPIO pin specification in device tree by using pin namespace local to pin bank instead of local to pin controller, e.g. gpios = gpj0 3 0; instead of gpios = pinctrl0 115 0; - Simplifies GPIO interrupt specification in device tree by using namespace local to pin bank (and equal to GPIO namespace), e.g. interrupt-parent = gpj0; interrupts = 3 0; instead of interrupt-parent = pinctrl0; interrupts = 115 0; - Simplifies internal GPIO pin to bank translation thanks to correspondence of particular GPIO chips to pin banks. This allows to remove the (costly in case of GPIO bit-banging drivers) lookup over all banks to find the one that the pin is from. 3) Third part is focused on removing the hard-coded description of wake-up interrupt layout. It moves wake-up interrupt description to bank struct and device tree, which allows to specify which pin banks support wake-up interrupts and how they are handled (direct or multiplexed/chained). See particular patches for more detailed descriptions and the last patch for updated device tree bindings. Changes since v1: - dropped moving SoC-specific data to device tree (might be added in further patches) - dropped per-bank specification of configuration register offsets (thus limiting scope of the driver to Exynos SoCs; will be added in further patches) Tomasz Figa (15): pinctrl: samsung: Detect and handle unsupported configuration types pinctrl: samsung: Do not pass gpio_chip to pin_to_reg_bank pinctrl: samsung: Assing pin numbers dynamically pinctrl: samsung: Remove static pin enumerations pinctrl: samsung: Distinguish between pin group and bank nodes ARM: dts: exynos4210-pinctrl: Add nodes for pin banks pinctrl: samsung: Match pin banks with their device nodes pinctrl: samsung: Hold pointer to driver data in bank struct pinctrl: samsung: Include bank-specific eint offset in bank struct pinctrl: exynos: Use one IRQ domain per pin bank pinctrl: samsung: Use one GPIO chip per pin bank pinctrl: samsung: Use per-bank IRQ domain for wake-up interrupts pinctrl: exynos: Set pin function to EINT in irq_set_type of wake-up EINT pinctrl: samsung: Add GPIO to IRQ translation Documentation: Update samsung-pinctrl device tree bindings documentation .../bindings/pinctrl/samsung-pinctrl.txt | 118 +-- arch/arm/boot/dts/exynos4210-pinctrl.dtsi | 278 arch/arm/boot/dts/exynos4210.dtsi | 241 +- drivers/pinctrl/pinctrl-exynos.c | 367 ++--- drivers/pinctrl/pinctrl-exynos.h | 170 ++ drivers/pinctrl/pinctrl-samsung.c | 203 drivers/pinctrl/pinctrl-samsung.h | 29 +- 7 files changed, 741 insertions(+), 665 deletions(-) -- 1.7.12 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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 01/15] pinctrl: samsung: Detect and handle unsupported configuration types
Hi Linus, On Thu, Oct 11, 2012 at 10:57 PM, Linus Walleij linus.wall...@linaro.org wrote: On Thu, Oct 11, 2012 at 10:11 AM, Tomasz Figa t.f...@samsung.com wrote: This patch modifies the pinctrl-samsung driver to detect when width of a bit field is set to zero (which means that such configuraton type is not supported) and return an error instead of trying to modify an inexistent register. Signed-off-by: Tomasz Figa t.f...@samsung.com I'm quite happy with these 17 patches, but I'd like to have Thomas Abraham's definitive ACK before I merge anything. Thomas did ACK at [00/17] ... mail. Thank you, Kyungmin Park 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 -- 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] usb: phy: samsung: Introducing usb phy driver for hsotg
+ Tomasz Figa, Acked-by: Kyungmin Park kyungmin.p...@samsung.com On Mon, Oct 15, 2012 at 10:28 PM, Felipe Balbi ba...@ti.com wrote: On Fri, Oct 12, 2012 at 03:45:34PM +0530, Praveen Paneri wrote: platform_set_drvdata() required for driver's remove function, so adding it back. From v6: Added TODO for phy bindings with controller Dropped platform_set_drvdata() from driver probe This driver uses usb_phy interface to interact with s3c-hsotg. Supports phy_init and phy_shutdown functions to enable/disable phy. Tested with smdk6410 and smdkv310. More SoCs can be brought under later. this commit log needs improvement. There are stuff there which shouldn't go to git's history. I would like to get Tested-bys and Acked-by from DT maintainers. Signed-off-by: Praveen Paneri p.pan...@samsung.com Acked-by: Heiko Stuebner he...@sntech.de --- .../devicetree/bindings/usb/samsung-usbphy.txt | 11 + drivers/usb/phy/Kconfig|8 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/samsung-usbphy.c | 357 include/linux/platform_data/samsung-usbphy.h | 27 ++ 5 files changed, 404 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/samsung-usbphy.txt create mode 100644 drivers/usb/phy/samsung-usbphy.c create mode 100644 include/linux/platform_data/samsung-usbphy.h diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt new file mode 100644 index 000..7b26e2d --- /dev/null +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt @@ -0,0 +1,11 @@ +* Samsung's usb phy transceiver + +The Samsung's phy transceiver is used for controlling usb otg phy for +s3c-hsotg usb device controller. +TODO: Adding the PHY binding with controller(s) according to the under +developement generic PHY driver. + +Required properties: +- compatible : should be samsung,exynos4210-usbphy +- reg : base physical address of the phy registers and length of memory mapped + region. diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 63c339b..313685f 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -32,3 +32,11 @@ config MV_U3D_PHY help Enable this to support Marvell USB 3.0 phy controller for Marvell SoC. + +config SAMSUNG_USBPHY + bool Samsung USB PHY controller Driver + depends on USB_S3C_HSOTG + select USB_OTG_UTILS + help + Enable this to support Samsung USB phy controller for samsung + SoCs. diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile index b069f29..55dcfc1 100644 --- a/drivers/usb/phy/Makefile +++ b/drivers/usb/phy/Makefile @@ -8,3 +8,4 @@ obj-$(CONFIG_OMAP_USB2) += omap-usb2.o obj-$(CONFIG_USB_ISP1301)+= isp1301.o obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o +obj-$(CONFIG_SAMSUNG_USBPHY) += samsung-usbphy.o diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung-usbphy.c new file mode 100644 index 000..14c182f --- /dev/null +++ b/drivers/usb/phy/samsung-usbphy.c @@ -0,0 +1,357 @@ +/* linux/drivers/usb/phy/samsung-usbphy.c + * + * Copyright (c) 2012 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * Author: Praveen Paneri p.pan...@samsung.com + * + * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG controller + * + * 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. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include linux/module.h +#include linux/platform_device.h +#include linux/clk.h +#include linux/delay.h +#include linux/err.h +#include linux/io.h +#include linux/of.h +#include linux/usb/otg.h +#include linux/platform_data/samsung-usbphy.h + +/* Register definitions */ + +#define S3C_PHYPWR (0x00) + +#define S3C_PHYPWR_NORMAL_MASK (0x19 0) +#define S3C_PHYPWR_OTG_DISABLE (1 4) +#define S3C_PHYPWR_ANALOG_POWERDOWN (1 3) +#define S3C_PHYPWR_FORCE_SUSPEND (1 1) +/* For Exynos4 */ +#define EXYNOS4_PHYPWR_NORMAL_MASK (0x39 0) +#define EXYNOS4_PHYPWR_SLEEP (1 5) + +#define S3C_PHYCLK (0x04) + +#define S3C_PHYCLK_MODE_SERIAL (1 6) +#define S3C_PHYCLK_EXT_OSC (1 5) +#define
Re: [PATCH v3 0/6] arm: exynos: add dt based support for exynos5 hdmi
Hi, It's common case, one topic but two different tree. So I suggest merge it at samsung sub-soc tree and drm parts will be merged after arm-soc tree is merged. since arm-soc tree collect arm soc-soc and merged early at merge window. then drm tree will be merged later. Until that time, drm patches are hold only at local git. How do you think? Thank you, Kyungmin Park On 10/16/12, Rahul Sharma r.sh.o...@gmail.com wrote: Hi Mr. Park, Mr. Kim, I had a suggestion here from Tomasz about dividing this patch-set into 2 portions: 1) DT related (patches 1-4) for samsung-dt branch. 2) Clocks, Arch data related to Exynos5. (patches 5,6) for exynos-drm-fixes branch. Rationale behind this is kgene tree with all 6 patches applied will have broken drm exynos4 and incomplete drm exynos5. I want to know your opinion on this. regards, Rahul Sharma On Tue, Oct 16, 2012 at 3:01 PM, Tomasz Figa t.f...@samsung.com wrote: Hi Rahul, On Tuesday 16 of October 2012 05:00:28 Rahul Sharma wrote: This patch set adds the DT based support for Samsung's Exynos5250. It adds device tree nodes for hdmi, mixer, hdmiphy and hdmiddc. The name of these devices are changed to the one matching with drivers. Exynos-drm and exynos hdmi-drm-commmon devices are removed from machine init code. Exynos-drm and exynos hdmi-drm-commmon devices are removed from machine init code. Patch set which adds this code is posted to dri-devel list at http://comments.gmane.org/gmane.comp.video.dri.devel/75121. This patchset is based on linux v3.6-rc6, branch v3.7-next/dt-samsung at git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git v1: - dropped patch for hpd gpio initialisation from machine init. - dropped patch for platform device registration. - removed platform device registration from non-dt platforms. v2: - removed version information from hdmi, mixer dt nodes. - added DT binding documentation for hdmi, mixer, hdmiphy and hdmiddc. v3: - corrected indentations. - changed dt node names to name@address format. Rahul Sharma (6): dts: exynos: add device tree support for exynos5 hdmi dts: exynos: add device tree support for exynos5 mixer dts: exynos: add device tree support for exynos5 hdmiphy dts: exynos: add device tree support for exynos5 hdmiddc arm: exynos: add clocks for exynos5 hdmi arm: exynos: removing exynos-drm device registration from non-dt platforms .../devicetree/bindings/drm/exynos/hdmi.txt | 22 +++ .../devicetree/bindings/drm/exynos/hdmiddc.txt | 12 .../devicetree/bindings/drm/exynos/hdmiphy.txt | 12 .../devicetree/bindings/drm/exynos/mixer.txt | 15 ++ arch/arm/boot/dts/exynos5250-smdk5250.dts | 24 +++- arch/arm/boot/dts/exynos5250.dtsi | 20 + arch/arm/mach-exynos/Makefile | 1 - arch/arm/mach-exynos/clock-exynos5.c | 14 - arch/arm/mach-exynos/dev-drm.c | 29 arch/arm/mach-exynos/include/mach/map.h | 2 + arch/arm/mach-exynos/mach-exynos5-dt.c | 8 + arch/arm/mach-exynos/mach-nuri.c | 3 -- arch/arm/mach-exynos/mach-origen.c | 3 -- arch/arm/mach-exynos/mach-smdk4x12.c | 3 -- arch/arm/mach-exynos/mach-smdkv310.c | 3 -- arch/arm/mach-exynos/mach-universal_c210.c | 3 -- arch/arm/plat-samsung/include/plat/devs.h | 2 - 17 files changed, 126 insertions(+), 50 deletions(-) create mode 100644 Documentation/devicetree/bindings/drm/exynos/hdmi.txt create mode 100644 Documentation/devicetree/bindings/drm/exynos/hdmiddc.txt create mode 100644 Documentation/devicetree/bindings/drm/exynos/hdmiphy.txt create mode 100644 Documentation/devicetree/bindings/drm/exynos/mixer.txt delete mode 100644 arch/arm/mach-exynos/dev-drm.c The patches look fine, but Kukjin's tree doesn't contain all the dependencies for them to be usable. Shouldn't they be based on exynos-drm-next branch of Kyungmin's tree at infradead instead: http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/exynos-drm-next Best regards, -- Tomasz Figa Samsung Poland RD Center -- 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] ARM: EXYNOS: exynos4-dt: Set .smp field of machine descriptor
+ Arnd, Olof,
Tomasz,
I think it's better to add arm-soc maintainers at CC when send the patches.
Samsung patches doesn't handled or merged with proper time.
Thank you,
Kyungmin Park
On 10/22/12, Tomasz Figa tomasz.f...@gmail.com wrote:
On Friday 12 of October 2012 11:49:38 Tomasz Figa wrote:
This patch adds missing initializer of .smp field of machine descriptor
of Exynos 4 DT machine.
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/mach-exynos/mach-exynos4-dt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c
b/arch/arm/mach-exynos/mach-exynos4-dt.c index 7222e3c..d6bdcfb 100644
--- a/arch/arm/mach-exynos/mach-exynos4-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
@@ -119,6 +119,7 @@ static char const *exynos4_dt_compat[] __initdata =
{
DT_MACHINE_START(EXYNOS4210_DT, Samsung Exynos4 (Flattened Device
Tree)) /* Maintainer: Thomas Abraham thomas.abra...@linaro.org */
+.smp= smp_ops(exynos_smp_ops),
.init_irq = exynos4_init_irq,
.map_io = exynos4_dt_map_io,
.handle_irq = gic_handle_irq,
Ping. I think this should be considered a fix.
Best regards,
Tomasz Figa
--
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 3/4] pinctrl: samsung: Add support for Exynos4x12
On 10/29/12, Linus Walleij linus.wall...@linaro.org wrote: On Wed, Oct 24, 2012 at 4:37 PM, Tomasz Figa t.f...@samsung.com wrote: This patch extends the driver with any necessary SoC-specific definitions to support Exynos4x12 SoCs. Signed-off-by: Tomasz Figa t.f...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Acked-by: Linus Walleij linus.wall...@linaro.org I guess you need all of this to go into my Samsung branch? I need and ACK from the Samsung maintainer and preferably Thomas A as well. Hi, Now we're trying to send the standalone patches to avoid the conflict. and hope to merge patches via proper subsystem. In this case, pinctl. Thank you, Kyungmin Park Yours, Linus Walleij ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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
On Fri, Nov 9, 2012 at 8:54 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Tue, Oct 30, 2012 at 10:27:32AM +0530, Praveen Paneri wrote: Changes from v6: Modified register definitions according to the existing ones. Changed default PHY clk selection for SoCs. Improved binding text and rebased to the latest usb-next. Changes from v5: Moved clk_get() to driver's probe function. Now reference clock frequency selection value is stored in samsung_usbphy structure for later use. Used IS_ENABLED() instead of #ifdef in samsung_usbphy_get_driver_data(). Changes from v4: Moved header file contents to driver's source file Removed unnecessary print message from driver's probe function Dropped the Free Software Foundation address from the header Changed the platform data code to use __initdata Changes from v3: Replaced susbsys_initcall()/module_exit() by module_platform_driver(). Accordingly in the hsotg driver returned -EPROBE_DEFER until phy driver is registered Removed unnecessary devm_usb_put_phy() call from the hsotg driver remove. Changes from v2: Changed the driver filenames to samsung-usbphy Changed 's3c' to 'samsung' for platform device as well as platform data Moved platform data structure to a separate file Rectified coding style related errors Changes from v1: Rebased patches to latest usb-next branch Changed the name 'sec_usbphy' to 'samsung_usbphy' This patch set introduces a phy driver for samsung SoCs. It uses the existing transceiver infrastructure to provide phy control functions. Use of this driver can be extended for usb host phy as well. Over the period of time all the phy related code for most of the samsung SoCs can be integrated here. Removing the existing phy code from mach-s3c64xx. Same can be done for other SoCs when they start supporting this phy driver. This driver is tested with smdk6410 and Exynos4210(with DT). Praveen Paneri (5): usb: phy: samsung: Introducing usb phy driver for hsotg usb: s3c-hsotg: Adding phy driver support For usb parts: Acked-by: Kyungmin Park kyungmin.p...@samsung.com ARM: S3C64XX: Removing old phy setup code ARM: S3C64XX: Enabling samsung-usbphy driver ARM: Exynos4210: Enabling samsung-usbphy driver guys I can't wait any longer. If I don't get proper Acks today, I will go ahead without all the PHY changes from Samsung :-s To Praveen, To remove these dependency and merge issue, please send patches for each subsystem. In this case, usb patches for usb tree and others are for arm arch. Thank you, Kyungmin Park -- balbi ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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: Exynos: Remove unused non-dt support for dwmci controller
On 11/26/12, Thomas Abraham thomas.abra...@linaro.org wrote:
With device tree support enabled for dwmci controller, the unused non-dt
support
for dwmci controller can be removed.
Are there no problem to use legacy board? e.g., universal_c210.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
arch/arm/mach-exynos/Makefile |1 -
arch/arm/mach-exynos/dev-dwmci.c | 75
-
arch/arm/mach-exynos/include/mach/dwmci.h | 20
3 files changed, 0 insertions(+), 96 deletions(-)
delete mode 100644 arch/arm/mach-exynos/dev-dwmci.c
delete mode 100644 arch/arm/mach-exynos/include/mach/dwmci.h
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index c12ed6a..b189881 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -50,7 +50,6 @@ obj-$(CONFIG_MACH_EXYNOS5_DT) +=
mach-exynos5-dt.o
obj-y+= dev-uart.o
obj-$(CONFIG_ARCH_EXYNOS4) += dev-audio.o
obj-$(CONFIG_EXYNOS4_DEV_AHCI) += dev-ahci.o
-obj-$(CONFIG_EXYNOS4_DEV_DWMCI) += dev-dwmci.o
obj-$(CONFIG_EXYNOS_DEV_DMA) += dma.o
obj-$(CONFIG_EXYNOS4_DEV_USB_OHCI) += dev-ohci.o
obj-$(CONFIG_EXYNOS_DEV_SYSMMU) += dev-sysmmu.o
diff --git a/arch/arm/mach-exynos/dev-dwmci.c
b/arch/arm/mach-exynos/dev-dwmci.c
deleted file mode 100644
index 7903501..000
--- a/arch/arm/mach-exynos/dev-dwmci.c
+++ /dev/null
@@ -1,75 +0,0 @@
-/*
- * linux/arch/arm/mach-exynos4/dev-dwmci.c
- *
- * Copyright (c) 2011 Samsung Electronics Co., Ltd.
- * http://www.samsung.com
- *
- * Platform device for Synopsys DesignWare Mobile Storage IP
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-
-#include linux/kernel.h
-#include linux/dma-mapping.h
-#include linux/platform_device.h
-#include linux/interrupt.h
-#include linux/ioport.h
-#include linux/mmc/dw_mmc.h
-
-#include plat/devs.h
-
-#include mach/map.h
-
-static int exynos4_dwmci_get_bus_wd(u32 slot_id)
-{
- return 4;
-}
-
-static int exynos4_dwmci_init(u32 slot_id, irq_handler_t handler, void
*data)
-{
- return 0;
-}
-
-static struct resource exynos4_dwmci_resource[] = {
- [0] = DEFINE_RES_MEM(EXYNOS4_PA_DWMCI, SZ_4K),
- [1] = DEFINE_RES_IRQ(EXYNOS4_IRQ_DWMCI),
-};
-
-static struct dw_mci_board exynos4_dwci_pdata = {
- .num_slots = 1,
- .quirks = DW_MCI_QUIRK_BROKEN_CARD_DETECTION,
- .bus_hz = 80 * 1000 * 1000,
- .detect_delay_ms= 200,
- .init = exynos4_dwmci_init,
- .get_bus_wd = exynos4_dwmci_get_bus_wd,
-};
-
-static u64 exynos4_dwmci_dmamask = DMA_BIT_MASK(32);
-
-struct platform_device exynos4_device_dwmci = {
- .name = dw_mmc,
- .id = -1,
- .num_resources = ARRAY_SIZE(exynos4_dwmci_resource),
- .resource = exynos4_dwmci_resource,
- .dev= {
- .dma_mask = exynos4_dwmci_dmamask,
- .coherent_dma_mask = DMA_BIT_MASK(32),
- .platform_data = exynos4_dwci_pdata,
- },
-};
-
-void __init exynos4_dwmci_set_platdata(struct dw_mci_board *pd)
-{
- struct dw_mci_board *npd;
-
- npd = s3c_set_platdata(pd, sizeof(struct dw_mci_board),
- exynos4_device_dwmci);
-
- if (!npd-init)
- npd-init = exynos4_dwmci_init;
- if (!npd-get_bus_wd)
- npd-get_bus_wd = exynos4_dwmci_get_bus_wd;
-}
diff --git a/arch/arm/mach-exynos/include/mach/dwmci.h
b/arch/arm/mach-exynos/include/mach/dwmci.h
deleted file mode 100644
index 7ce6574..000
--- a/arch/arm/mach-exynos/include/mach/dwmci.h
+++ /dev/null
@@ -1,20 +0,0 @@
-/* linux/arch/arm/mach-exynos4/include/mach/dwmci.h
- *
- * Copyright (c) 2011 Samsung Electronics Co., Ltd.
- * http://www.samsung.com/
- *
- * Synopsys DesignWare Mobile Storage for EXYNOS4210
- *
- * 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.
- */
-
-#ifndef __ASM_ARM_ARCH_DWMCI_H
-#define __ASM_ARM_ARCH_DWMCI_H __FILE__
-
-#include linux/mmc/dw_mmc.h
-
-extern void exynos4_dwmci_set_platdata(struct dw_mci_board *pd);
-
-#endif /* __ASM_ARM_ARCH_DWMCI_H */
--
1.7.5.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from
Re: [PATCH] ARM: dts: add initial dts file for ORIGEN4QUAD
Hi,
On 11/26/12, chlrb...@gmail.com chlrb...@gmail.com wrote:
From: Kyuho Choi kh.c...@insignal.co.kr
This patch adds initial dts file for ORIGEN4QUAD board.
ORIGEN4QUAD board based on Samsung EXYNOS4412 SoC.
More properties will be added later.
Signed-off-by: Kyuho Choi kh.c...@insignal.co.kr
---
arch/arm/boot/dts/exynos4412-origen4quad.dts | 45
++
1 files changed, 45 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos4412-origen4quad.dts
diff --git a/arch/arm/boot/dts/exynos4412-origen4quad.dts
b/arch/arm/boot/dts/exynos4412-origen4quad.dts
new file mode 100644
index 000..390a2ab
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4412-origen4quad.dts
@@ -0,0 +1,45 @@
+/*
+ * Samsung's Exynos4412 based Origen4Quad board device tree source
+ *
+ * Copyright (c) 2012-2013 Isnignal Co., Ltd.
+ * http://www.insignal.co.kr
+ *
+ * Device tree source file for Insignal's Origen4Quad board which is based
on
+ * Samsung's Exynos4412 SoC.
+ *
+ * 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.
+*/
+
+/dts-v1/;
+/include/ exynos4412.dtsi
+
+/ {
+ model = Insignal Origen4Quad board based on Exynos4412;
+ compatible = insignal,origen4quad, samsung,exynos4412;
+
+ memory {
+ reg = 0x4000 0x4000;
+ };
does it test to boot with this dts file?
does it support 1GiB memory section?
Thank you,
Kyungmin Park
+
+ chosen {
+ bootargs =root=/dev/ram0 rw ramdisk=32768 initrd=0x4100,32M
console=ttySAC2,115200 init=/linuxrc;
+ };
+
+ serial@1380 {
+ status = okay;
+ };
+
+ serial@1381 {
+ status = okay;
+ };
+
+ serial@1382 {
+ status = okay;
+ };
+
+ serial@1383 {
+ status = okay;
+ };
+};
--
1.7.5.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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] i2c-s3c2410: Leave the bus disabled unless it is in use
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
On Thu, Nov 29, 2012 at 2:05 PM, Naveen Krishna Chatradhi
ch.nav...@samsung.com wrote:
From: Simon Glass s...@chromium.org
There is a rather odd feature of the exynos i2c controller that if it
is left enabled, it can lock itself up with the clk line held low.
This makes the bus unusable.
Unfortunately, the s3c24xx_i2c_set_master() function does not notice
this, and reports a timeout. From then on the bus cannot be used until
the AP is rebooted.
The problem happens when any sort of interrupt occurs (e.g. due to a
bus transition) when we are not in the middle of a transaction. We
have seen many instances of this when U-Boot leaves the bus apparently
happy, but Linux cannot access it.
The current code is therefore pretty fragile.
This fixes things by leaving the bus disabled unless we are actually
in a transaction. We enable the bus at the start of the transaction and
disable it at the end. That way we won't get interrupts and will not
lock up the bus.
It might be possible to clear pending interrupts on start-up, but this
seems to be a more robust solution. We can't service interrupts when
we are not in a transaction, and anyway would rather not lock up the
bus while we try.
Signed-off-by: Simon Glass s...@chromium.org
Cc: Grant Grundler grund...@chromium.org
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---
drivers/i2c/busses/i2c-s3c2410.c | 37 +
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c
b/drivers/i2c/busses/i2c-s3c2410.c
index e93e7d6..2fd346d 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -186,6 +186,31 @@ static inline void s3c24xx_i2c_enable_irq(struct
s3c24xx_i2c *i2c)
writel(tmp | S3C2410_IICCON_IRQEN, i2c-regs + S3C2410_IICCON);
}
+/*
+ * Disable the bus so that we won't get any interrupts from now on, or try
+ * to drive any lines. This is the default state when we don't have
+ * anything to send/receive.
+ *
+ * If there is an event on the bus, or we have a pre-existing event at
+ * kernel boot time, we may not notice the event and the I2C controller
+ * will lock the bus with the I2C clock line low indefinitely.
+ */
+static inline void s3c24xx_i2c_disable_bus(struct s3c24xx_i2c *i2c)
+{
+ unsigned long tmp;
+
+ /* Stop driving the I2C pins */
+ tmp = readl(i2c-regs + S3C2410_IICSTAT);
+ tmp = ~S3C2410_IICSTAT_TXRXEN;
+ writel(tmp, i2c-regs + S3C2410_IICSTAT);
+
+ /* We don't expect any interrupts now, and don't want send acks */
+ tmp = readl(i2c-regs + S3C2410_IICCON);
+ tmp = ~(S3C2410_IICCON_IRQEN | S3C2410_IICCON_IRQPEND |
+ S3C2410_IICCON_ACKEN);
+ writel(tmp, i2c-regs + S3C2410_IICCON);
+}
+
/* s3c24xx_i2c_message_start
*
@@ -646,7 +671,11 @@ static int s3c24xx_i2c_doxfer(struct s3c24xx_i2c *i2c,
s3c24xx_i2c_wait_idle(i2c);
+ s3c24xx_i2c_disable_bus(i2c);
+
out:
+ i2c-state = STATE_IDLE;
+
return ret;
}
@@ -912,7 +941,6 @@ static void s3c24xx_i2c_dt_gpio_free(struct s3c24xx_i2c
*i2c)
static int s3c24xx_i2c_init(struct s3c24xx_i2c *i2c)
{
- unsigned long iicon = S3C2410_IICCON_IRQEN | S3C2410_IICCON_ACKEN;
struct s3c2410_platform_i2c *pdata;
unsigned int freq;
@@ -926,12 +954,12 @@ static int s3c24xx_i2c_init(struct s3c24xx_i2c *i2c)
dev_info(i2c-dev, slave address 0x%02x\n, pdata-slave_addr);
- writel(iicon, i2c-regs + S3C2410_IICCON);
+ writel(0, i2c-regs + S3C2410_IICCON);
+ writel(0, i2c-regs + S3C2410_IICSTAT);
/* we need to work out the divisors for the clock... */
if (s3c24xx_i2c_clockrate(i2c, freq) != 0) {
- writel(0, i2c-regs + S3C2410_IICCON);
dev_err(i2c-dev, cannot meet bus frequency required\n);
return -EINVAL;
}
@@ -939,7 +967,8 @@ static int s3c24xx_i2c_init(struct s3c24xx_i2c *i2c)
/* todo - check that the i2c lines aren't being dragged anywhere */
dev_info(i2c-dev, bus frequency set to %d KHz\n, freq);
- dev_dbg(i2c-dev, S3C2410_IICCON=0x%02lx\n, iicon);
+ dev_dbg(i2c-dev, S3C2410_IICCON=0x%02x\n,
+ readl(i2c-regs + S3C2410_IICCON));
return 0;
}
--
1.7.9.5
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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] I2C: EXYNOS: Add slave support to i2c
Hi,
On Mon, Dec 3, 2012 at 9:16 PM, Giridhar Maruthy
giridhar.maru...@linaro.org wrote:
This patch adds slave support to i2c. The dt entry i2c-mode
decides at probe time if the controller needs to work in
slave mode and the controller is accordingly programmed.
Signed-off-by: Giridhar Maruthy giridhar.maru...@linaro.org
---
drivers/i2c/busses/i2c-s3c2410.c | 100
++
1 file changed, 68 insertions(+), 32 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c
b/drivers/i2c/busses/i2c-s3c2410.c
index e93e7d6..d83a6d7 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -53,6 +53,9 @@
/* Max time to wait for bus to become idle after a xfer (in us) */
#define S3C2410_IDLE_TIMEOUT 5000
+/* To find the master/slave mode of current controller */
+#define is_master(i2c) (!i2c-i2c_mode)
+
/* i2c controller state */
enum s3c24xx_i2c_state {
STATE_IDLE,
@@ -89,6 +92,8 @@ struct s3c24xx_i2c {
#ifdef CONFIG_CPU_FREQ
struct notifier_block freq_transition;
#endif
+ /* i2c_mode: 0 is for master; and 1 is for slave */
+ unsigned inti2c_mode;
If it's used for master or not, doesn't better to use 'is_master' or
'is_slave'? what's the meaning of 'i2c_mode'?
and
#define is_master(i2c) (i2c-is_master)
Thank you,
Kyungmin Park
};
static struct platform_device_id s3c24xx_driver_ids[] = {
@@ -202,11 +207,21 @@ static void s3c24xx_i2c_message_start(struct
s3c24xx_i2c *i2c,
stat = 0;
stat |= S3C2410_IICSTAT_TXRXEN;
- if (msg-flags I2C_M_RD) {
- stat |= S3C2410_IICSTAT_MASTER_RX;
- addr |= 1;
- } else
- stat |= S3C2410_IICSTAT_MASTER_TX;
+ if (is_master(i2c)) {
+ /* Master mode */
+ if (msg-flags I2C_M_RD) {
+ stat |= S3C2410_IICSTAT_MASTER_RX;
+ addr |= 1;
+ } else
+ stat |= S3C2410_IICSTAT_MASTER_TX;
+ } else {
+ /* Slave mode */
+ if (msg-flags I2C_M_RD) {
+ stat |= S3C2410_IICSTAT_SLAVE_RX;
+ addr |= 1;
+ } else
+ stat |= S3C2410_IICSTAT_SLAVE_TX;
+ }
if (msg-flags I2C_M_REV_DIR_ADDR)
addr ^= 1;
@@ -228,8 +243,10 @@ static void s3c24xx_i2c_message_start(struct
s3c24xx_i2c *i2c,
dev_dbg(i2c-dev, iiccon, %08lx\n, iiccon);
writel(iiccon, i2c-regs + S3C2410_IICCON);
- stat |= S3C2410_IICSTAT_START;
- writel(stat, i2c-regs + S3C2410_IICSTAT);
+ if (is_master(i2c)) {
+ stat |= S3C2410_IICSTAT_START;
+ writel(stat, i2c-regs + S3C2410_IICSTAT);
+ }
}
static inline void s3c24xx_i2c_stop(struct s3c24xx_i2c *i2c, int ret)
@@ -272,14 +289,19 @@ static inline void s3c24xx_i2c_stop(struct s3c24xx_i2c
*i2c, int ret)
* devices, the host as Master and the HDMIPHY device as the slave.
* Skipping the STOP condition has been tested on this bus and
works.
*/
- if (i2c-quirks QUIRK_HDMIPHY) {
- /* Stop driving the I2C pins */
- iicstat = ~S3C2410_IICSTAT_TXRXEN;
- } else {
- /* stop the transfer */
- iicstat = ~S3C2410_IICSTAT_START;
+ if (is_master(i2c)) {
+ if (i2c-quirks QUIRK_HDMIPHY) {
+ /* Stop driving the I2C pins */
+ iicstat = ~S3C2410_IICSTAT_TXRXEN;
+ } else {
+ /* stop the transfer */
+ if (is_master(i2c)) {
+ /* Start/Stop required only for master */
+ iicstat = ~S3C2410_IICSTAT_START;
+ }
+ }
+ writel(iicstat, i2c-regs + S3C2410_IICSTAT);
}
- writel(iicstat, i2c-regs + S3C2410_IICSTAT);
i2c-state = STATE_STOP;
@@ -348,7 +370,8 @@ static int i2c_s3c_irq_nextbyte(struct s3c24xx_i2c *i2c,
unsigned long iicstat)
*/
if (iicstat S3C2410_IICSTAT_LASTBIT
- !(i2c-msg-flags I2C_M_IGNORE_NAK)) {
+ !(i2c-msg-flags I2C_M_IGNORE_NAK)
+ is_master(i2c)) {
/* ack was not received... */
dev_dbg(i2c-dev, ack was not received\n);
@@ -380,7 +403,7 @@ static int i2c_s3c_irq_nextbyte(struct s3c24xx_i2c *i2c,
unsigned long iicstat)
* end of the message, and if so, work out what to do
*/
- if (!(i2c-msg-flags I2C_M_IGNORE_NAK)) {
+ if (!(i2c-msg-flags I2C_M_IGNORE_NAK) is_master(i2c))
{
if (iicstat S3C2410_IICSTAT_LASTBIT
Re: [clocks] ARM: S3C64XX: Use new clock-clksrc.c code for clocks.
Hi,
On Tue, Dec 1, 2009 at 10:43 AM, Ben Dooks ben-li...@fluff.org wrote:
Move the s3c6400-clock.c implementation over to use the new common
plat-samsung based clock-clksrc.c.
Note, this does not delete the clocks definitions that are now unused
in the regs-clock.h to reduce the quantity of change in this commit.
Based on original patches by Harald Welte.
Signed-off-by: Ben Dooks ben-li...@fluff.org
---
arch/arm/plat-s3c64xx/Kconfig | 1 +
arch/arm/plat-s3c64xx/s3c6400-clock.c | 241
++---
2 files changed, 40 insertions(+), 202 deletions(-)
diff --git a/arch/arm/plat-s3c64xx/Kconfig b/arch/arm/plat-s3c64xx/Kconfig
index bcfa778..f029697 100644
--- a/arch/arm/plat-s3c64xx/Kconfig
+++ b/arch/arm/plat-s3c64xx/Kconfig
@@ -15,6 +15,7 @@ config PLAT_S3C64XX
select ARM_VIC
select NO_IOPORT
select ARCH_REQUIRE_GPIOLIB
+ select SAMSUNG_CLKSRC
select S3C_GPIO_TRACK
select S3C_GPIO_PULL_UPDOWN
select S3C_GPIO_CFG_S3C24XX
diff --git a/arch/arm/plat-s3c64xx/s3c6400-clock.c
b/arch/arm/plat-s3c64xx/s3c6400-clock.c
index a07e5c9..adc2e0a 100644
--- a/arch/arm/plat-s3c64xx/s3c6400-clock.c
+++ b/arch/arm/plat-s3c64xx/s3c6400-clock.c
@@ -29,6 +29,7 @@
#include plat/regs-clock.h
#include plat/clock.h
+#include plat/clock-clksrc.h
#include plat/cpu.h
#include plat/pll.h
@@ -47,22 +48,6 @@ static struct clk clk_ext_xtal_mux = {
#define clk_fout_mpll clk_mpll
-struct clk_sources {
- unsigned int nr_sources;
- struct clk **sources;
-};
-
-struct clksrc_clk {
- struct clk clk;
- unsigned int mask;
- unsigned int shift;
-
- struct clk_sources *sources;
-
- unsigned int divider_shift;
- void __iomem *reg_divider;
-};
-
static struct clk clk_fout_apll = {
.name = fout_apll,
.id = -1,
@@ -73,7 +58,7 @@ static struct clk *clk_src_apll_list[] = {
[1] = clk_fout_apll,
};
-static struct clk_sources clk_src_apll = {
+static struct clksrc_sources clk_src_apll = {
.sources = clk_src_apll_list,
.nr_sources = ARRAY_SIZE(clk_src_apll_list),
};
@@ -83,8 +68,7 @@ static struct clksrc_clk clk_mout_apll = {
.name = mout_apll,
.id = -1,
},
- .shift = S3C6400_CLKSRC_APLL_MOUT_SHIFT,
- .mask = S3C6400_CLKSRC_APLL_MOUT,
+ .reg_src = { S3C_CLK_SRC, 0, 1 },
What's the meaning of '0', '1'? It's difficult to read and understand,
How about to use the proper macro, I think it means the offset and
required mask bit?
Others are same.
Thank you,
Kyungmin Park
.sources = clk_src_apll,
};
@@ -98,7 +82,7 @@ static struct clk *clk_src_epll_list[] = {
[1] = clk_fout_epll,
};
-static struct clk_sources clk_src_epll = {
+static struct clksrc_sources clk_src_epll = {
.sources = clk_src_epll_list,
.nr_sources = ARRAY_SIZE(clk_src_epll_list),
};
@@ -108,8 +92,7 @@ static struct clksrc_clk clk_mout_epll = {
.name = mout_epll,
.id = -1,
},
- .shift = S3C6400_CLKSRC_EPLL_MOUT_SHIFT,
- .mask = S3C6400_CLKSRC_EPLL_MOUT,
+ .reg_src = { S3C_CLK_SRC, 2, 1 },
.sources = clk_src_epll,
};
@@ -118,7 +101,7 @@ static struct clk *clk_src_mpll_list[] = {
[1] = clk_fout_mpll,
};
-static struct clk_sources clk_src_mpll = {
+static struct clksrc_sources clk_src_mpll = {
.sources = clk_src_mpll_list,
.nr_sources = ARRAY_SIZE(clk_src_mpll_list),
};
@@ -128,8 +111,7 @@ static struct clksrc_clk clk_mout_mpll = {
.name = mout_mpll,
.id = -1,
},
- .shift = S3C6400_CLKSRC_MPLL_MOUT_SHIFT,
- .mask = S3C6400_CLKSRC_MPLL_MOUT,
+ .reg_src = { S3C_CLK_SRC, 1, 1 },
.sources = clk_src_mpll,
};
@@ -218,7 +200,7 @@ static struct clk *clkset_spi_mmc_list[] = {
clk_27m,
};
-static struct clk_sources clkset_spi_mmc = {
+static struct clksrc_sources clkset_spi_mmc = {
.sources = clkset_spi_mmc_list,
.nr_sources = ARRAY_SIZE(clkset_spi_mmc_list),
};
@@ -230,7 +212,7 @@ static struct clk *clkset_irda_list[] = {
clk_27m,
};
-static struct clk_sources clkset_irda = {
+static struct clksrc_sources clkset_irda = {
.sources = clkset_irda_list,
.nr_sources = ARRAY_SIZE(clkset_irda_list),
};
@@ -242,7 +224,7 @@ static struct clk *clkset_uart_list[] = {
NULL
};
-static struct clk_sources clkset_uart = {
+static struct clksrc_sources clkset_uart = {
.sources = clkset_uart_list
Re: [PATCH 09/10] ARM: S5PV210: Add S5PC110 configuration file
On Tue, Jan 19, 2010 at 11:28 AM, Kukjin Kim kgene@samsung.com wrote: This patch adds S5PC110 default configuration file. Signed-off-by: Kukjin Kim kgene@samsung.com --- arch/arm/configs/s5pc110_defconfig | 895 1 files changed, 895 insertions(+), 0 deletions(-) I don't like this ambiguous name. How about specify the correct name such as s5pc110_smdkc110_defconfig. diff --git a/arch/arm/configs/s5pc110_defconfig b/arch/arm/configs/s5pc110_defconfig new file mode 100644 index 000..3956edc --- /dev/null +++ b/arch/arm/configs/s5pc110_defconfig @@ -0,0 +1,895 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.33-rc4 +# Tue Jan 19 11:14:43 2010 +# +CONFIG_ARM=y +CONFIG_SYS_SUPPORTS_APM_EMULATION=y +CONFIG_GENERIC_GPIO=y +CONFIG_NO_IOPORT=y +CONFIG_GENERIC_HARDIRQS=y +CONFIG_STACKTRACE_SUPPORT=y +CONFIG_HAVE_LATENCYTOP_SUPPORT=y +CONFIG_LOCKDEP_SUPPORT=y +CONFIG_TRACE_IRQFLAGS_SUPPORT=y +CONFIG_HARDIRQS_SW_RESEND=y +CONFIG_GENERIC_IRQ_PROBE=y +CONFIG_RWSEM_GENERIC_SPINLOCK=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y +CONFIG_VECTORS_BASE=0x +CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config +CONFIG_CONSTRUCTORS=y + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_LOCK_KERNEL=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION= +CONFIG_LOCALVERSION_AUTO=y +CONFIG_HAVE_KERNEL_GZIP=y +CONFIG_HAVE_KERNEL_LZO=y +CONFIG_KERNEL_GZIP=y +# CONFIG_KERNEL_BZIP2 is not set +# CONFIG_KERNEL_LZMA is not set +# CONFIG_KERNEL_LZO is not set +CONFIG_SWAP=y +# CONFIG_SYSVIPC is not set +# CONFIG_BSD_PROCESS_ACCT is not set + +# +# RCU Subsystem +# +CONFIG_TREE_RCU=y +# CONFIG_TREE_PREEMPT_RCU is not set +# CONFIG_TINY_RCU is not set +# CONFIG_RCU_TRACE is not set +CONFIG_RCU_FANOUT=32 +# CONFIG_RCU_FANOUT_EXACT is not set +# CONFIG_TREE_RCU_TRACE is not set +# CONFIG_IKCONFIG is not set +CONFIG_LOG_BUF_SHIFT=17 +# CONFIG_GROUP_SCHED is not set +# CONFIG_CGROUPS is not set +CONFIG_SYSFS_DEPRECATED=y +CONFIG_SYSFS_DEPRECATED_V2=y +# CONFIG_RELAY is not set +CONFIG_NAMESPACES=y +# CONFIG_UTS_NS is not set +# CONFIG_USER_NS is not set +# CONFIG_PID_NS is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE= +CONFIG_RD_GZIP=y +CONFIG_RD_BZIP2=y +CONFIG_RD_LZMA=y +CONFIG_RD_LZO=y +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_SYSCTL=y +CONFIG_ANON_INODES=y +# CONFIG_EMBEDDED is not set +CONFIG_UID16=y +CONFIG_SYSCTL_SYSCALL=y +CONFIG_KALLSYMS=y +CONFIG_KALLSYMS_ALL=y +# CONFIG_KALLSYMS_EXTRA_PASS is not set +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_EPOLL=y +CONFIG_SIGNALFD=y +CONFIG_TIMERFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_AIO=y + +# +# Kernel Performance Events And Counters +# +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_SLUB_DEBUG=y +CONFIG_COMPAT_BRK=y +# CONFIG_SLAB is not set +CONFIG_SLUB=y +# CONFIG_SLOB is not set +# CONFIG_PROFILING is not set +CONFIG_HAVE_OPROFILE=y +# CONFIG_KPROBES is not set +CONFIG_HAVE_KPROBES=y +CONFIG_HAVE_KRETPROBES=y +CONFIG_HAVE_CLK=y + +# +# GCOV-based kernel profiling +# +# CONFIG_SLOW_WORK is not set +CONFIG_HAVE_GENERIC_DMA_COHERENT=y +CONFIG_SLABINFO=y +CONFIG_RT_MUTEXES=y +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +# CONFIG_MODULE_FORCE_LOAD is not set +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +# CONFIG_MODVERSIONS is not set +# CONFIG_MODULE_SRCVERSION_ALL is not set +CONFIG_BLOCK=y +CONFIG_LBDAF=y +# CONFIG_BLK_DEV_BSG is not set +# CONFIG_BLK_DEV_INTEGRITY is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +# CONFIG_DEFAULT_DEADLINE is not set +CONFIG_DEFAULT_CFQ=y +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED=cfq +# CONFIG_INLINE_SPIN_TRYLOCK is not set +# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set +# CONFIG_INLINE_SPIN_LOCK is not set +# CONFIG_INLINE_SPIN_LOCK_BH is not set +# CONFIG_INLINE_SPIN_LOCK_IRQ is not set +# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set +# CONFIG_INLINE_SPIN_UNLOCK is not set +# CONFIG_INLINE_SPIN_UNLOCK_BH is not set +# CONFIG_INLINE_SPIN_UNLOCK_IRQ is not set +# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set +# CONFIG_INLINE_READ_TRYLOCK is not set +# CONFIG_INLINE_READ_LOCK is not set +# CONFIG_INLINE_READ_LOCK_BH is not set +# CONFIG_INLINE_READ_LOCK_IRQ is not set +# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set +# CONFIG_INLINE_READ_UNLOCK is not set +# CONFIG_INLINE_READ_UNLOCK_BH is not set +# CONFIG_INLINE_READ_UNLOCK_IRQ is not set +# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set +# CONFIG_INLINE_WRITE_TRYLOCK is not set +# CONFIG_INLINE_WRITE_LOCK is not set +# CONFIG_INLINE_WRITE_LOCK_BH is not set +# CONFIG_INLINE_WRITE_LOCK_IRQ is not
Re: [PATCH 11/11] ARM: S5P6440: Remove redundant defines
On Thu, May 13, 2010 at 11:02 AM, Ben Dooks ben-li...@fluff.org wrote:
On Thu, May 13, 2010 at 10:49:29AM +0900, Jassi Brar wrote:
On Thu, May 13, 2010 at 9:28 AM, Kukjin Kim kgene@samsung.com wrote:
From: Thomas Abraham thomas...@samsung.com
--- a/arch/arm/mach-s5p6440/clock.c
+++ b/arch/arm/mach-s5p6440/clock.c
@@ -357,121 +357,121 @@ static struct clk init_clocks_disable[] = {
.id = -1,
.parent = clk_hclk.clk,
.enable = s5p6440_mem_ctrl,
- .ctrlbit = S5P_CLKCON_MEM0_HCLK_NFCON,
+ .ctrlbit = (1 2),
Peculiar. I have never seen defines dropped in favor of magic numbers.
I know it seems a little odd at first, but people seem to be clinging
on to writing it down in a header file and then using it once as some
form of high law of programming. Whilst talking with Kukjin and others
last year and looking at this, we came to the following conclusions
about single-use defines:
1) It takes two lines of code, where one is sufficient.
2) You only have to look in the relevant .c file to find out the
value instead of tracking down a header. This makes it easier
to verify the value against the manual and easier to compare
against simialr code.
Then define it at c code and use the macro. I also don't like the
hard-coded values.
Thank you,
Kyungmin 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
Re: [PATCH v2 11/11] Input: s3c24xx_ts - Uses Feature field instead TYPE for Samsung SoCs
On Fri, May 14, 2010 at 4:25 PM, Kukjin Kim kgene@samsung.com wrote:
From: Naveen Krishna ch.nav...@samsung.com
This patch removes teh TYPE from touchscreen driver for Samsung SoCs
and uses a Feature bit field instead.
Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com
Signed-off-by: Kukjin Kim kgene@samsung.com
---
drivers/input/touchscreen/s3c2410_ts.c | 23 +--
1 files changed, 5 insertions(+), 18 deletions(-)
diff --git a/drivers/input/touchscreen/s3c2410_ts.c
b/drivers/input/touchscreen/s3c2410_ts.c
index 8a970ea..aa43f93 100644
--- a/drivers/input/touchscreen/s3c2410_ts.c
+++ b/drivers/input/touchscreen/s3c2410_ts.c
@@ -55,6 +55,8 @@
S3C2410_ADCTSC_AUTO_PST | \
S3C2410_ADCTSC_XY_PST(0))
+#define FEAT_PEN_IRQ (1 0) /* HAS ADCCLRINTPNDNUP */
It should be go header file for board files to use?
+
/* Per-touchscreen data. */
/**
@@ -81,17 +83,11 @@ struct s3c2410ts {
int irq_tc;
int count;
int shift;
+ int feat;
};
What's the 'feat'? How about to write 'features' exactly.
It's for plurals for future.
Thank you,
Kyungmin Park
static struct s3c2410ts ts;
-enum s3c_cpu_type {
- TYPE_S3C2410,
- TYPE_S3C2440,
- TYPE_S3C64XX, /* S3C64XX, S5P64XX Series */
- TYPE_S5PV210, /* S5PV210 */
-};
-
/**
* get_down - return the down state of the pen
* @data0: The data read from ADCDAT0 register.
@@ -179,7 +175,7 @@ static irqreturn_t stylus_irq(int irq, void *dev_id)
else
dev_info(ts.dev, %s: count=%d\n, __func__, ts.count);
- if (platform_get_device_id(pdev)-driver_data = TYPE_S3C64XX) {
+ if (ts.feat FEAT_PEN_IRQ) {
/* Clear pen down/up interrupt */
writel(0x0, ts.io + S3C64XX_ADCCLRINTPNDNUP);
}
@@ -330,6 +326,7 @@ static int __devinit s3c2410ts_probe(struct
platform_device *pdev)
ts.input-id.version = 0x0102;
ts.shift = info-oversampling_shift;
+ ts.feat = info-feature;
ret = request_irq(ts.irq_tc, stylus_irq, IRQF_DISABLED,
s3c2410_ts_pen, ts.input);
@@ -415,15 +412,6 @@ static struct dev_pm_ops s3c_ts_pmops = {
};
#endif
-static struct platform_device_id s3cts_driver_ids[] = {
- { s3c2410-ts, TYPE_S3C2410 },
- { s3c2440-ts, TYPE_S3C2440 },
- { s3c64xx-ts, TYPE_S3C64XX },
- { s5pv210-ts, TYPE_S5PV210 },
- { }
-};
-MODULE_DEVICE_TABLE(platform, s3cts_driver_ids);
-
static struct platform_driver s3c_ts_driver = {
.driver = {
.name = samsung-ts,
@@ -432,7 +420,6 @@ static struct platform_driver s3c_ts_driver = {
.pm = s3c_ts_pmops,
#endif
},
- .id_table = s3cts_driver_ids,
.probe = s3c2410ts_probe,
.remove = __devexit_p(s3c2410ts_remove),
};
--
1.6.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
--
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] ARM: S5PV210: Add Ext interrupt support.
On Mon, May 17, 2010 at 11:22 AM, Ben Dooks ben-li...@fluff.org wrote: On Mon, May 17, 2010 at 10:16:56AM +0900, Kukjin Kim wrote: From: Jongpill Lee boyko@samsung.com Add support for external interrupts on v210. Signed-off-by: Jongpill Lee boyko@samsung.com Signed-off-by: Pannaga Bhushan p.bhus...@samsung.com Signed-off-by: Kukjin Kim kgene@samsung.com --- arch/arm/mach-s5pv210/Kconfig | 1 + arch/arm/mach-s5pv210/include/mach/irqs.h | 31 ++-- arch/arm/mach-s5pv210/include/mach/regs-gpio.h | 46 + arch/arm/plat-s5p/Kconfig | 5 + arch/arm/plat-s5p/Makefile | 1 + arch/arm/plat-s5p/irq-eint.c | 216 6 files changed, 282 insertions(+), 18 deletions(-) create mode 100644 arch/arm/mach-s5pv210/include/mach/regs-gpio.h create mode 100644 arch/arm/plat-s5p/irq-eint.c diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig index af33a1a..c4c2a7f 100644 --- a/arch/arm/mach-s5pv210/Kconfig +++ b/arch/arm/mach-s5pv210/Kconfig @@ -12,6 +12,7 @@ if ARCH_S5PV210 config CPU_S5PV210 bool select PLAT_S5P + select S5P_EXT_INT help Enable S5PV210 CPU support diff --git a/arch/arm/mach-s5pv210/include/mach/irqs.h b/arch/arm/mach-s5pv210/include/mach/irqs.h index 62c5175..42b9b28 100644 --- a/arch/arm/mach-s5pv210/include/mach/irqs.h +++ b/arch/arm/mach-s5pv210/include/mach/irqs.h @@ -17,22 +17,9 @@ /* VIC0: System, DMA, Timer */ -#define IRQ_EINT0 S5P_IRQ_VIC0(0) -#define IRQ_EINT1 S5P_IRQ_VIC0(1) -#define IRQ_EINT2 S5P_IRQ_VIC0(2) -#define IRQ_EINT3 S5P_IRQ_VIC0(3) -#define IRQ_EINT4 S5P_IRQ_VIC0(4) -#define IRQ_EINT5 S5P_IRQ_VIC0(5) -#define IRQ_EINT6 S5P_IRQ_VIC0(6) -#define IRQ_EINT7 S5P_IRQ_VIC0(7) -#define IRQ_EINT8 S5P_IRQ_VIC0(8) -#define IRQ_EINT9 S5P_IRQ_VIC0(9) -#define IRQ_EINT10 S5P_IRQ_VIC0(10) -#define IRQ_EINT11 S5P_IRQ_VIC0(11) -#define IRQ_EINT12 S5P_IRQ_VIC0(12) -#define IRQ_EINT13 S5P_IRQ_VIC0(13) -#define IRQ_EINT14 S5P_IRQ_VIC0(14) -#define IRQ_EINT15 S5P_IRQ_VIC0(15) +/* Can be used for EINTs 0 to 15 */ +#define IRQ_EINT(x) ((x) + S5P_IRQ_VIC0(0)) + It should be consider the higher interrupt number. As your comment user should use the IRQ_EINT(16) or IRQ_EINT(22). So IRQ_EINT should handle if EINT is grater than 15 This function demuxes the IRQ from the group0 external interrupts, from IRQ_EINT(16) to IRQ_EINT(31). It is designed to be inlined into * the specific handlers s5p_irq_demux_eintX_Y. #define IRQ_EINT(x) ((x) 16 ? S5P_IRQ_VIC0(x) : \ (S5P_IRQ_EINT_BASE + (x)-16)) Thank you, Kyungmin Park #define IRQ_EINT16_31 S5P_IRQ_VIC0(16) #define IRQ_BATF S5P_IRQ_VIC0(17) #define IRQ_MDMA S5P_IRQ_VIC0(18) @@ -137,10 +124,18 @@ #define S5P_IRQ_EINT_BASE (IRQ_VIC_END + 1) #define S5P_EINT(x) ((x) + S5P_IRQ_EINT_BASE) -#define IRQ_EINT(x) S5P_EINT(x) +/* Can be used for EINTs 16 to 31 */ +#define IRQ_EINT_GRP(x) S5P_EINT(x) + +#define EINT_MODE S3C_GPIO_SFN(0xf) /* Set the default NR_IRQS */ -#define NR_IRQS (IRQ_EINT(31) + 1) +#define NR_IRQS (IRQ_EINT_GRP(31) + 1) + +#define EINT_GPIO_REG0(x) S5PV210_GPH0(x) +#define EINT_GPIO_REG1(x) S5PV210_GPH1(x) +#define EINT_GPIO_REG2(x) S5PV210_GPH2(x) +#define EINT_GPIO_REG3(x) S5PV210_GPH3(x) #endif /* ASM_ARCH_IRQS_H */ diff --git a/arch/arm/mach-s5pv210/include/mach/regs-gpio.h b/arch/arm/mach-s5pv210/include/mach/regs-gpio.h new file mode 100644 index 000..fe16292 --- /dev/null +++ b/arch/arm/mach-s5pv210/include/mach/regs-gpio.h @@ -0,0 +1,46 @@ +/* linux/arch/arm/mach-s5pv210/include/mach/regs-gpio.h + * + * Copyright (c) 2010 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * S5PV210 - GPIO (including EINT) register definitions + * + * 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. +*/ + +#ifndef __ASM_ARCH_REGS_GPIO_H +#define __ASM_ARCH_REGS_GPIO_H __FILE__ + +#include mach/map.h + +#define S5PV210_EINT30CON (S5P_VA_GPIO + 0xE00) +#define S5P_EINT_CON(x) (S5PV210_EINT30CON + ((x) * 0x4)) + +#define S5PV210_EINT30FLTCON0 (S5P_VA_GPIO + 0xE80) +#define S5P_EINT_FLTCON(x) (S5PV210_EINT30FLTCON0 + ((x) * 0x4)) + +#define S5PV210_EINT30MASK (S5P_VA_GPIO + 0xF00) +#define S5P_EINT_MASK(x) (S5PV210_EINT30MASK + ((x) * 0x4)) + +#define
Re: [PATCH 1/7] ARM: S5PV210: add support for software reset
Hi, But Samsung SoC hardware engineer recommends to use the reset of watchdog instead of software reset by restriction of Hardware environment. that's optional method for each board. If software reset doesn't work. we can provide the watchdog reset additionally . In our case we use the watchdog reset for other purpose so we don't want to use watchdog reset at normal reset condition. Thank you, Kyungmin 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
Re: [PATCH 05/15] ARM: S5P6442: Change to using s3c_gpio_cfgpin_range()
Hi,
Looks good but I'm afraid it's more difficult to find pin
configuration from typo.
On Fri, May 28, 2010 at 2:56 PM, Ben Dooks ben-li...@fluff.org wrote:
Change the code setting ranges of GPIO pins using s3c_gpio_cfgpin() to
use the recently introduced s3c_gpio_cfgpin_range().
Signed-off-by: Ben Dooks ben-li...@fluff.org
---
arch/arm/mach-s5p6442/dev-audio.c | 30 ++
arch/arm/mach-s5p6442/dev-spi.c | 4 +---
2 files changed, 11 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-s5p6442/dev-audio.c
b/arch/arm/mach-s5p6442/dev-audio.c
index cb801e1..0e57caf 100644
--- a/arch/arm/mach-s5p6442/dev-audio.c
+++ b/arch/arm/mach-s5p6442/dev-audio.c
@@ -21,22 +21,16 @@
static int s5p6442_cfg_i2s(struct platform_device *pdev)
{
+ unsigned int base;
+
/* configure GPIO for i2s port */
switch (pdev-id) {
case 1:
- s3c_gpio_cfgpin(S5P6442_GPC1(0), S3C_GPIO_SFN(2));
- s3c_gpio_cfgpin(S5P6442_GPC1(1), S3C_GPIO_SFN(2));
- s3c_gpio_cfgpin(S5P6442_GPC1(2), S3C_GPIO_SFN(2));
- s3c_gpio_cfgpin(S5P6442_GPC1(3), S3C_GPIO_SFN(2));
- s3c_gpio_cfgpin(S5P6442_GPC1(4), S3C_GPIO_SFN(2));
+ base = S5P6442_GPC1(0);
break;
case -1:
- s3c_gpio_cfgpin(S5P6442_GPC0(0), S3C_GPIO_SFN(2));
- s3c_gpio_cfgpin(S5P6442_GPC0(1), S3C_GPIO_SFN(2));
- s3c_gpio_cfgpin(S5P6442_GPC0(2), S3C_GPIO_SFN(2));
- s3c_gpio_cfgpin(S5P6442_GPC0(3), S3C_GPIO_SFN(2));
- s3c_gpio_cfgpin(S5P6442_GPC0(4), S3C_GPIO_SFN(2));
+ base = S5P6442_GPC0(0);
break;
default:
@@ -44,6 +38,7 @@ static int s5p6442_cfg_i2s(struct platform_device *pdev)
return -EINVAL;
}
+ s3c_gpio_cfgpin_range(base, 5, S3C_GPIO_SFN(2));
return 0;
}
@@ -111,21 +106,15 @@ struct platform_device s5p6442_device_iis1 = {
static int s5p6442_pcm_cfg_gpio(struct platform_device *pdev)
{
+ unsigned int base;
+
switch (pdev-id) {
case 0:
- s3c_gpio_cfgpin(S5P6442_GPC0(0), S3C_GPIO_SFN(3));
- s3c_gpio_cfgpin(S5P6442_GPC0(1), S3C_GPIO_SFN(3));
- s3c_gpio_cfgpin(S5P6442_GPC0(2), S3C_GPIO_SFN(3));
- s3c_gpio_cfgpin(S5P6442_GPC0(3), S3C_GPIO_SFN(3));
- s3c_gpio_cfgpin(S5P6442_GPC0(4), S3C_GPIO_SFN(3));
+ base = S5P6442_GPC0(0);
break;
case 1:
- s3c_gpio_cfgpin(S5P6442_GPC1(0), S3C_GPIO_SFN(3));
- s3c_gpio_cfgpin(S5P6442_GPC1(1), S3C_GPIO_SFN(3));
- s3c_gpio_cfgpin(S5P6442_GPC1(2), S3C_GPIO_SFN(3));
- s3c_gpio_cfgpin(S5P6442_GPC1(3), S3C_GPIO_SFN(3));
- s3c_gpio_cfgpin(S5P6442_GPC1(4), S3C_GPIO_SFN(3));
+ base = S5P6442_GPC1(0);
break;
default:
@@ -133,6 +122,7 @@ static int s5p6442_pcm_cfg_gpio(struct platform_device
*pdev)
return -EINVAL;
}
+ s3c_gpio_cfgpin_range(base, 5, S3C_GPIO_SFN(3));
return 0;
}
diff --git a/arch/arm/mach-s5p6442/dev-spi.c b/arch/arm/mach-s5p6442/dev-spi.c
index 3019952..1c5c170 100644
--- a/arch/arm/mach-s5p6442/dev-spi.c
+++ b/arch/arm/mach-s5p6442/dev-spi.c
@@ -37,9 +37,7 @@ static int s5p6442_spi_cfg_gpio(struct platform_device
*pdev)
{
switch (pdev-id) {
case 0:
- s3c_gpio_cfgpin(S5P6442_GPB(0), S3C_GPIO_SFN(2));
- s3c_gpio_cfgpin(S5P6442_GPB(2), S3C_GPIO_SFN(2));
- s3c_gpio_cfgpin(S5P6442_GPB(3), S3C_GPIO_SFN(2));
+ s3c_gpio_cfgpin_range(S5P6442_GPB(0), 4, S3C_GPIO_SFN(2));
Where's the GPB(1)???
Thank you,
Kyungmin Park
s3c_gpio_setpull(S5P6442_GPB(0), S3C_GPIO_PULL_UP);
s3c_gpio_setpull(S5P6442_GPB(2), S3C_GPIO_PULL_UP);
s3c_gpio_setpull(S5P6442_GPB(3), S3C_GPIO_PULL_UP);
--
1.6.3.3
--
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 v2] ARM: S5PV210: Add Power Management Support
On Tue, Jun 1, 2010 at 1:16 PM, Ben Dooks b...@trinity.fluff.org wrote:
On Tue, Jun 01, 2010 at 12:23:39PM +0900, Kyungmin Park wrote:
On Tue, Jun 1, 2010 at 11:03 AM, Ben Dooks ben-li...@fluff.org wrote:
On Tue, Jun 01, 2010 at 10:36:04AM +0900, Kukjin Kim wrote:
From: Jongpill Lee boyko@samsung.com
This patch adds suspend-to-ram support for S5PV210.
Signed-off-by: Jongpill Lee boyko@samsung.com
Signed-off-by: Kukjin Kim kgene@samsung.com
---
Changes since v1:
1. Fixed comments as per comments from Ben Dooks
2. Removed redunt #if defined(CONFIG_PM)
3. Removed redunt including header files
4. Removed mach/pm.h and plat/pm-s5p.h
5. Moved 's5pv210_core_save' into machine directory
6. Moved sleep.S into machine directory for S5P SoCs compatibility
7. Added CF retension configuration when wake-up
This patch is based on Linus' master (2.6.35-rc1)
arch/arm/mach-s5pv210/Kconfig | 6 +
arch/arm/mach-s5pv210/Makefile | 1 +
arch/arm/mach-s5pv210/include/mach/pm-core.h | 44 ++
arch/arm/mach-s5pv210/include/mach/regs-clock.h | 5 +-
arch/arm/mach-s5pv210/mach-smdkc110.c | 2 +
arch/arm/mach-s5pv210/mach-smdkv210.c | 3 +
arch/arm/mach-s5pv210/pm.c | 180
+++
arch/arm/mach-s5pv210/sleep.S | 166
+
arch/arm/plat-s5p/Makefile | 2 +
arch/arm/plat-s5p/include/plat/irqs.h | 2 +
arch/arm/plat-s5p/irq-pm.c | 108 ++
arch/arm/plat-s5p/pm.c | 52 +++
arch/arm/plat-samsung/pm-gpio.c | 4 +-
13 files changed, 572 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/mach-s5pv210/include/mach/pm-core.h
create mode 100644 arch/arm/mach-s5pv210/pm.c
create mode 100644 arch/arm/mach-s5pv210/sleep.S
create mode 100644 arch/arm/plat-s5p/irq-pm.c
create mode 100644 arch/arm/plat-s5p/pm.c
diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
index 0761eac..86cca1b 100644
--- a/arch/arm/mach-s5pv210/Kconfig
+++ b/arch/arm/mach-s5pv210/Kconfig
@@ -14,6 +14,7 @@ config CPU_S5PV210
select PLAT_S5P
select S3C_PL330_DMA
select S5P_EXT_INT
+ select S5PV210_PM if PM
help
Enable S5PV210 CPU support
@@ -88,4 +89,9 @@ config MACH_SMDKC110
Machine support for Samsung SMDKC110
S5PC110(MCP) is one of package option of S5PV210
+config S5PV210_PM
+ bool
+ help
+ Power Management code common to S5PV210
+
endif
diff --git a/arch/arm/mach-s5pv210/Makefile
b/arch/arm/mach-s5pv210/Makefile
index 30be9a6..59382ec 100644
--- a/arch/arm/mach-s5pv210/Makefile
+++ b/arch/arm/mach-s5pv210/Makefile
@@ -14,6 +14,7 @@ obj- :=
obj-$(CONFIG_CPU_S5PV210) += cpu.o init.o clock.o dma.o gpiolib.o
obj-$(CONFIG_CPU_S5PV210) += setup-i2c0.o
+obj-$(CONFIG_S5PV210_PM) += pm.o sleep.o
# machine support
diff --git a/arch/arm/mach-s5pv210/include/mach/pm-core.h
b/arch/arm/mach-s5pv210/include/mach/pm-core.h
new file mode 100644
index 000..ca3f827
--- /dev/null
+++ b/arch/arm/mach-s5pv210/include/mach/pm-core.h
@@ -0,0 +1,44 @@
+/* linux/arch/arm/mach-s5pv210/include/mach/pm-core.h
+ *
+ * Copyright (c) 2010 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Based on arch/arm/mach-s3c2410/include/mach/pm-core.h,
+ * Copyright 2008 Simtec Electronics
+ * Ben Dooks b...@simtec.co.uk
+ * http://armlinux.simtec.co.uk/
+ *
+ * S5PV210 - PM core support for arch/arm/plat-s5p/pm.c
+ *
+ * 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.
+*/
+
+static inline void s3c_pm_debug_init_uart(void)
+{
+ /* nothing here yet */
+}
+
+static inline void s3c_pm_arch_prepare_irqs(void)
+{
+ __raw_writel(s3c_irqwake_intmask, S5P_WAKEUP_MASK);
+ __raw_writel(s3c_irqwake_eintmask, S5P_EINT_WAKEUP_MASK);
+}
+
+static inline void s3c_pm_arch_stop_clocks(void)
+{
+ /* nothing here yet */
+}
+
+static inline void s3c_pm_arch_show_resume_irqs(void)
+{
+ /* nothing here yet */
+}
+
+static inline void s3c_pm_arch_update_uart(void __iomem *regs,
+ struct pm_uart_save *save)
+{
+ /* nothing here yet */
+}
+
diff --git a/arch/arm/mach-s5pv210/include/mach/regs-clock.h
b/arch/arm/mach-s5pv210/include/mach/regs-clock.h
index 2a25ab4..f4a443a 100644
--- a/arch/arm/mach-s5pv210/include/mach/regs-clock.h
+++ b/arch/arm/mach-s5pv210/include/mach/regs-clock.h
@@ -157,8 +157,11
Re: [PATCH 1/3] s3c64xx: Fix build without SDHCI controllers
On Fri, Jun 11, 2010 at 9:56 AM, Kukjin Kim kgene@samsung.com wrote:
Marek Szyprowski wrote:
This patch fixes the following compilation problem if only NCP machine
is selected:
arch/arm/mach-s3c64xx/s3c6410.c: In function ‘s3c6410_map_io’:
arch/arm/mach-s3c64xx/s3c6410.c:51: error: implicit declaration of function
‘s3c6410_default_sdhci2’
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/plat-samsung/include/plat/sdhci.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/sdhci.h b/arch/arm/plat-
samsung/include/plat/sdhci.h
index 13f9fb2..c2044e5 100644
--- a/arch/arm/plat-samsung/include/plat/sdhci.h
+++ b/arch/arm/plat-samsung/include/plat/sdhci.h
@@ -166,6 +166,7 @@ static inline void s3c6410_default_sdhci2(void) { }
#else
static inline void s3c6410_default_sdhci0(void) { }
static inline void s3c6410_default_sdhci1(void) { }
+static inline void s3c6410_default_sdhci2(void) { }
static inline void s3c6400_default_sdhci0(void) { }
static inline void s3c6400_default_sdhci1(void) { }
--
Maybe missed in Maurus' patch 'S3C64XX: add HSMMC2 support'
commit 92b118f6968ae0788ac659af47b464acd9a754a1
Which kernel tree do you use?
it's against the latest kernel.
Thank you,
Kyungmin Park
Also need 'static inline s3c6400_default_sdhci2(void) { }'
Could you re-submit updated patch including s3c6400_default_sdhci2()?
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, 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
--
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] sdhci-s3c: Add SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK quirk for Samsung SoC
Hi,
On Thu, Jun 10, 2010 at 8:39 PM, Kukjin Kim kgene@samsung.com wrote:
From: Lee Hyuk hyuk1@samsung.com
On Samsung's SDMMC hosts the timeout clock is derivied from the SD
Clock, which is set dynamically.
So, checked 'SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK' quirk and removed
'sdhci_s3c_get_timeout_clk' callback which doesn't need any more.
Signed-off-by: Hyuk Lee hyuk1@samsung.com
Signed-off-by: Kukjin Kim kgene@samsung.com
---
drivers/mmc/host/sdhci-s3c.c | 10 +++---
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index af21792..ca09382 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -110,11 +110,6 @@ static unsigned int sdhci_s3c_get_max_clk(struct
sdhci_host *host)
return max;
}
-static unsigned int sdhci_s3c_get_timeout_clk(struct sdhci_host *host)
-{
- return sdhci_s3c_get_max_clk(host) / 100;
-}
-
/**
* sdhci_s3c_consider_clock - consider one the bus clocks for current setting
* @ourhost: Our SDHCI instance.
@@ -188,7 +183,6 @@ static void sdhci_s3c_set_clock(struct sdhci_host *host,
unsigned int clock)
ourhost-cur_clk = best_src;
host-max_clk = clk_get_rate(clk);
- host-timeout_clk = sdhci_s3c_get_timeout_clk(host);
ctrl = readl(host-ioaddr + S3C_SDHCI_CONTROL2);
ctrl = ~S3C_SDHCI_CTRL2_SELBASECLK_MASK;
@@ -211,7 +205,6 @@ static void sdhci_s3c_set_clock(struct sdhci_host *host,
unsigned int clock)
static struct sdhci_ops sdhci_s3c_ops = {
.get_max_clock = sdhci_s3c_get_max_clk,
- .get_timeout_clock = sdhci_s3c_get_timeout_clk,
.set_clock = sdhci_s3c_set_clock,
};
@@ -335,6 +328,9 @@ static int __devinit sdhci_s3c_probe(struct
platform_device *pdev)
host-quirks |= (SDHCI_QUIRK_32BIT_DMA_ADDR |
SDHCI_QUIRK_32BIT_DMA_SIZE);
+ /* HSMMC on Samsung SoCs uses SDCLK as timeout clock. */
+ host-quirks |= SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK;
How do you know Samsung SoCs use SDCLK in the spec?
Is it also true at s3c64xx series?
Thank you,
Kyungmin Park
+
ret = sdhci_add_host(host);
if (ret) {
dev_err(dev, sdhci_add_host() failed\n);
--
1.6.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
--
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/3] s3c64xx: Fix build without SDHCI controllers
-Original Message-
From: Kukjin Kim [mailto:kgene@samsung.com]
Sent: Friday, June 11, 2010 12:59 PM
To: 'Kyungmin Park'
Cc: 'Marek Szyprowski'; linux-arm-ker...@lists.infradead.org; linux-
samsung-...@vger.kernel.org; linux-...@vger.kernel.org; ben-
li...@fluff.org
Subject: RE: [PATCH 1/3] s3c64xx: Fix build without SDHCI controllers
Kyungmin Park wrote:
On Fri, Jun 11, 2010 at 9:56 AM, Kukjin Kim kgene@samsung.com
wrote:
Marek Szyprowski wrote:
This patch fixes the following compilation problem if only NCP
machine
is selected:
arch/arm/mach-s3c64xx/s3c6410.c: In function ‘s3c6410_map_io’:
arch/arm/mach-s3c64xx/s3c6410.c:51: error: implicit declaration of
function
‘s3c6410_default_sdhci2’
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/plat-samsung/include/plat/sdhci.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/sdhci.h
b/arch/arm/plat-
samsung/include/plat/sdhci.h
index 13f9fb2..c2044e5 100644
--- a/arch/arm/plat-samsung/include/plat/sdhci.h
+++ b/arch/arm/plat-samsung/include/plat/sdhci.h
@@ -166,6 +166,7 @@ static inline void s3c6410_default_sdhci2(void)
{ }
#else
static inline void s3c6410_default_sdhci0(void) { }
static inline void s3c6410_default_sdhci1(void) { }
+static inline void s3c6410_default_sdhci2(void) { }
static inline void s3c6400_default_sdhci0(void) { }
static inline void s3c6400_default_sdhci1(void) { }
--
Maybe missed in Maurus' patch 'S3C64XX: add HSMMC2 support'
commit 92b118f6968ae0788ac659af47b464acd9a754a1
Which kernel tree do you use?
it's against the latest kernel.
Of course, Linus' 35-rc2.
We used 63a07cb64ccc3ceae619d3298545d602ab5ecd38
And there's no s3c6410_default_sdhci2(void) .
Thank you,
Kyungmin Park
Any problem?
Also need 'static inline s3c6400_default_sdhci2(void) { }'
Could you re-submit updated patch including s3c6400_default_sdhci2()?
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, 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/5] sdhci-s3c: depend on plat-samsung
On Fri, Jun 11, 2010 at 2:24 PM, Ben Dooks ben-li...@fluff.org wrote: On Fri, Jun 11, 2010 at 09:29:38AM +0900, Kukjin Kim wrote: Marek Szyprowski wrote: Most Samsung SoC have support for SDHCI block, so make the driver dependent on the Samsung platform instead on listing all SoCs in the Kconfig (and updating it again when support for the new SoC variant is added). Hi, Marek Kyungmin Park already submitted same patch. Hmm, Mr Park and Co really need to learn how to handle the treatment of patches. I'm really disapointed that these patches get submitted without the proper authour accreditation. If this isn't sorted out then I for one will start thinking about giving this stuff an automatic reject. It's just Marek missed the previous my patch, and I reply there's duplicated patch already. Thank you, Kyungmin Park Please ensure that the original authour of a patch is accredited for the work, and the right sign-off and any other ack data is kept with the patch. There's documentation about most of this in the kernel already at Documentation/SubmittingPatches. And Andrew Morton added to the -mm tree. http://www.spinics.net/lists/mm-commits/msg79159.html But, I think your comment is better... Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/mmc/host/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig index e171e77..acf5bf6 100644 --- a/drivers/mmc/host/Kconfig +++ b/drivers/mmc/host/Kconfig @@ -123,7 +123,7 @@ config MMC_SDHCI_PLTFM config MMC_SDHCI_S3C tristate SDHCI support on Samsung S3C SoC - depends on MMC_SDHCI (PLAT_S3C24XX || PLAT_S3C64XX) + depends on MMC_SDHCI PLAT_SAMSUNG help This selects the Secure Digital Host Controller Interface (SDHCI) often referrered to as the HSMMC block in some of the Samsung S3C -- Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- -- Ben Q: What's a light-year? A: One-third less calories than a regular year. ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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] sdhci-s3c: Add SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK quirk for Samsung SoC
On Fri, Jun 11, 2010 at 5:08 PM, Kukjin Kim kgene@samsung.com wrote:
Kyungmin Park wrote:
Hi,
On Thu, Jun 10, 2010 at 8:39 PM, Kukjin Kim kgene@samsung.com wrote:
From: Lee Hyuk hyuk1@samsung.com
On Samsung's SDMMC hosts the timeout clock is derivied from the SD
Clock, which is set dynamically.
So, checked 'SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK' quirk and removed
'sdhci_s3c_get_timeout_clk' callback which doesn't need any more.
Signed-off-by: Hyuk Lee hyuk1@samsung.com
Signed-off-by: Kukjin Kim kgene@samsung.com
---
drivers/mmc/host/sdhci-s3c.c | 10 +++---
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index af21792..ca09382 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -110,11 +110,6 @@ static unsigned int sdhci_s3c_get_max_clk(struct
sdhci_host *host)
return max;
}
-static unsigned int sdhci_s3c_get_timeout_clk(struct sdhci_host *host)
-{
- return sdhci_s3c_get_max_clk(host) / 100;
-}
-
/**
* sdhci_s3c_consider_clock - consider one the bus clocks for current
setting
* @ourhost: Our SDHCI instance.
@@ -188,7 +183,6 @@ static void sdhci_s3c_set_clock(struct sdhci_host
*host,
unsigned int clock)
ourhost-cur_clk = best_src;
host-max_clk = clk_get_rate(clk);
- host-timeout_clk = sdhci_s3c_get_timeout_clk(host);
ctrl = readl(host-ioaddr + S3C_SDHCI_CONTROL2);
ctrl = ~S3C_SDHCI_CTRL2_SELBASECLK_MASK;
@@ -211,7 +205,6 @@ static void sdhci_s3c_set_clock(struct sdhci_host
*host,
unsigned int clock)
static struct sdhci_ops sdhci_s3c_ops = {
.get_max_clock = sdhci_s3c_get_max_clk,
- .get_timeout_clock = sdhci_s3c_get_timeout_clk,
.set_clock = sdhci_s3c_set_clock,
};
@@ -335,6 +328,9 @@ static int __devinit sdhci_s3c_probe(struct
platform_device *pdev)
host-quirks |= (SDHCI_QUIRK_32BIT_DMA_ADDR |
SDHCI_QUIRK_32BIT_DMA_SIZE);
+ /* HSMMC on Samsung SoCs uses SDCLK as timeout clock. */
+ host-quirks |= SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK;
How do you know Samsung SoCs use SDCLK in the spec?
Samsung SoC hardware engineer guided about that.
Of course H/W team know it. they made it. I mean how can we know it at Spec?
If MMC developer don't know the samsung socs well, then how to set it
quirk from Spec.
Thank you,
Kyungmin Park
Is it also true at s3c64xx series?
Yes, of course.
+
ret = sdhci_add_host(host);
if (ret) {
dev_err(dev, sdhci_add_host() failed\n);
--
1.6.2.5
--
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
To unsubscribe from this list: send the line unsubscribe linux-mmc 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 2/2 RE-SEND] ARM: S5PV210: Add support HSMMC on Samsung SMDKV210
Hi
On Mon, Jun 14, 2010 at 4:19 PM, Kukjin Kim kgene@samsung.com wrote:
From: Lee Hyuk hyuk1@samsung.com
This patch adds support HSMMC on Samsung SMDKV210, and gpio configuration for
S5PV210 hsmmc3.
Signed-off-by: Hyuk Lee hyuk1@samsung.com
Signed-off-by: Kukjin Kim kgene@samsung.com
---
Changes since previous patch:
- Adding missed call s5pv210_default_sdhci3() in s5pv210_map_io()
arch/arm/mach-s5pv210/Kconfig|5 +
arch/arm/mach-s5pv210/cpu.c |1 +
arch/arm/mach-s5pv210/include/mach/map.h |1 +
arch/arm/mach-s5pv210/mach-smdkv210.c|4
arch/arm/mach-s5pv210/setup-sdhci-gpio.c | 20
5 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
index 0761eac..6aee967 100644
--- a/arch/arm/mach-s5pv210/Kconfig
+++ b/arch/arm/mach-s5pv210/Kconfig
@@ -72,9 +72,14 @@ config MACH_SMDKV210
select CPU_S5PV210
select ARCH_SPARSEMEM_ENABLE
select SAMSUNG_DEV_ADC
+ select S3C_DEV_HSMMC
+ select S3C_DEV_HSMMC1
+ select S3C_DEV_HSMMC2
+ select S3C_DEV_HSMMC3
select SAMSUNG_DEV_TS
select S3C_DEV_WDT
select HAVE_S3C2410_WATCHDOG
+ select S5PV210_SETUP_SDHCI
help
Machine support for Samsung SMDKV210
diff --git a/arch/arm/mach-s5pv210/cpu.c b/arch/arm/mach-s5pv210/cpu.c
index 411a4a9..765034e 100644
--- a/arch/arm/mach-s5pv210/cpu.c
+++ b/arch/arm/mach-s5pv210/cpu.c
@@ -86,6 +86,7 @@ void __init s5pv210_map_io(void)
s5pv210_default_sdhci0();
s5pv210_default_sdhci1();
s5pv210_default_sdhci2();
+ s5pv210_default_sdhci3();
/* the i2c devices are directly compatible with s3c2440 */
s3c_i2c0_setname(s3c2440-i2c);
diff --git a/arch/arm/mach-s5pv210/include/mach/map.h
b/arch/arm/mach-s5pv210/include/mach/map.h
index 34eb168..fa9d7c2 100644
--- a/arch/arm/mach-s5pv210/include/mach/map.h
+++ b/arch/arm/mach-s5pv210/include/mach/map.h
@@ -97,6 +97,7 @@
#define S3C_PA_HSMMC0 S5PV210_PA_HSMMC(0)
#define S3C_PA_HSMMC1 S5PV210_PA_HSMMC(1)
#define S3C_PA_HSMMC2 S5PV210_PA_HSMMC(2)
+#define S3C_PA_HSMMC3 S5PV210_PA_HSMMC(3)
#define S3C_PA_IIC S5PV210_PA_IIC0
#define S3C_PA_IIC1S5PV210_PA_IIC1
#define S3C_PA_IIC2S5PV210_PA_IIC2
diff --git a/arch/arm/mach-s5pv210/mach-smdkv210.c
b/arch/arm/mach-s5pv210/mach-smdkv210.c
index 0d46279..b08f376 100644
--- a/arch/arm/mach-s5pv210/mach-smdkv210.c
+++ b/arch/arm/mach-s5pv210/mach-smdkv210.c
@@ -77,6 +77,10 @@ static struct platform_device *smdkv210_devices[]
__initdata = {
s5pv210_device_iis0,
s5pv210_device_ac97,
s3c_device_adc,
+ s3c_device_hsmmc0,
+ s3c_device_hsmmc1,
+ s3c_device_hsmmc2,
+ s3c_device_hsmmc3,
s3c_device_ts,
s3c_device_wdt,
};
diff --git a/arch/arm/mach-s5pv210/setup-sdhci-gpio.c
b/arch/arm/mach-s5pv210/setup-sdhci-gpio.c
index fe7d86d..415f62c 100644
--- a/arch/arm/mach-s5pv210/setup-sdhci-gpio.c
+++ b/arch/arm/mach-s5pv210/setup-sdhci-gpio.c
@@ -102,3 +102,23 @@ void s5pv210_setup_sdhci2_cfg_gpio(struct
platform_device *dev, int width)
s3c_gpio_setpull(S5PV210_GPG2(2), S3C_GPIO_PULL_UP);
s3c_gpio_cfgpin(S5PV210_GPG2(2), S3C_GPIO_SFN(2));
}
+
+void s5pv210_setup_sdhci3_cfg_gpio(struct platform_device *dev, int width)
+{
+ unsigned int gpio;
+
+ /* Set all the necessary GPG1[0:2] pins to special-function 2 */
Wrong pin name, GPG3?
+ for (gpio = S5PV210_GPG3(0); gpio S5PV210_GPG3(2); gpio++) {
+ s3c_gpio_cfgpin(gpio, S3C_GPIO_SFN(2));
+ s3c_gpio_setpull(gpio, S3C_GPIO_PULL_NONE);
+ }
+
+ /* Data pin GPG1[3:6] to special-function 2 */
ditto
+ for (gpio = S5PV210_GPG3(3); gpio = S5PV210_GPG3(6); gpio++) {
+ s3c_gpio_cfgpin(gpio, S3C_GPIO_SFN(2));
+ s3c_gpio_setpull(gpio, S3C_GPIO_PULL_NONE);
+ }
+
+ s3c_gpio_setpull(S5PV210_GPG3(2), S3C_GPIO_PULL_UP);
+ s3c_gpio_cfgpin(S5PV210_GPG3(2), S3C_GPIO_SFN(2));
In case of this, how about to use one loop like this.
for (gpio = GPG3(0); gpio = GPG3(7); gpio++)
s3c_gpio_cfgpin(gpio, S3C_GPIO_SFN(2));
since all pins use special function 2.
or others methods are welcome.
To Ben,
When do you apply previous gpio helper functions?
Thank you,
Kyungmin Park
+}
--
1.6.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
--
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_defconfig: Update for removing s5pc110_defconfig
Acked-by: Kyungmin Park kyungmin.p...@samsung.com P.s. How about the define C110_COMMON select to reduce Kconfig lines? in case of c110 has almost same features. sparemem, 24 fb, rtc, and so on. On Wed, Jun 16, 2010 at 8:42 AM, Kukjin Kim kgene@samsung.com wrote: Now that S5PC110 machines and S5PV210 machines can be built into one kernel, update mach-s5pv210/Kconfig and s5pv210_defconfig. Tested on SMDKC110(S5PC110) and SMDKV210(S5PV210). Note that GONI machine ID is not included in the kernel. Created and tested against linux-2.6.35-rc3. Signed-off-by: Kukjin Kim kgene@samsung.com --- arch/arm/configs/s5pc110_defconfig | 924 arch/arm/configs/s5pv210_defconfig | 30 +- arch/arm/mach-s5pv210/Kconfig | 28 +- 3 files changed, 39 insertions(+), 943 deletions(-) delete mode 100644 arch/arm/configs/s5pc110_defconfig diff --git a/arch/arm/configs/s5pc110_defconfig b/arch/arm/configs/s5pc110_defconfig deleted file mode 100644 index c4de360..000 --- a/arch/arm/configs/s5pc110_defconfig +++ /dev/null @@ -1,924 +0,0 @@ -# -# Automatically generated make config: don't edit -# Linux kernel version: 2.6.34 -# Wed May 26 19:04:37 2010 -# -CONFIG_ARM=y -CONFIG_SYS_SUPPORTS_APM_EMULATION=y -CONFIG_GENERIC_GPIO=y -CONFIG_GENERIC_TIME=y -CONFIG_ARCH_USES_GETTIMEOFFSET=y -CONFIG_HAVE_PROC_CPU=y -CONFIG_NO_IOPORT=y -CONFIG_GENERIC_HARDIRQS=y -CONFIG_STACKTRACE_SUPPORT=y -CONFIG_HAVE_LATENCYTOP_SUPPORT=y -CONFIG_LOCKDEP_SUPPORT=y -CONFIG_TRACE_IRQFLAGS_SUPPORT=y -CONFIG_HARDIRQS_SW_RESEND=y -CONFIG_GENERIC_IRQ_PROBE=y -CONFIG_RWSEM_GENERIC_SPINLOCK=y -CONFIG_GENERIC_HWEIGHT=y -CONFIG_GENERIC_CALIBRATE_DELAY=y -CONFIG_NEED_DMA_MAP_STATE=y -CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y -CONFIG_ARM_L1_CACHE_SHIFT_6=y -CONFIG_VECTORS_BASE=0x -CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config -CONFIG_CONSTRUCTORS=y - -# -# General setup -# -CONFIG_EXPERIMENTAL=y -CONFIG_BROKEN_ON_SMP=y -CONFIG_LOCK_KERNEL=y -CONFIG_INIT_ENV_ARG_LIMIT=32 -CONFIG_LOCALVERSION= -CONFIG_LOCALVERSION_AUTO=y -CONFIG_HAVE_KERNEL_GZIP=y -CONFIG_HAVE_KERNEL_LZMA=y -CONFIG_HAVE_KERNEL_LZO=y -CONFIG_KERNEL_GZIP=y -# CONFIG_KERNEL_BZIP2 is not set -# CONFIG_KERNEL_LZMA is not set -# CONFIG_KERNEL_LZO is not set -CONFIG_SWAP=y -# CONFIG_SYSVIPC is not set -# CONFIG_BSD_PROCESS_ACCT is not set - -# -# RCU Subsystem -# -CONFIG_TREE_RCU=y -# CONFIG_TREE_PREEMPT_RCU is not set -# CONFIG_TINY_RCU is not set -# CONFIG_RCU_TRACE is not set -CONFIG_RCU_FANOUT=32 -# CONFIG_RCU_FANOUT_EXACT is not set -# CONFIG_TREE_RCU_TRACE is not set -# CONFIG_IKCONFIG is not set -CONFIG_LOG_BUF_SHIFT=17 -# CONFIG_CGROUPS is not set -CONFIG_SYSFS_DEPRECATED=y -CONFIG_SYSFS_DEPRECATED_V2=y -# CONFIG_RELAY is not set -CONFIG_NAMESPACES=y -# CONFIG_UTS_NS is not set -# CONFIG_USER_NS is not set -# CONFIG_PID_NS is not set -CONFIG_BLK_DEV_INITRD=y -CONFIG_INITRAMFS_SOURCE= -CONFIG_RD_GZIP=y -CONFIG_RD_BZIP2=y -CONFIG_RD_LZMA=y -CONFIG_RD_LZO=y -CONFIG_CC_OPTIMIZE_FOR_SIZE=y -CONFIG_SYSCTL=y -CONFIG_ANON_INODES=y -# CONFIG_EMBEDDED is not set -CONFIG_UID16=y -CONFIG_SYSCTL_SYSCALL=y -CONFIG_KALLSYMS=y -CONFIG_KALLSYMS_ALL=y -# CONFIG_KALLSYMS_EXTRA_PASS is not set -CONFIG_HOTPLUG=y -CONFIG_PRINTK=y -CONFIG_BUG=y -CONFIG_ELF_CORE=y -CONFIG_BASE_FULL=y -CONFIG_FUTEX=y -CONFIG_EPOLL=y -CONFIG_SIGNALFD=y -CONFIG_TIMERFD=y -CONFIG_EVENTFD=y -CONFIG_SHMEM=y -CONFIG_AIO=y -CONFIG_HAVE_PERF_EVENTS=y -CONFIG_PERF_USE_VMALLOC=y - -# -# Kernel Performance Events And Counters -# -# CONFIG_PERF_EVENTS is not set -# CONFIG_PERF_COUNTERS is not set -CONFIG_VM_EVENT_COUNTERS=y -CONFIG_SLUB_DEBUG=y -CONFIG_COMPAT_BRK=y -# CONFIG_SLAB is not set -CONFIG_SLUB=y -# CONFIG_SLOB is not set -# CONFIG_PROFILING is not set -CONFIG_HAVE_OPROFILE=y -# CONFIG_KPROBES is not set -CONFIG_HAVE_KPROBES=y -CONFIG_HAVE_KRETPROBES=y -CONFIG_HAVE_CLK=y - -# -# GCOV-based kernel profiling -# -# CONFIG_SLOW_WORK is not set -CONFIG_HAVE_GENERIC_DMA_COHERENT=y -CONFIG_SLABINFO=y -CONFIG_RT_MUTEXES=y -CONFIG_BASE_SMALL=0 -CONFIG_MODULES=y -# CONFIG_MODULE_FORCE_LOAD is not set -CONFIG_MODULE_UNLOAD=y -# CONFIG_MODULE_FORCE_UNLOAD is not set -# CONFIG_MODVERSIONS is not set -# CONFIG_MODULE_SRCVERSION_ALL is not set -CONFIG_BLOCK=y -CONFIG_LBDAF=y -# CONFIG_BLK_DEV_BSG is not set -# CONFIG_BLK_DEV_INTEGRITY is not set - -# -# IO Schedulers -# -CONFIG_IOSCHED_NOOP=y -CONFIG_IOSCHED_DEADLINE=y -CONFIG_IOSCHED_CFQ=y -# CONFIG_DEFAULT_DEADLINE is not set -CONFIG_DEFAULT_CFQ=y -# CONFIG_DEFAULT_NOOP is not set -CONFIG_DEFAULT_IOSCHED=cfq -# CONFIG_INLINE_SPIN_TRYLOCK is not set -# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set -# CONFIG_INLINE_SPIN_LOCK is not set -# CONFIG_INLINE_SPIN_LOCK_BH is not set -# CONFIG_INLINE_SPIN_LOCK_IRQ is not set -# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
Samsung SoCs: preparation for single kernel
To Ben,
I really need single kernel for s5pc110 (cortex A8) and s5pc210
(cortex A9) at least.
Fortunately arm move to these approaches recently. but current Samsung
SoCs not prepare these one.
So I wonder do you have a plan or how to address these issues?
How to assign the address at resources and use it at runtime?
Personally I want to use cpu_is_*. but you reject it to use.
Other way is that we can create the base address variables and assign
it at init time.
Please give your opinions.
Thank you,
Kyungmin Park
e.g., cpu_is_* usage at OMAP tree
static void omap_init_mcspi(void)
{
if (cpu_is_omap44xx())
omap4_mcspi_fixup();
platform_device_register(omap2_mcspi1);
platform_device_register(omap2_mcspi2);
if (cpu_is_omap2430() || cpu_is_omap343x() || cpu_is_omap44xx())
omap2_mcspi3_init();
if (cpu_is_omap343x() || cpu_is_omap44xx())
omap2_mcspi4_init();
}
--
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: Samsung SoCs: preparation for single kernel
On Wed, Jun 23, 2010 at 10:54 AM, Eric Miao eric.y.m...@gmail.com wrote:
On Wed, Jun 23, 2010 at 9:47 AM, Kyungmin Park kmp...@infradead.org wrote:
On Wed, Jun 23, 2010 at 9:50 AM, Eric Miao eric.y.m...@gmail.com wrote:
On Wed, Jun 23, 2010 at 7:27 AM, Kyungmin Park kmp...@infradead.org wrote:
To Ben,
I really need single kernel for s5pc110 (cortex A8) and s5pc210
(cortex A9) at least.
Fortunately arm move to these approaches recently. but current Samsung
SoCs not prepare these one.
So I wonder do you have a plan or how to address these issues?
How to assign the address at resources and use it at runtime?
Personally I want to use cpu_is_*. but you reject it to use.
Other way is that we can create the base address variables and assign
it at init time.
Please give your opinions.
Thank you,
Kyungmin Park
e.g., cpu_is_* usage at OMAP tree
static void omap_init_mcspi(void)
{
if (cpu_is_omap44xx())
omap4_mcspi_fixup();
platform_device_register(omap2_mcspi1);
platform_device_register(omap2_mcspi2);
if (cpu_is_omap2430() || cpu_is_omap343x() || cpu_is_omap44xx())
omap2_mcspi3_init();
if (cpu_is_omap343x() || cpu_is_omap44xx())
omap2_mcspi4_init();
}
Just my two cents: cpu_is_*() can be used, but only when absolutely
necessary.
The s3c does a CPU detection at startup, so I guess the usage of cpu_is_*()
can be even reduced.
My concern is that most device resources use the S3C_* or S5P_* prefix
and defined at each arch differently.
E.G., mmc resource drivers use the S3C_PA_HSMMC0. but each mach has
different base address.
then how to handle this or make it possible?
Now you have
s5pv210_device_hsmmc0
s5pc100_device_hsmmc0
s3c64xx_device_hsmmc0
each with a different base.
Good, then wait Ben's opinions.
#define S5PV210_PA_HSMMC(x) (0xEB00 + ((x) * 0x10))
#define S3C_PA_HSMMC0 S5PV210_PA_HSMMC(0)
#define S3C_PA_HSMMC1 S5PV210_PA_HSMMC(1)
#define S3C_PA_HSMMC2 S5PV210_PA_HSMMC(2)
#define S5PC100_PA_HSMMC(x) (0xED80 + ((x) * 0x10))
#define S3C_PA_HSMMC0 S5PC100_PA_HSMMC(0)
#define S3C_PA_HSMMC1 S5PC100_PA_HSMMC(1)
#define S3C_PA_HSMMC2 S5PC100_PA_HSMMC(2)
#define S3C64XX_PA_HSMMC(x) (0x7C20 + ((x) * 0x10))
#define S3C64XX_PA_HSMMC0 S3C64XX_PA_HSMMC(0)
#define S3C64XX_PA_HSMMC1 S3C64XX_PA_HSMMC(1)
#define S3C64XX_PA_HSMMC2 S3C64XX_PA_HSMMC(2)
#define S3C_PA_HSMMC0 S3C64XX_PA_HSMMC0
#define S3C_PA_HSMMC1 S3C64XX_PA_HSMMC1
#define S3C_PA_HSMMC2 S3C64XX_PA_HSMMC2
I'm not sure if the above case is a good reference or not. The
omap_init_mcspi
is called from omap2_init_devices(), while the registration can actually be
made into the board init code when that device is used (some of the McSPIs
are
not used, and it's not necessary to register them), and the differences be
handled in the driver.
that's just example how to use cpu_is_* in others. the current schme
in samsung SoCs. we passed the different platform name for each arch.
e.g., s3c2410_i2c or s3c2440_i2c then i2c driver detect it and handle
properly. of course it assume base address is set correctly as above.
For the device driver, when you register two different i2c devices:
struct platform_device s3c2410_device_i2c {
.name = s3c2410-i2c,
...
};
struct platform_device s3c2440_device_i2c {
.name = s3c2440-i2c,
...
};
And register the corresponding one in your board code (your board code
knows exactly which one to register, no? )
And then in your i2c driver, you declare:
const static struct platform_device_id s3c_i2c_ids[] = {
{ s3c2410-i2c, S3C2410_SPECIFIC_FLAGS },
{ s3c2440-i2c, S3C2440_SPECIFIC_FLAGS },
.
};
Now you have S3C2410_SPECIFIC_FLAGS and S3C2440_SPECIFIC_FLAGS for your
device driver to distinguish between the differences. Normally, the
differences won't be much, and make sure you have good abstraction of
those _SPECIFIC_FLAGS.
It's already done.
Thank you,
Kyungmin Park
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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 v2 0/4] ARM: S5P: Support gpio interrupts
On Wed, Jun 23, 2010 at 4:50 PM, Kukjin Kim kgene@samsung.com wrote: Joonyoung Shim wrote: This patch v2 set is to support gpio interrupts of samsung s5p cpus, and the GPIOlib gpio_to_irq goes to plat-samsung gpiolib, so patch v2 set has four commit smaller than v1. Changes since v1: - Add irq_base to s3c_gpio_chip struct - GPIOlib gpio_to_irq() is implemented to samsung_gpiolib_to_irq() of plat-samsung gpiolib Joonyoung Shim (4): ARM: S5PV210: Add gpio interrupt support ARM: S5PC100: Use S5P gpio interrupts interface ARM: S5PC100: Move external interrupt defines ARM: SAMSUNG: Add GPIOlib gpio_to_irq arch/arm/mach-s5pc100/Makefile | 2 +- arch/arm/mach-s5pc100/gpiolib.c | 70 ++- arch/arm/mach-s5pc100/include/mach/gpio.h | 7 - arch/arm/mach-s5pc100/include/mach/irqs.h | 18 ++- arch/arm/mach-s5pc100/include/mach/regs-gpio.h | 7 + arch/arm/mach-s5pc100/irq-gpio.c | 266 arch/arm/mach-s5pv210/gpiolib.c | 18 ++- arch/arm/mach-s5pv210/include/mach/irqs.h | 16 ++- arch/arm/plat-s5p/Makefile | 2 +- arch/arm/plat-s5p/irq-gpioint.c | 208 ++ arch/arm/plat-samsung/gpiolib.c | 9 + arch/arm/plat-samsung/include/plat/gpio-core.h | 6 + 12 files changed, 295 insertions(+), 334 deletions(-) delete mode 100644 arch/arm/mach-s5pc100/irq-gpio.c create mode 100644 arch/arm/plat-s5p/irq-gpioint.c I am sure this patchset is working code, but Ben had made suggestion about 'sparse irq'... It is because there are too many gpio interrupts and having support of all of them is unnecessary as realistically only few of them maybe used. In fact in SMDK board there is no use of gpio in interrupt mode. Ben, I remember your suggestion for using 'sparse irq' for handling gpio interrupts. And in fact, sparse irq implementation can be beneficial to many other boards... Could you please explain about that? Interesting. you can find it by [ARM] Preliminary support for dynamic IRQ written by Eric. Instead define the 'NR_IRQS' of chip, board can define each 'nr_irqs' at init time. Maybe smdk don't use the GPIOs. but mobile phones at samsung use the until MP0x. Sometime H/W team connect it at MP04 or MP05 which doesn't support GPIO interrupt. Thank you, Kyungmin 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
Re: [PATCH 2/3] ARM: S5P: Add System define for arch_reset()
On Thu, Jun 24, 2010 at 7:31 AM, Kukjin Kim kgene@samsung.com wrote:
From: Jongpill Lee boyko@samsung.com
This patch adds system define for arch_reset() using Watchdog reset.
And adds IO mapping for using WDT.
Are there any reason to use the WDT to system reset?
As original purpose of WDT. doesn't it better to use system reset?
Since we use the WDT reset at other purpose. but if you add the WDT
reset to system reset.
then we can't control it. bootloader check the reset reason then
report something wrong at previous operation.
So I want to use system reset as original purpose.
Thank you,
Kyungmin Park
Signed-off-by: Jongpill Lee boyko@samsung.com
Signed-off-by: Kukjin Kim kgene@samsung.com
---
arch/arm/plat-s5p/cpu.c | 5 +
arch/arm/plat-s5p/include/plat/system-reset.h | 24
2 files changed, 29 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-s5p/include/plat/system-reset.h
diff --git a/arch/arm/plat-s5p/cpu.c b/arch/arm/plat-s5p/cpu.c
index 75cb8c3..1ab55e8 100644
--- a/arch/arm/plat-s5p/cpu.c
+++ b/arch/arm/plat-s5p/cpu.c
@@ -103,6 +103,11 @@ static struct map_desc s5p_iodesc[] __initdata = {
.pfn = __phys_to_pfn(S5P_PA_GPIO),
.length = SZ_4K,
.type = MT_DEVICE,
+ }, {
+ .virtual = (unsigned long)S3C_VA_WATCHDOG,
+ .pfn = __phys_to_pfn(S3C_PA_WDT),
+ .length = SZ_4K,
+ .type = MT_DEVICE,
},
};
diff --git a/arch/arm/plat-s5p/include/plat/system-reset.h
b/arch/arm/plat-s5p/include/plat/system-reset.h
new file mode 100644
index 000..7f76a16
--- /dev/null
+++ b/arch/arm/plat-s5p/include/plat/system-reset.h
@@ -0,0 +1,24 @@
+/* linux/arch/arm/plat-s5p/include/plat/system-reset.h
+ *
+ * Copyright (c) 2010 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Based on arch/arm/mach-s3c2410/include/mach/system-reset.h
+ *
+ * S5P - System define for arch_reset()
+ *
+ * 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 plat/watchdog-reset.h
+
+static void arch_reset(char mode, const char *cmd)
+{
+ /* Perform reset using Watchdog reset.
+ * SWRESET support will be added later.
+ */
+
+ arch_wdt_reset();
+}
--
1.6.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
--
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: Samsung SoCs: preparation for single kernel
On Wed, Jun 23, 2010 at 6:20 PM, Marek Szyprowski
m.szyprow...@samsung.com wrote:
Hello,
On Wednesday, June 23, 2010 10:02 AM Eric Miao wrote:
Now you have
s5pv210_device_hsmmc0
s5pc100_device_hsmmc0
s3c64xx_device_hsmmc0
each with a different base.
There is no need for such code duplication.
However, I believe this is the right way to go. A certain level of
duplication is the price to pay for a generic and clean solution.
When a peripheral controller or IP is moved from one SoC to the
next generation, there are several things could have been changed:
1. new base address and IRQ number
2. fixes and enhancements to the original IP
1. will result in a different 'struct resource', and 2. will result in a
different 'struct platform_device' with a different name, so the driver
can match the platform_device_id table as you agreed I'm right on
that recommendation.
They are actually _two_ different devices.
Right, they are separate entities, but would be really good if a similar
git brcode could be merged together.
Ben is working on a solution for
a single kernel which supports multiple SoCs. Some of his work in
progress can
be found here: git://git.fluff.org/bjdooks/linux branch wip-samsung-dev
and
wip-samsung-dev2.
Could you describe it a bit here and bring it on table for discussion?
The idea behind his patches is to provide a table for each SoC with short
description of all available devices and generate platform_device entries
dynamically from that table.
Here is a short code example:
struct s3c_pdev_table s3c6xxx_dev_table[] __initdata = {
{
.type = SAMSUNG_DEVICE_UART,
.name = s3c6400-uart,
.index = 0,
.base = S3C_PA_UART0,
.irq = IRQ_S3CUART_RX0,
.template = template_uart_s3c64xx,
}, {
.type = SAMSUNG_DEVICE_UART,
.name = s3c6400-uart,
.index = 1,
.base = S3C_PA_UART1,
.irq = IRQ_S3CUART_RX1,
.template = template_uart_s3c64xx,
}, {
.type = SAMSUNG_DEVICE_UART,
.name = s3c6400-uart,
.index = 2,
.base = S3C_PA_UART2,
.irq = IRQ_S3CUART_RX2,
.template = template_uart_s3c64xx,
}, {
.type = SAMSUNG_DEVICE_UART,
.name = s3c6400-uart,
.index = 3,
.base = S3C_PA_UART3,
.irq = IRQ_S3CUART_RX3,
.template = template_uart_s3c64xx,
}, {
.type = SAMSUNG_DEVICE_WATCHDOG,
.name = s3c2410-wdt,
.index = -1,
.base = S3C64XX_PA_WATCHDOG,
.irq = IRQ_WDT,
}, {
.type = SAMSUNG_DEVICE_SDHCI,
.name = s3c-sdhci,
.index = 0,
.base = S3C64XX_PA_HSMMC0 ,
.irq = IRQ_HSMMC0,
.dma = samsung_std_dma_mask,
}, {
.type = SAMSUNG_DEVICE_SDHCI,
.name = s3c-sdhci,
.index = 1,
.base = S3C64XX_PA_HSMMC1,
.irq = IRQ_HSMMC1,
.dma = samsung_std_dma_mask,
}, {
.type = SAMSUNG_DEVICE_SDHCI,
.name = s3c-sdhci,
.index = 2,
.base = S3C64XX_PA_HSMMC2,
.irq = IRQ_HSMMC1,
.dma = samsung_std_dma_mask,
}, {
.type = SAMSUNG_DEVICE_OHCI,
.name = s3c2410-ohci,
.index = -1,
.base = S3C64XX_PA_USBHOST,
.irq = IRQ_USBH,
.dma = samsung_std_dma_mask,
}, {
.type = SAMSUNG_DEVICE_NAND,
.name = s3c6400-nand,
.index = -1,
.base = 0x4E00,
.irq = IRQ_NFC,
}, {
.type = SAMSUNG_DEVICE_I2C,
.name = s3c2440-i2c,
.index = 0,
.base = S3C64XX_PA_IIC0,
.irq = IRQ_IIC,
}, {
...
This solution is imho really clean an easy to understand. It is also
easy to check which SoC has which peripherals defined and how.
Question. recently it's changed to use MMC0, MMC2, MMC3, then how to define it?
More basically, where these info are defined for chip or board?
If chip, the how to handle several variants?
Thank you,
Kyungmin Park
I hope Ben will be able to finish it soon and all Samsung platforms can
be converted for it. Then creating a single kernel for more than one SoC
should be possible with only a few additional changes.
PS: My feeling of commenting several of the samsung patches so far turns
out
Re: [PATCH 0/8] ARM: S5PV310: Add support for Samsung S5PV310 SoC
Hi, How about to start the single kernel preparation from this patch? Instead of create the new machine directory, we just put the mach-s5pv210 or create the new one. and don't you think it's confusing of names. s5pc110 (same as s5pv210), vs. s5pc210 (same as s5pv310). maybe someone don't read the chip carefully. it's misleading the chips. Thank you, Kyungmin Park On Fri, Jun 25, 2010 at 11:27 PM, Kukjin Kim kgene@samsung.com wrote: This patch set adds support for Samsung S5PV310/S5PC210. The S5PV310 integrates a ARM Cortex A9 microprocessor with several other peripherals to support features such as multimedia, storage, graphics and gaming. The S5PV310 can be used in products such as Netbooks and Mobile devices. This patch set consists of the following patches. [PATCH 1/8] ARM: S5P: Remove fixed uart offset dependent code [PATCH 2/8] ARM: S5PV310: Add new CPU initialization support [PATCH 3/8] ARM: S5PV310: Add Clock and PLL support [PATCH 4/8] ARM: S5PV310: Add IRQ support [PATCH 5/8] ARM: S5PV310: Add Timer support [PATCH 6/8] ARM: S5PV310: Add new Kconfig and Makefiles [PATCH 7/8] ARM: S5PV310: Add Board support file [PATCH 8/8] ARM: S5PV310: Add serial port support -- 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 8/8] ARM: S5PV310: Add serial port support
Hi,
As previous description. it's also same except the udivslot
calculation and clock selection.
How about to just modify current v210 serial codes by just adding the
V310 or C210 type?
Thank you,
Kyungmin Park
On Fri, Jun 25, 2010 at 11:27 PM, Kukjin Kim kgene@samsung.com wrote:
From: Changhwan Youn chaos.y...@samsung.com
This patch adds UART serial port support for S5PV310 CPU.
Signed-off-by: Changhwan Youn chaos.y...@samsung.com
Signed-off-by: Kukjin Kim kgene@samsung.com
---
drivers/serial/Kconfig | 8 +++
drivers/serial/Makefile | 1 +
drivers/serial/s5pv310.c | 124
++
3 files changed, 133 insertions(+), 0 deletions(-)
create mode 100644 drivers/serial/s5pv310.c
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 8b23165..b5ff41f 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -550,6 +550,14 @@ config SERIAL_S5PV210
help
Serial port support for Samsung's S5P Family of SoC's
+config SERIAL_S5PV310
+ tristate Samsung S5PV310 Serial port support
+ depends on SERIAL_SAMSUNG CPU_S5PV310
+ select SERIAL_SAMSUNG_UARTS_4
+ default y
+ help
+ Serial port support for Samsung's S5P Family of SoC's
+
config SERIAL_MAX3100
tristate MAX3100 support
depends on SPI
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index 208a855..bd32d3f 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_SERIAL_S3C2440) += s3c2440.o
obj-$(CONFIG_SERIAL_S3C24A0) += s3c24a0.o
obj-$(CONFIG_SERIAL_S3C6400) += s3c6400.o
obj-$(CONFIG_SERIAL_S5PV210) += s5pv210.o
+obj-$(CONFIG_SERIAL_S5PV310) += s5pv310.o
obj-$(CONFIG_SERIAL_MAX3100) += max3100.o
obj-$(CONFIG_SERIAL_IP22_ZILOG) += ip22zilog.o
obj-$(CONFIG_SERIAL_MUX) += mux.o
diff --git a/drivers/serial/s5pv310.c b/drivers/serial/s5pv310.c
new file mode 100644
index 000..1d466cf
--- /dev/null
+++ b/drivers/serial/s5pv310.c
@@ -0,0 +1,124 @@
+/* linux/drivers/serial/s5pv310.c
+ *
+ * Copyright (c) 2010 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * Based on drivers/serial/s5pv210.c
+ *
+ * Driver for Samsung S5PV310 SoC UARTs.
+ *
+ * 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/module.h
+#include linux/io.h
+#include linux/platform_device.h
+#include linux/serial_core.h
+
+#include plat/regs-serial.h
+#include samsung.h
+
+static int s5pv310_serial_setsource(struct uart_port *port,
+ struct s3c24xx_uart_clksrc *clk)
+{
+ /* for s5pv310, serial clock source is only uclk1 */
+ return 0;
+};
+
+static int s5pv310_serial_getsource(struct uart_port *port,
+ struct s3c24xx_uart_clksrc *clk)
+{
+ /* for s5pv310, serial clock source is only uclk1 */
+ clk-divisor = 1;
+ clk-name = uclk1;
+ return 0;
+};
+
+static int s5pv310_serial_resetport(struct uart_port *port,
+ struct s3c2410_uartcfg *cfg)
+{
+ wr_regl(port, S3C2410_UCON, cfg-ucon);
+ wr_regl(port, S3C2410_ULCON, cfg-ulcon);
+
+ /* reset both fifos */
+ wr_regl(port, S3C2410_UFCON, cfg-ufcon | S3C2410_UFCON_RESETBOTH);
+ wr_regl(port, S3C2410_UFCON, cfg-ufcon);
+
+ return 0;
+}
+
+#define S5PV310_UART_DEFAULT_INFO(fifo_size) \
+ .name = Samsung S5PV310 UART, \
+ .type = PORT_S3C6400, \
+ .fifosize = fifo_size, \
+ .has_fracval = 1, \
+ .rx_fifomask = S5PV210_UFSTAT_RXMASK, \
+ .rx_fifoshift = S5PV210_UFSTAT_RXSHIFT, \
+ .rx_fifofull = S5PV210_UFSTAT_RXFULL, \
+ .tx_fifofull = S5PV210_UFSTAT_TXFULL, \
+ .tx_fifomask = S5PV210_UFSTAT_TXMASK, \
+ .tx_fifoshift = S5PV210_UFSTAT_TXSHIFT, \
+ .get_clksrc = s5pv310_serial_getsource, \
+ .set_clksrc = s5pv310_serial_setsource, \
+ .reset_port = s5pv310_serial_resetport
+
+static struct s3c24xx_uart_info s5p_port_fifo256 = {
+ S5PV310_UART_DEFAULT_INFO(256),
+};
+
+static struct s3c24xx_uart_info s5p_port_fifo64 = {
+ S5PV310_UART_DEFAULT_INFO(64),
+};
+
+static struct s3c24xx_uart_info s5p_port_fifo16 = {
+ S5PV310_UART_DEFAULT_INFO(16),
+};
+
+struct s3c24xx_uart_info *s5p_uart_inf[] = {
+ [0] = s5p_port_fifo256,
+ [1] = s5p_port_fifo64,
+ [2] = s5p_port_fifo16
Re: [PATCH] ARM: SAMSUNG: updates sdhci.h for Samsung SoCs
Hi,
Instead of refactoring, how about to delete it and move to dev-hsmmc file.
We don't need to call each sdhci_setup at each cpu files. just set
platform data and register platform data.
Just focus the each dev-hsmmc file and no need to change header file anymore.
How do you think?
Thank you,
Kyungmin Park
On Mon, Jul 5, 2010 at 9:18 PM, Kukjin Kim kgene@samsung.com wrote:
This patch updates sdhci.h as Maurus suggestion like following:
From:
#ifdef ...
function()
{
blahblah;
}
#else
function() { }
#endif
To:
function()
{
#ifdef ...
blahblah;
#endif
}
And fixes a couple of typos.
Signed-off-by: Kukjin Kim kgene@samsung.com
---
Note: depends on previous v3 patch set, Add support HSMMC on Samsung SMDKV210
arch/arm/plat-samsung/include/plat/sdhci.h | 91
+---
1 files changed, 30 insertions(+), 61 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/sdhci.h
b/arch/arm/plat-samsung/include/plat/sdhci.h
index 1314ffa..5ad1e94 100644
--- a/arch/arm/plat-samsung/include/plat/sdhci.h
+++ b/arch/arm/plat-samsung/include/plat/sdhci.h
@@ -82,12 +82,11 @@ extern void s5pv210_setup_sdhci1_cfg_gpio(struct
platform_device *, int w);
extern void s5pv210_setup_sdhci2_cfg_gpio(struct platform_device *, int w);
extern void s5pv210_setup_sdhci3_cfg_gpio(struct platform_device *, int w);
-/* S3C6400 SDHCI setup */
+/* S3C64XX SDHCI setup */
#ifdef CONFIG_S3C64XX_SETUP_SDHCI
extern char *s3c64xx_hsmmc_clksrcs[4];
-#ifdef CONFIG_S3C_DEV_HSMMC
extern void s3c6400_setup_sdhci_cfg_card(struct platform_device *dev,
void __iomem *r,
struct mmc_ios *ios,
@@ -95,76 +94,62 @@ extern void s3c6400_setup_sdhci_cfg_card(struct
platform_device *dev,
static inline void s3c6400_default_sdhci0(void)
{
+#ifdef CONFIG_S3C_DEV_HSMMC
s3c_hsmmc0_def_platdata.clocks = s3c64xx_hsmmc_clksrcs;
s3c_hsmmc0_def_platdata.cfg_gpio = s3c64xx_setup_sdhci0_cfg_gpio;
s3c_hsmmc0_def_platdata.cfg_card = s3c6400_setup_sdhci_cfg_card;
+#endif
}
-#else
-static inline void s3c6400_default_sdhci0(void) { }
-#endif /* CONFIG_S3C_DEV_HSMMC */
-
-#ifdef CONFIG_S3C_DEV_HSMMC1
static inline void s3c6400_default_sdhci1(void)
{
+#ifdef CONFIG_S3C_DEV_HSMMC1
s3c_hsmmc1_def_platdata.clocks = s3c64xx_hsmmc_clksrcs;
s3c_hsmmc1_def_platdata.cfg_gpio = s3c64xx_setup_sdhci1_cfg_gpio;
s3c_hsmmc1_def_platdata.cfg_card = s3c6400_setup_sdhci_cfg_card;
+#endif
}
-#else
-static inline void s3c6400_default_sdhci1(void) { }
-#endif /* CONFIG_S3C_DEV_HSMMC1 */
-#ifdef CONFIG_S3C_DEV_HSMMC2
static inline void s3c6400_default_sdhci2(void)
{
+#ifdef CONFIG_S3C_DEV_HSMMC2
s3c_hsmmc2_def_platdata.clocks = s3c64xx_hsmmc_clksrcs;
s3c_hsmmc2_def_platdata.cfg_gpio = s3c64xx_setup_sdhci2_cfg_gpio;
s3c_hsmmc2_def_platdata.cfg_card = s3c6400_setup_sdhci_cfg_card;
+#endif
}
-#else
-static inline void s3c6400_default_sdhci2(void) { }
-#endif /* CONFIG_S3C_DEV_HSMMC2 */
-
-/* S3C6410 SDHCI setup */
extern void s3c6410_setup_sdhci_cfg_card(struct platform_device *dev,
void __iomem *r,
struct mmc_ios *ios,
struct mmc_card *card);
-#ifdef CONFIG_S3C_DEV_HSMMC
static inline void s3c6410_default_sdhci0(void)
{
+#ifdef CONFIG_S3C_DEV_HSMMC
s3c_hsmmc0_def_platdata.clocks = s3c64xx_hsmmc_clksrcs;
s3c_hsmmc0_def_platdata.cfg_gpio = s3c64xx_setup_sdhci0_cfg_gpio;
s3c_hsmmc0_def_platdata.cfg_card = s3c6410_setup_sdhci_cfg_card;
+#endif
}
-#else
-static inline void s3c6410_default_sdhci0(void) { }
-#endif /* CONFIG_S3C_DEV_HSMMC */
-#ifdef CONFIG_S3C_DEV_HSMMC1
static inline void s3c6410_default_sdhci1(void)
{
+#ifdef CONFIG_S3C_DEV_HSMMC1
s3c_hsmmc1_def_platdata.clocks = s3c64xx_hsmmc_clksrcs;
s3c_hsmmc1_def_platdata.cfg_gpio = s3c64xx_setup_sdhci1_cfg_gpio;
s3c_hsmmc1_def_platdata.cfg_card = s3c6410_setup_sdhci_cfg_card;
+#endif
}
-#else
-static inline void s3c6410_default_sdhci1(void) { }
-#endif /* CONFIG_S3C_DEV_HSMMC1 */
-#ifdef CONFIG_S3C_DEV_HSMMC2
static inline void s3c6410_default_sdhci2(void)
{
+#ifdef CONFIG_S3C_DEV_HSMMC2
s3c_hsmmc2_def_platdata.clocks = s3c64xx_hsmmc_clksrcs;
s3c_hsmmc2_def_platdata.cfg_gpio = s3c64xx_setup_sdhci2_cfg_gpio;
s3c_hsmmc2_def_platdata.cfg_card = s3c6410_setup_sdhci_cfg_card;
+#endif
}
-#else
-static inline void s3c6410_default_sdhci2(void) { }
-#endif /* CONFIG_S3C_DEV_HSMMC2 */
#else
static inline void s3c6410_default_sdhci0(void) { }
@@ -184,48 +169,42 @@ extern void s5pc100_setup_sdhci0_cfg_card(struct
platform_device *dev
Re: [PATCH] ARM: S5P: Add PMU device
On Mon, Jul 5, 2010 at 9:57 PM, Kukjin Kim kgene@samsung.com wrote: Maurus Cuelenaere wrote: Op 05-07-10 03:46, Joonyoung Shim schreef: This patch adds an initcall for the s5p platforms so that they register their PMU IRQs with the PMU framework in the Kernel. Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com --- arch/arm/mach-s5p6442/include/mach/irqs.h | 2 +- arch/arm/mach-s5pc100/include/mach/irqs.h | 1 + arch/arm/mach-s5pv210/include/mach/irqs.h | 1 + arch/arm/plat-s5p/Makefile | 1 + arch/arm/plat-s5p/dev-pmu.c | 37 + 5 files changed, 41 insertions(+), 1 deletions(-) create mode 100644 arch/arm/plat-s5p/dev-pmu.c Wouldn't it be better if this was in plat-samsung? I can see that the S3C6410 datasheet mentions a PMU_IRQ_ENABLE bit in SYS_OTHERS so I suspect that it has the same functionality (even though there's no mention of which interrupt this is). Yes, I also found PMU_IRQ_ENABLE bit in System Others register of S3C6410 datasheet. But as your comments, could not found the interrupt number and any description...Actually, need to check whether it's available or not. And S5P6440 has it. So Joonyoung, it would be helpful if you could add 6440 PMUIRQ (VIC1[23]) in this patch. It's another story. Can you explain the difference between 6440 and 6442? As I heard it's same chip and type is difference. If true, how about to delete the 6442 directory? It makes a single kernel simple. Thank you, Kyungmin Park Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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: S5P: Add PMU device
On Tue, Jul 6, 2010 at 12:12 PM, Kukjin Kim kgene@samsung.com wrote: Kyungmin Park wrote: On Mon, Jul 5, 2010 at 9:57 PM, Kukjin Kim kgene@samsung.com wrote: Maurus Cuelenaere wrote: Op 05-07-10 03:46, Joonyoung Shim schreef: This patch adds an initcall for the s5p platforms so that they register their PMU IRQs with the PMU framework in the Kernel. Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com --- arch/arm/mach-s5p6442/include/mach/irqs.h | 2 +- arch/arm/mach-s5pc100/include/mach/irqs.h | 1 + arch/arm/mach-s5pv210/include/mach/irqs.h | 1 + arch/arm/plat-s5p/Makefile | 1 + arch/arm/plat-s5p/dev-pmu.c | 37 + 5 files changed, 41 insertions(+), 1 deletions(-) create mode 100644 arch/arm/plat-s5p/dev-pmu.c Wouldn't it be better if this was in plat-samsung? I can see that the S3C6410 datasheet mentions a PMU_IRQ_ENABLE bit in SYS_OTHERS so I suspect that it has the same functionality (even though there's no mention of which interrupt this is). Yes, I also found PMU_IRQ_ENABLE bit in System Others register of S3C6410 datasheet. But as your comments, could not found the interrupt number and any description...Actually, need to check whether it's available or not. And S5P6440 has it. So Joonyoung, it would be helpful if you could add 6440 PMUIRQ (VIC1[23]) in this patch. It's another story. Can you explain the difference between 6440 and 6442? As I heard it's same chip and type is difference. If true, how about to delete the 6442 directory? It makes a single kernel simple. I remember, already explained about that. Hmm..Where did you hear wrong information that they are same? :-( Absolutely, they are different !! not same chip. ... But actually, I'm working on merge some S5P SoCs... Can you tell me in details? Now we start the merge the s5p6442 and s5pc110. And how about to merge the s5pc100 with s3c6410? it's not good decision to place the c100 at s5p with name prefix. I think it's better to place the similar core at same directory instead of name. Thank you, Kyungmin Park Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, 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 -- 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] SDHCI-S3C fixes and enhancements (driver specific code)
Hi Andrew, I hope to merge it at next merge windows. Others any comments? Thank you, Kyungmin Park On Wed, Jun 16, 2010 at 3:49 PM, Marek Szyprowski m.szyprow...@samsung.com wrote: Hello, This series includes various fixes to sdhci-s3c driver as well as a major feature enhancement. This patch series is prepared to get complete sdhci support on Samsung Aquila board. A quick overview on the patches: #1 - add missing sdhci_s3c_driver_remove() function #2 - introduce new sdhci quirk to get rid of anoying runtime warning and possible problems with slow mmc/sd cards #3 - add support for various methods of notifying the host driver about the card insertion/removal (should be compatible with existing code) Last patch requires changes to the Samsung platform setup code, which has been posted in a separate patch series for easier merging, please refer to the [PATCH v2] SDHCI-S3C fixes and enhancements (platform specific code) thread. Changes since V1: - added support for gpio external interrupt card based detect method directly to sdhci-s3c driver - removed duplicate Kconfig patch - removed timeout patch (not really needed) A complete list of patches: [PATCH 1/3] sdhci-s3c: add missing remove function [PATCH 2/3] sdhci-s3c: add support for the non standard minimal clock value [PATCH 3/3] sdhci-s3c: add support for new card detection methods Best regards -- Marek Szyprowski Samsung Poland RD Center -- 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] ARM: S5PV210: Fix on SECTION_SIZE_BITS on S5PV210/S5PC110.
On Tue, Jul 6, 2010 at 1:36 PM, Kukjin Kim kgene@samsung.com wrote: This patch fixes on SECTION_SIZE_BITS for Sparsemem on S5PV210/S5PC110. Because smallest size of a bank on S5PV210/S5PC110 is aligned by 16MB. So each section's maximum size should be 16MB. Could you explain what's the problem? Even though 80MiB is used at logical size. it used the physical 128MiB so. it's reasonable to use 128MiB align instead of 16MiB. Are there boards use 64MiB or less? I think if decrease the SECTIONS_SIZE_BITS, it wastes the memory. Thank you, Kyungmin Park Reported-by: Kyongho Cho pullip@samsung.com Signed-off-by: Kukjin Kim kgene@samsung.com --- arch/arm/mach-s5pv210/include/mach/memory.h | 8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-s5pv210/include/mach/memory.h b/arch/arm/mach-s5pv210/include/mach/memory.h index 379117e..4a372d8 100644 --- a/arch/arm/mach-s5pv210/include/mach/memory.h +++ b/arch/arm/mach-s5pv210/include/mach/memory.h @@ -16,8 +16,12 @@ #define PHYS_OFFSET UL(0x2000) #define CONSISTENT_DMA_SIZE (SZ_8M + SZ_4M + SZ_2M) -/* Maximum of 256MiB in one bank */ +/* Sparsemem support. Each section is a maximum of 16MB. + * Because there are many different memory type on S5PC110(MCP), + * and there is a case that having 80MB, 128MB or 256MB in one + * bank. +*/ #define MAX_PHYSMEM_BITS 32 -#define SECTION_SIZE_BITS 28 +#define SECTION_SIZE_BITS 24 #endif /* __ASM_ARCH_MEMORY_H */ -- 1.6.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 -- 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 on SECTION_SIZE_BITS on S5PV210/S5PC110.
On Wed, Jul 7, 2010 at 8:27 AM, Kukjin Kim kgene@samsung.com wrote: Russell King wrote: Hi Russell :-) On Tue, Jul 06, 2010 at 01:36:47PM +0900, Kukjin Kim wrote: This patch fixes on SECTION_SIZE_BITS for Sparsemem on S5PV210/S5PC110. Because smallest size of a bank on S5PV210/S5PC110 is aligned by 16MB. So each section's maximum size should be 16MB. What is the spacing of chunks of memory, and minimum alignment of those chunks in physical address space? Some S5PC110(MCP D-type) has only available 80MiB in a bank. So the space accounts for 432MiB in a DMC0, but larger memory(256MiB + 128MiB) exists in a DMC1. It's OneDRAM consists of 80MiB for AP, 16MiB for shared between AP and CP, and last 32MiB for CP. Even though we use the dedicated 80MiB for AP. we also use the shared 16MiB at AP side. Then can we access the last 32MiB? the answer is no. But it's connected physically. so we can't use the last 32MiB area for other case. Additionally it's almost difficult to 16MiB align by Spec. Memory Chip0 Configuration Register (MemConfig0, R/W, Address=0xF000_0008, 0xF140_0008) chip_mask [23:16] AXI Base Address Mask Upper address bit mask to determine AXI offset address of memory chip0. 0 = Corresponding address bit is not to be used for comparison 1 = Corresponding address bit is to be used for comparison For example, if chip_mask = 0xF8, then AXI offset address becomes 0x_ ~ 0x07FF_. If AXI base address of memory chip0 is 0x2000_, then memory chip0 has an address range of 0x2000_ ~ 0x27FF_. Thank you, Kyungmin Park As you know, the size of a section should be a power of 2 and a physical address space of a section should be contiguous. If a section size is greater than 16MiB, a section have a hole. So the SECTION_SIZE_BITS should be 16MiB. Also, what is the maximum physical address which memory can be located? Following is memory map of S5PV210/S5PC110. 0x8000 --- | | 0x7000 | | | | 0x6000 | DMC 1 | up to 1GiB | | 0x5000 | | | | 0x4000 - | | 0x3000 | DMC 0 | up to 512MiB | | 0x2000 --- Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, 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 -- 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
Requested features for next merge on s5pc110
Hi Kukjin, Before next merge window, I hope these features will be included. If your team is done already, please reply it. If not, our team will do it. 1. High-resolution timer using timer 4 and systimer. other timer 1, 2, 3, is used 2. Basic suspend resume feature. No clock gating, and cpufreq. Of course I hope it's included. 3. Aquila goni board support. If possible all feature are included at current maineline kernel implemented. If I'm missing one features, please let me know, Give your opinions. Thank you, Kyungmin 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
Re: Requested features for next merge on s5pc110
On Thu, Jul 8, 2010 at 12:39 PM, Jassi Brar jassisinghb...@gmail.com wrote: On Thu, Jul 8, 2010 at 12:05 PM, Kyungmin Park kmp...@infradead.org wrote: 3. Aquila goni board support. If possible all feature are included at current maineline kernel implemented. Without doubt it's pleasing to see so many people involved pushing support for Samsung's SoCs and machines based upon them. But it might be worthwhile to rethink if support for such 'not-so-popular' machines and 'transient' socs is necessary or even useful ? It depends on the point of view. Even though it's not sold from marker, others will be used. e.g., Limo. We are planing to distribute mobile reference board to developer and community that's reason to enable it at mainline. Of course the best is sell the reference board from LSI like beagle board from TI or other company. you can enable these at smdk board. I also want to know that which name of either s5pv210 or s5pc110 is popular at outside? I think latter is well known since galaxy S and wave phone uses it. Anyway I hope to use mainline kernel as base kernel at our board. To Jassi, Can you post the sound related patches such as I2S? Thank you, Kyungmin 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
Re: About SECTION_SIZE_BITS for Sparsemem
Interesting. I got tested with #define MAX_PHYSMEM_BITS31 #define SECTION_SIZE_BITS 27 # cat /proc/sys/vm/min_free_kbytes 1832 # echo 1828 /proc/sys/vm/min_free_kbytes # cat /proc/sys/vm/min_free_kbytes 1828 # echo 1820 /proc/sys/vm/min_free_kbytes # cat /proc/sys/vm/min_free_kbytes 1820 # echo 1700 /proc/sys/vm/min_free_kbytes # cat /proc/sys/vm/min_free_kbytes 1700 No kernel panic. Thank you, Kyungmin Park On Mon, Jul 12, 2010 at 5:32 PM, Kukjin Kim kgene@samsung.com wrote: Russell, Hi, Kukjin Kim wrote: Russell wrote: So, memory starts at 0x2000 and finishes at 0x2500. That's fine. That doesn't mean the section size is 16MB. As I've already said, the section size has _nothing_ what so ever to do with the size of memory, or the granularity of the size of memory. By way of illustration, it is perfectly legal to have a section size of 256MB but only have 1MB in a section and this is perfectly legal. So sections do not have to be completely filled. Actually, as you know, the hole's area of mem_map is freed from bootmem if a section has a hole when initializing sparse memory. I identified that a section doesn't need to be a contiguous area of physical memory when reading your comment with the fact that the mem_map of a section can be smaller than the size of a section. I found, however, the kernel panics when modifying min_free_kbytes file in the proc filesystem if a section has a hole. While processing the change of min_free_kbytes in the kernel, page descriptors in a hole of an online section is accessed. As I said, following error happens. It would be helpful to me if any opinions or comments. --- When SECTION_SIZE_BITS is 24 (16MiB), [r...@samsung ~]# cat /proc/sys/vm/min_free_kbytes 2736 [r...@samsung ~]# echo 2730 /proc/sys/vm/min_free_kbytes [r...@samsung ~]# cat /proc/sys/vm/min_free_kbytes 2730 [r...@samsung ~]# When SECTION_SIZE_BITS is 28 (256MiB), [r...@samsung ~]# cat /proc/sys/vm/min_free_kbytes 2736 [r...@samsung ~]# echo 2730 /proc/sys/vm/min_free_kbytes Unable to handle kernel NULL pointer dereference at virtual address 0004 pgd = 80a14000 [0004] *pgd=20a0b031, *pte=, *ppte= Internal error: Oops: 17 [#1] PREEMPT last sysfs file: Modules linked in: CPU: 0 Not tainted (2.6.35-rc4-7-g9a59bf7-dirty #3) PC is at get_pageblock_flags_group+0x54/0xa8 LR is at setup_per_zone_wmarks+0xfc/0x1d4 pc : [800686cc] lr : [800691a0] psr: 6093 sp : 80a03ed0 ip : 0001 fp : 00058000 r10: 004a r9 : 801e5fbc r8 : 802c r7 : 0001c900 r6 : 00025000 r5 : 801e5fa4 r4 : 007e r3 : 0018 r2 : 0002 r1 : r0 : Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 20a14019 DAC: 0015 Process bash (pid: 888, stack limit = 0x80a022e8) Stack: (0x80a03ed0 to 0x80a04000) 3ec0: 801e5fa4 00025000 800691a0 3ee0: a013 02aa 0005 0001 801d8254 2aacb000 0005 0001 3f00: 80a02000 80a03f80 0001 80069354 80a03f80 0001 801d7900 800d2734 3f20: 80a03f80 0005 80a0903c 0005 b7c81c00 2aacb000 3f40: 80a03f80 0005 800d2760 0001 2aacb000 0005 8008ff74 3f60: b7c81c00 2aacb000 b7c81c00 2aacb000 0005 800900c8 3f80: 0005 0005 0005 2aacb000 2ac525f8 0004 3fa0: 8001f0e8 8001ef40 0005 2aacb000 0001 2aacb000 0005 3fc0: 0005 2aacb000 2ac525f8 0004 0005 000babe0 0001 3fe0: 2aacb000 7e88ca58 2ab99124 2abe643c 6010 0001 [800686cc] (get_pageblock_flags_group+0x54/0xa8) from [800691a0] (setup_per_zone_wmarks+0xfc/0x1d4) [800691a0] (setup_per_zone_wmarks+0xfc/0x1d4) from [80069354] (min_free_kbytes_sysctl_handler+0x20/0x28) [80069354] (min_free_kbytes_sysctl_handler+0x20/0x28) from [800d2734] (proc_sys_call_handler+0x90/0xac) [800d2734] (proc_sys_call_handler+0x90/0xac) from [800d2760] (proc_sys_write+0x10/0x14) [800d2760] (proc_sys_write+0x10/0x14) from [8008ff74] (vfs_write+0xac/0x154) [8008ff74] (vfs_write+0xac/0x154) from [800900c8] (sys_write+0x3c/0x68) [800900c8] (sys_write+0x3c/0x68) from [8001ef40] (ret_fast_syscall+0x0/0x30) Code: 11a0cb8c 11a0cbac 1080018c e3a0c001 (e5904004) ---[ end trace 8b96cc6afed783d1 ]--- note: bash[888] exited with preempt_count 1 BUG: scheduling while atomic: bash/888/0x4002 Modules linked in: [80024558] (unwind_backtrace+0x0/0xec) from [8014f110] (schedule+0x6c/0x2e4) [8014f110] (schedule+0x6c/0x2e4) from [80035f74] (__cond_resched+0x24/0x34) [80035f74] (__cond_resched+0x24/0x34) from [8014f484] (_cond_resched+0x30/0x40) [8014f484] (_cond_resched+0x30/0x40) from [8007ac1c] (unmap_vmas+0x550/0x604) [8007ac1c] (unmap_vmas+0x550/0x604) from [8007d6b8] (exit_mmap+0xb0/0x1d8
Re: About SECTION_SIZE_BITS for Sparsemem
On Mon, Jul 12, 2010 at 6:58 PM, Kukjin Kim kgene@samsung.com wrote: Kyungmin Park wrote: Interesting. I got tested with #define MAX_PHYSMEM_BITS 31 #define SECTION_SIZE_BITS 27 # cat /proc/sys/vm/min_free_kbytes 1832 # echo 1828 /proc/sys/vm/min_free_kbytes # cat /proc/sys/vm/min_free_kbytes 1828 # echo 1820 /proc/sys/vm/min_free_kbytes # cat /proc/sys/vm/min_free_kbytes 1820 # echo 1700 /proc/sys/vm/min_free_kbytes # cat /proc/sys/vm/min_free_kbytes 1700 No kernel panic. Thanks for your test on the board. But I need your environment for comparing. Please let me know. Following is my board environment. From boot-loader(u-boot). SMDKC110 # bdinfo arch_number = 0x0891 env_t = 0x boot_params = 0x2100 DRAM bank = 0x - start = 0x2000 - size = 0x0500 DRAM bank = 0x0001 - start = 0x4000 - size = 0x1000 DRAM bank = 0x0002 - start = 0x5000 - size = 0x0800 From kernel boot message. SMDKC110 # bootm c0008000 Boot with zImage Starting kernel ... Uncompressing Linux... done, booting the kernel. Linux version 2.6.35-rc4-8-g98c749c (kg...@starstone) (gcc version 4.4.1 (Sourcery G++ Lite 2009q3-67) ) #1 PREEMPT Mon Jul 12 18:47:04 KST 2010 CPU: ARMv7 Processor [412fc082] revision 2 (ARMv7), cr=10c53c7f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: SMDKC110 ... Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 80MB 256MB 128MB = 464MB total Memory: 459616k/459616k available, 15520k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) DMA : 0xff00 - 0xffe0 ( 14 MB) vmalloc : 0xb880 - 0xe000 ( 632 MB) lowmem : 0x8000 - 0xb800 ( 896 MB) modules : 0x7f00 - 0x8000 ( 16 MB) .init : 0x80008000 - 0x8001e000 ( 88 kB) .text : 0x8001e000 - 0x801be000 (1664 kB) .data : 0x801ce000 - 0x801e6600 ( 98 kB) SLUB: Genslabs=9, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Hierarchical RCU implementation. RCU-based detection of stalled CPUs is disabled. Verbose stalled-CPUs detection is disabled. ... And SECTION_SIZE_BITS is 28, not 27. 27 for our board. 28 for generic. Note that I enabled HIGHMEM and modify the VMALLOC_END to 0xd000' to test HIGHMEM. Universal # bdinfo arch_number = 0x0B2E env_t = 0x boot_params = 0x3100 DRAM bank = 0x - start= 0x3000 - size = 0x0500 DRAM bank = 0x0001 - start= 0x4000 - size = 0x1800 baudrate= 115200 bps Universal # run bootcmd OneNAND read: offset 0xc0, size 0x60 6291456 bytes read: OK ## Booting kernel from Legacy Image at 30007fc0 ... Image Name: Linux-2.6.35-rc4+ Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1548496 Bytes = 1.5 MiB Load Address: 30008000 Entry Point: 30008000 Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. [0.00] Linux version 2.6.35-rc4+ (kmp...@july) (gcc version 4.4.1 (GCC)0 [0.00] CPU: ARMv7 Processor [412fc082] revision 2 (ARMv7), cr=10c53c7f [0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction ce [0.00] Machine: GONI [0.00] Ignoring unrecognised tag 0x54410008 [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] CPU S5PV210/S5PC110 (id 0x43110200) ... [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Memory: 80MB 128MB 128MB 128MB = 464MB total [0.00] Memory: 468224k/468224k available, 6912k reserved, 262144K highmm [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] DMA : 0xff00 - 0xffe0 ( 14 MB) [0.00] vmalloc : 0xd880 - 0xe000 ( 120 MB) [0.00] lowmem : 0xc000 - 0xd800 ( 384 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .init : 0xc0008000 - 0xc001b000 ( 76 kB) [0.00] .text : 0xc001b000 - 0xc0282000 (2460 kB) [0.00] .data : 0xc0298000 - 0xc02b1160 ( 101 kB) [0.00] Hierarchical RCU implementation. [0.00] RCU-based detection of stalled CPUs is disabled. [0.00] Verbose stalled-CPUs detection is disabled. [0.00] NR_IRQS:176 [0.00] VIC @f400
Re: [PATCH v2] ARM: s5pv210_defconfig: Update for removing s5pc110_defconfig
Question? Are there difference between smdkc110 and smdkv210? Thank you, Kyungmin Park On Tue, Jul 13, 2010 at 11:22 AM, Kukjin Kim kgene@samsung.com wrote: Now that S5PC110 machines and S5PV210 machines can be built into one kernel, update mach-s5pv210/Kconfig and s5pv210_defconfig. Tested on SMDKC110(S5PC110) and SMDKV210(S5PV210). Note that GONI machine ID is not included in the kernel. Created and tested against linux-2.6.35-rc5. Signed-off-by: Kukjin Kim kgene@samsung.com --- Changes since v1: - This patch re-based against linux-2.6.35-rc5 which includes 'ARM: reduce defconfigs' from Uwe Kleine-Konig. arch/arm/configs/s5pc110_defconfig | 66 arch/arm/configs/s5pv210_defconfig | 4 ++ arch/arm/mach-s5pv210/Kconfig | 28 +-- 3 files changed, 21 insertions(+), 77 deletions(-) delete mode 100644 arch/arm/configs/s5pc110_defconfig diff --git a/arch/arm/configs/s5pc110_defconfig b/arch/arm/configs/s5pc110_defconfig deleted file mode 100644 index 22c2d14..000 --- a/arch/arm/configs/s5pc110_defconfig +++ /dev/null @@ -1,66 +0,0 @@ -CONFIG_EXPERIMENTAL=y -CONFIG_SYSFS_DEPRECATED_V2=y -CONFIG_BLK_DEV_INITRD=y -CONFIG_KALLSYMS_ALL=y -CONFIG_MODULES=y -CONFIG_MODULE_UNLOAD=y -# CONFIG_BLK_DEV_BSG is not set -CONFIG_ARCH_S5PV210=y -CONFIG_S3C_LOWLEVEL_UART_PORT=1 -CONFIG_MACH_SMDKC110=y -CONFIG_VMSPLIT_2G=y -CONFIG_PREEMPT=y -CONFIG_AEABI=y -CONFIG_CMDLINE=root=/dev/ram0 rw ramdisk=8192 initrd=0x2080,8M console=ttySAC1,115200 init=/linuxrc -CONFIG_VFP=y -CONFIG_NEON=y -CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug -CONFIG_BLK_DEV_LOOP=y -CONFIG_BLK_DEV_RAM=y -CONFIG_BLK_DEV_RAM_SIZE=8192 -# CONFIG_MISC_DEVICES is not set -CONFIG_SCSI=y -CONFIG_BLK_DEV_SD=y -CONFIG_CHR_DEV_SG=y -CONFIG_INPUT_EVDEV=y -# CONFIG_INPUT_KEYBOARD is not set -# CONFIG_INPUT_MOUSE is not set -CONFIG_INPUT_TOUCHSCREEN=y -CONFIG_SERIAL_8250=y -CONFIG_SERIAL_SAMSUNG=y -CONFIG_SERIAL_SAMSUNG_CONSOLE=y -CONFIG_HW_RANDOM=y -# CONFIG_HWMON is not set -# CONFIG_VGA_CONSOLE is not set -# CONFIG_HID_SUPPORT is not set -# CONFIG_USB_SUPPORT is not set -CONFIG_EXT2_FS=y -CONFIG_INOTIFY=y -CONFIG_MSDOS_FS=y -CONFIG_VFAT_FS=y -CONFIG_TMPFS=y -CONFIG_TMPFS_POSIX_ACL=y -CONFIG_CRAMFS=y -CONFIG_ROMFS_FS=y -CONFIG_PARTITION_ADVANCED=y -CONFIG_BSD_DISKLABEL=y -CONFIG_SOLARIS_X86_PARTITION=y -CONFIG_NLS_CODEPAGE_437=y -CONFIG_NLS_ASCII=y -CONFIG_NLS_ISO8859_1=y -CONFIG_MAGIC_SYSRQ=y -CONFIG_DEBUG_KERNEL=y -# CONFIG_DEBUG_PREEMPT is not set -CONFIG_DEBUG_RT_MUTEXES=y -CONFIG_DEBUG_SPINLOCK=y -CONFIG_DEBUG_MUTEXES=y -CONFIG_DEBUG_SPINLOCK_SLEEP=y -CONFIG_DEBUG_INFO=y -# CONFIG_RCU_CPU_STALL_DETECTOR is not set -CONFIG_SYSCTL_SYSCALL_CHECK=y -CONFIG_DEBUG_USER=y -CONFIG_DEBUG_ERRORS=y -CONFIG_DEBUG_LL=y -CONFIG_EARLY_PRINTK=y -CONFIG_DEBUG_S3C_UART=1 -CONFIG_CRC_CCITT=y diff --git a/arch/arm/configs/s5pv210_defconfig b/arch/arm/configs/s5pv210_defconfig index 1753836..b2fbbff 100644 --- a/arch/arm/configs/s5pv210_defconfig +++ b/arch/arm/configs/s5pv210_defconfig @@ -7,6 +7,10 @@ CONFIG_MODULE_UNLOAD=y # CONFIG_BLK_DEV_BSG is not set CONFIG_ARCH_S5PV210=y CONFIG_S3C_LOWLEVEL_UART_PORT=1 +CONFIG_S3C_DEV_FB=y +CONFIG_S5PV210_SETUP_FB_24BPP=y +CONFIG_MACH_AQUILA=y +CONFIG_MACH_SMDKC110=y CONFIG_MACH_SMDKV210=y CONFIG_VMSPLIT_2G=y CONFIG_PREEMPT=y diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig index 7e2e1eb..e7b98bf 100644 --- a/arch/arm/mach-s5pv210/Kconfig +++ b/arch/arm/mach-s5pv210/Kconfig @@ -43,10 +43,10 @@ config S5PV210_SETUP_SDHCI_GPIO help Common setup code for SDHCI gpio. -# machine support +menu S5PC110 Machines config MACH_AQUILA - bool Samsung Aquila + bool Aquila select CPU_S5PV210 select ARCH_SPARSEMEM_ENABLE select S5PV210_SETUP_FB_24BPP @@ -64,11 +64,25 @@ config MACH_GONI Machine support for Samsung GONI board S5PC110(MCP) is one of package option of S5PV210 +config MACH_SMDKC110 + bool SMDKC110 + select CPU_S5PV210 + select ARCH_SPARSEMEM_ENABLE + select S3C_DEV_WDT + select HAVE_S3C2410_WATCHDOG + help + Machine support for Samsung SMDKC110 + S5PC110(MCP) is one of package option of S5PV210 + +endmenu + config S5PC110_DEV_ONENAND bool help Compile in platform device definition for OneNAND1 controller +menu S5PV210 Machines + config MACH_SMDKV210 bool SMDKV210 select CPU_S5PV210 @@ -80,14 +94,6 @@ config MACH_SMDKV210 help Machine support for Samsung SMDKV210 -config MACH_SMDKC110 - bool SMDKC110 - select CPU_S5PV210 - select ARCH_SPARSEMEM_ENABLE - select S3C_DEV_WDT - select HAVE_S3C2410_WATCHDOG - help - Machine support for Samsung SMDKC110
Re: [PATCH 1/3] arm: s5pv210: GONI: add support for framebuffer
On Wed, Jul 14, 2010 at 4:30 PM, Marek Szyprowski
m.szyprow...@samsung.com wrote:
Hello,
On Wednesday, July 14, 2010 8:48 AM Kukjin Kim wrote:
Marek Szyprowski wrote:
This patch adds required platform definitions to enable s3c-fb
driver on GONI board. One framebuffer window in 480x800x16bpp mode is
defined.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-s5pv210/Kconfig | 2 +
arch/arm/mach-s5pv210/mach-goni.c | 39
+
2 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-
s5pv210/Kconfig
index 5e88941..8ab4bb0 100644
--- a/arch/arm/mach-s5pv210/Kconfig
+++ b/arch/arm/mach-s5pv210/Kconfig
@@ -59,6 +59,8 @@ config MACH_GONI
bool GONI
select CPU_S5PV210
select ARCH_SPARSEMEM_ENABLE
+ select S5PV210_SETUP_FB_24BPP
+ select S3C_DEV_FB
select S5PC110_DEV_ONENAND
help
Machine support for Samsung GONI board
diff --git a/arch/arm/mach-s5pv210/mach-goni.c
b/arch/arm/mach-s5pv210/mach-
goni.c
index 88c38e3..05b4a1a 100644
--- a/arch/arm/mach-s5pv210/mach-goni.c
+++ b/arch/arm/mach-s5pv210/mach-goni.c
@@ -12,6 +12,9 @@
#include linux/types.h
#include linux/init.h
#include linux/serial_core.h
+#include linux/fb.h
+#include linux/delay.h
need linux/delay.h in here?
+#include linux/clk.h
same...need linux/clk.h?
#include asm/mach/arch.h
#include asm/mach/map.h
@@ -20,11 +23,15 @@
#include mach/map.h
#include mach/regs-clock.h
+#include mach/regs-fb.h
+#include mach/gpio.h
linux/gpio.h
Ok.
+#include plat/gpio-cfg.h
#include plat/regs-serial.h
#include plat/s5pv210.h
#include plat/devs.h
#include plat/cpu.h
+#include plat/fb.h
/* Following are default values for UCON, ULCON and UFCON UART registers
*/
#define S5PV210_UCON_DEFAULT (S3C2410_UCON_TXILEVEL | \
@@ -73,7 +80,35 @@ static struct s3c2410_uartcfg goni_uartcfgs[]
__initdata = {
},
};
+/* Frame Buffer */
No need this comment because we know _fb_ means frame buffer...
Comments in the source code are imho always welcome. As you know mach-*.c
files
grows to very large sizes and it is much easier to read them if all
definitions
and items are grouped and commented with a header on top of them (with such
comments you easily can notice where one group starts and ends without reading
the code).
+static struct s3c_fb_pd_win goni_fb_win0 = {
How about to use goni_fb_win[] array so that can be extended easily...
I've just followed the style used in the other mach-*.c files. No problem to
change it.
+ .win_mode = {
+ .pixclock = 1ULL /
((16+16+2+480)*(28+3+2+800)*55),
Marugu(?) send the patch remove pixclock at fb mailing list. So If
+ .left_margin = 16,
+ .right_margin = 16,
+ .upper_margin = 3,
+ .lower_margin = 28,
+ .hsync_len = 2,
+ .vsync_len = 2,
+ .xres = 480,
+ .yres = 800,
+ .refresh = 55,
+ },
+ .max_bpp = 32,
+ .default_bpp = 16,
If possible, please keep the align like below...for easily reading...
But...it depends on your taste...:-)
Ok, no problem with this.
+ .win_mode = {
+ .pixclock = 1ULL /
((16+16+2+480)*(28+3+2+800)*55),
Maurus send the patch remove pixclock calculation so I hope his patch
merge and we just remove it at here.
Thank you,
Kyungmin Park
+ .left_margin = 16,
+ .right_margin = 16,
+ .upper_margin = 3,
+ .lower_margin = 28,
+ .hsync_len = 2,
+ .vsync_len = 2,
+ .xres = 480,
+ .yres = 800,
+ .refresh = 55,
+ },
+ .max_bpp = 32,
+ .default_bpp = 16,
+};
+
+static struct s3c_fb_platdata goni_lcd_pdata __initdata = {
+ .win[0] = goni_fb_win0,
+ .vidcon0 = VIDCON0_VIDOUT_RGB |
VIDCON0_PNRMODE_RGB |
+ VIDCON0_CLKSEL_LCD,
+ .vidcon1 = VIDCON1_INV_VCLK | VIDCON1_INV_VDEN
+ | VIDCON1_INV_HSYNC |
VIDCON1_INV_VSYNC,
+ .setup_gpio = s5pv210_fb_gpio_setup_24bpp,
+};
Same...as previous comment.
+
static struct platform_device *goni_devices[] __initdata = {
+ s3c_device_fb,
s5pc110_device_onenand,
};
@@ -86,6 +121,10 @@ static void __init goni_map_io(void)
static void __init goni_machine_init(void)
{
+
no need above empty line.
+ /* FB */
+ s3c_fb_set_platdata(goni_lcd_pdata);
+
platform_add_devices(goni_devices, ARRAY_SIZE(goni_devices));
}
--
Thanks.
Best regards,
Kgene
Re: [PATCH v2] ARM: s5pv210_defconfig: Update for removing s5pc110_defconfig
On Wed, Jul 14, 2010 at 10:15 PM, Marek Szyprowski m.szyprow...@samsung.com wrote: Hello, On Tuesday, July 13, 2010 4:22 AM Kukjin Kim wrote: Now that S5PC110 machines and S5PV210 machines can be built into one kernel, update mach-s5pv210/Kconfig and s5pv210_defconfig. Tested on SMDKC110(S5PC110) and SMDKV210(S5PV210). Note that GONI machine ID is not included in the kernel. Russell finally updated mach-types in his latest kernel tree: http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-arm.git/ (master branch). I've tested this patch with Aquila and GONI boards and it's ok. Created and tested against linux-2.6.35-rc5. Signed-off-by: Kukjin Kim kgene@samsung.com Acked-by: Marek Szyprowski m.szyprow...@samsung.com --- Changes since v1: - This patch re-based against linux-2.6.35-rc5 which includes 'ARM: reduce defconfigs' from Uwe Kleine-Konig. No need to update board_defconfig since the latest merge removes the all arm *_defconfig. Thank you, Kyungmin Park arch/arm/configs/s5pc110_defconfig | 66 arch/arm/configs/s5pv210_defconfig | 4 ++ arch/arm/mach-s5pv210/Kconfig | 28 +-- 3 files changed, 21 insertions(+), 77 deletions(-) delete mode 100644 arch/arm/configs/s5pc110_defconfig diff --git a/arch/arm/configs/s5pc110_defconfig b/arch/arm/configs/s5pc110_defconfig deleted file mode 100644 index 22c2d14..000 --- a/arch/arm/configs/s5pc110_defconfig +++ /dev/null @@ -1,66 +0,0 @@ -CONFIG_EXPERIMENTAL=y -CONFIG_SYSFS_DEPRECATED_V2=y -CONFIG_BLK_DEV_INITRD=y -CONFIG_KALLSYMS_ALL=y -CONFIG_MODULES=y -CONFIG_MODULE_UNLOAD=y -# CONFIG_BLK_DEV_BSG is not set -CONFIG_ARCH_S5PV210=y -CONFIG_S3C_LOWLEVEL_UART_PORT=1 -CONFIG_MACH_SMDKC110=y -CONFIG_VMSPLIT_2G=y -CONFIG_PREEMPT=y -CONFIG_AEABI=y -CONFIG_CMDLINE=root=/dev/ram0 rw ramdisk=8192 initrd=0x2080,8M console=ttySAC1,115200 init=/linuxrc -CONFIG_VFP=y -CONFIG_NEON=y -CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug -CONFIG_BLK_DEV_LOOP=y -CONFIG_BLK_DEV_RAM=y -CONFIG_BLK_DEV_RAM_SIZE=8192 -# CONFIG_MISC_DEVICES is not set -CONFIG_SCSI=y -CONFIG_BLK_DEV_SD=y -CONFIG_CHR_DEV_SG=y -CONFIG_INPUT_EVDEV=y -# CONFIG_INPUT_KEYBOARD is not set -# CONFIG_INPUT_MOUSE is not set -CONFIG_INPUT_TOUCHSCREEN=y -CONFIG_SERIAL_8250=y -CONFIG_SERIAL_SAMSUNG=y -CONFIG_SERIAL_SAMSUNG_CONSOLE=y -CONFIG_HW_RANDOM=y -# CONFIG_HWMON is not set -# CONFIG_VGA_CONSOLE is not set -# CONFIG_HID_SUPPORT is not set -# CONFIG_USB_SUPPORT is not set -CONFIG_EXT2_FS=y -CONFIG_INOTIFY=y -CONFIG_MSDOS_FS=y -CONFIG_VFAT_FS=y -CONFIG_TMPFS=y -CONFIG_TMPFS_POSIX_ACL=y -CONFIG_CRAMFS=y -CONFIG_ROMFS_FS=y -CONFIG_PARTITION_ADVANCED=y -CONFIG_BSD_DISKLABEL=y -CONFIG_SOLARIS_X86_PARTITION=y -CONFIG_NLS_CODEPAGE_437=y -CONFIG_NLS_ASCII=y -CONFIG_NLS_ISO8859_1=y -CONFIG_MAGIC_SYSRQ=y -CONFIG_DEBUG_KERNEL=y -# CONFIG_DEBUG_PREEMPT is not set -CONFIG_DEBUG_RT_MUTEXES=y -CONFIG_DEBUG_SPINLOCK=y -CONFIG_DEBUG_MUTEXES=y -CONFIG_DEBUG_SPINLOCK_SLEEP=y -CONFIG_DEBUG_INFO=y -# CONFIG_RCU_CPU_STALL_DETECTOR is not set -CONFIG_SYSCTL_SYSCALL_CHECK=y -CONFIG_DEBUG_USER=y -CONFIG_DEBUG_ERRORS=y -CONFIG_DEBUG_LL=y -CONFIG_EARLY_PRINTK=y -CONFIG_DEBUG_S3C_UART=1 -CONFIG_CRC_CCITT=y diff --git a/arch/arm/configs/s5pv210_defconfig b/arch/arm/configs/s5pv210_defconfig index 1753836..b2fbbff 100644 --- a/arch/arm/configs/s5pv210_defconfig +++ b/arch/arm/configs/s5pv210_defconfig @@ -7,6 +7,10 @@ CONFIG_MODULE_UNLOAD=y # CONFIG_BLK_DEV_BSG is not set CONFIG_ARCH_S5PV210=y CONFIG_S3C_LOWLEVEL_UART_PORT=1 +CONFIG_S3C_DEV_FB=y +CONFIG_S5PV210_SETUP_FB_24BPP=y +CONFIG_MACH_AQUILA=y +CONFIG_MACH_SMDKC110=y CONFIG_MACH_SMDKV210=y CONFIG_VMSPLIT_2G=y CONFIG_PREEMPT=y diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig index 7e2e1eb..e7b98bf 100644 --- a/arch/arm/mach-s5pv210/Kconfig +++ b/arch/arm/mach-s5pv210/Kconfig @@ -43,10 +43,10 @@ config S5PV210_SETUP_SDHCI_GPIO help Common setup code for SDHCI gpio. -# machine support +menu S5PC110 Machines config MACH_AQUILA - bool Samsung Aquila + bool Aquila select CPU_S5PV210 select ARCH_SPARSEMEM_ENABLE select S5PV210_SETUP_FB_24BPP @@ -64,11 +64,25 @@ config MACH_GONI Machine support for Samsung GONI board S5PC110(MCP) is one of package option of S5PV210 +config MACH_SMDKC110 + bool SMDKC110 + select CPU_S5PV210 + select ARCH_SPARSEMEM_ENABLE + select S3C_DEV_WDT + select HAVE_S3C2410_WATCHDOG + help + Machine support for Samsung SMDKC110 + S5PC110(MCP) is one of package option of S5PV210 + +endmenu + config S5PC110_DEV_ONENAND bool help Compile in platform device definition for OneNAND1 controller +menu S5PV210 Machines + config MACH_SMDKV210 bool SMDKV210 select CPU_S5PV210
Re: [PATCH 3/3] i2c/busses: Select I2C bus support for S5PV210 and S5P6440.
On Fri, Jul 16, 2010 at 10:13 PM, Kukjin Kim kgene@samsung.com wrote: From: Naveen Krishna Ch ch.nav...@samsung.com This patch is to select support I2C channels 0, 1 and 2 for S5PV210 and S5P6440. Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com Signed-off-by: Kukjin Kim kgene@samsung.com --- drivers/i2c/busses/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index bceafbf..e553fe8 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -523,7 +523,7 @@ config I2C_PXA_SLAVE config I2C_S3C2410 tristate S3C2410 I2C Driver - depends on ARCH_S3C2410 || ARCH_S3C64XX + depends on ARCH_S3C2410 || ARCH_S3C64XX || ARCH_S5PV210 || ARCH_S5P6440 Are there any SoCs don't have i2c? If no, how about to just depends on PLAT_SAMSUNG. Thank you, Kyungmin Park help Say Y here to include support for I2C controller in the Samsung S3C2410 based System-on-Chip devices. -- 1.6.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 -- 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 2/5] ARM: S5P: Added default pll values for APLL 800/1000MHz
On Fri, Jul 16, 2010 at 9:22 PM, Kukjin Kim kgene@samsung.com wrote:
MyungJoo Ham wrote:
CPUFREQ of S5PV210 uses different APLL settings and we provide
such values for CPUFREQ at pll.h. We have been using differently
between EVT0 and EVT1 machines. Although this version of kernel
assumes that the CPU is EVT1, users may use code for EVT0 later.
Note that at 1GHz of ARMCLK, APLL should be 1GHz and for other lower
ARMCLK, APLL should be 800MHz.
Signed-off-by: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/plat-s5p/include/plat/pll.h | 8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-s5p/include/plat/pll.h
b/arch/arm/plat-s5p/include/plat/pll.h
index 7db3227..3112aba 100644
--- a/arch/arm/plat-s5p/include/plat/pll.h
+++ b/arch/arm/plat-s5p/include/plat/pll.h
@@ -21,6 +21,14 @@
#include asm/div64.h
+#ifdef CONFIG_CPU_S5PC110_EVT0_ERRATA
Actually, EVT0 is not real chip and not for mass production.
So don't use in here.
But we got too many board and want to use it. ARM core is also has
some workaround to fix internal bug. so you can regard it.
config S5PC110_WORKAROUND
help
Early s5pc110 has some errata blah blah ... To fix it you can enable it.
Thank you,
Kyungmin Park
+#define PLL45XX_APLL_VAL_1000 (1 31) | (0xfa16) | (0x68) |
(0x1)
+#define PLL45XX_APLL_VAL_800 (1 31) | (0xc816) | (0x68) | (0x1)
+#else
+#define PLL45XX_APLL_VAL_1000 (1 31) | (12516) | (38) | (1)
+#define PLL45XX_APLL_VAL_800 (1 31) | (10016) | (38) | (1)
+#endif
+
enum pll45xx_type_t {
pll_4500,
pll_4502,
--
And...I got the below result from scripts/checkpatch.pl.
--
ERROR: Macros with complex values should be enclosed in parenthesis
#27: FILE: arch/arm/plat-s5p/include/plat/pll.h:25:
+#define PLL45XX_APLL_VAL_1000 (1 31) | (0xfa16) | (0x68) | (0x1)
ERROR: Macros with complex values should be enclosed in parenthesis
#28: FILE: arch/arm/plat-s5p/include/plat/pll.h:26:
+#define PLL45XX_APLL_VAL_800 (1 31) | (0xc816) | (0x68) | (0x1)
ERROR: Macros with complex values should be enclosed in parenthesis
#30: FILE: arch/arm/plat-s5p/include/plat/pll.h:28:
+#define PLL45XX_APLL_VAL_1000 (1 31) | (12516) | (38) | (1)
ERROR: Macros with complex values should be enclosed in parenthesis
#31: FILE: arch/arm/plat-s5p/include/plat/pll.h:29:
+#define PLL45XX_APLL_VAL_800 (1 31) | (10016) | (38) | (1)
total: 4 errors, 0 warnings, 14 lines checked
--
I already said to you about that :-(
See the Documentation/SubmittingPatches...
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, 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
--
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 2/8] ARM: S5PV310: Add new CPU initialization support
To Ben,
Now you are working on make a single kernel for s5p series at your git.
The v310 or c210 chip also included in these works.
Previous time Marek sent the mail if you are busy with other works, he
can help it.
Give your opinions.
TO Changhwan or Kukjin
Did you see the ben's work? If yes, can you make it similar way?
Thank you,
Kyungmin Park
On Fri, Jul 16, 2010 at 8:52 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Jul 16, 2010 at 05:58:28PM +0900, Kukjin Kim wrote:
diff --git a/arch/arm/mach-s5pv310/platsmp.c
b/arch/arm/mach-s5pv310/platsmp.c
new file mode 100644
index 000..9325ac2
--- /dev/null
+++ b/arch/arm/mach-s5pv310/platsmp.c
@@ -0,0 +1,212 @@
+/* linux/arch/arm/mach-s5pv310/platsmp.c
+ *
+ * Copyright (c) 2010 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * Cloned from linux/arch/arm/mach-realview/platsmp.c
+ *
+ * Copyright (C) 2002 ARM Ltd.
+ * All Rights Reserved
+ *
+ * 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/init.h
+#include linux/errno.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/jiffies.h
+#include linux/smp.h
+#include linux/io.h
+
+#include asm/cacheflush.h
+#include mach/hardware.h
+#include asm/mach-types.h
+#include asm/localtimer.h
+#include asm/unified.h
+
+#include asm/smp_scu.h
+#include mach/regs-clock.h
+
+extern void s5pv310_secondary_startup(void);
+
+/*
+ * control for which core is the next to come out of the secondary
+ * boot holding pen
+ */
+volatile int __cpuinitdata pen_release = -1;
+
+static void __iomem *scu_base_addr(void)
+{
+ return (void __iomem *)(S5P_VA_SCU);
+}
+
+static inline unsigned int get_core_count(void)
+{
+ void __iomem *scu_base = scu_base_addr();
+ if (scu_base)
+ return scu_get_core_count(scu_base);
+ return 1;
+}
+
+static DEFINE_SPINLOCK(boot_lock);
+
+void __cpuinit platform_secondary_init(unsigned int cpu)
+{
+ trace_hardirqs_off();
+
+ /*
+ * if any interrupts are already enabled for the primary
+ * core (e.g. timer irq), then they will not have been enabled
+ * for us: do so
+ */
+ gic_cpu_init(0, gic_cpu_base_addr);
+
+ /*
+ * let the primary processor know we're out of the
+ * pen, then head off into the C entry point
+ */
+ pen_release = -1;
+ smp_wmb();
+
+ /*
+ * Synchronise with the boot thread.
+ */
+ spin_lock(boot_lock);
+ spin_unlock(boot_lock);
+}
+
+int __cpuinit boot_secondary(unsigned int cpu, struct task_struct *idle)
+{
+ unsigned long timeout;
+
+ /*
+ * set synchronisation state between this boot processor
+ * and the secondary one
+ */
+ spin_lock(boot_lock);
+
+ /*
+ * The secondary processor is waiting to be released from
+ * the holding pen - release it, then wait for it to flag
+ * that it has been released by resetting pen_release.
+ *
+ * Note that pen_release is the hardware CPU ID, whereas
+ * cpu is Linux's internal ID.
+ */
+ pen_release = cpu;
+ flush_cache_all();
+
+ /*
+ * XXX
+ *
+ * This is a later addition to the booting protocol: the
+ * bootMonitor now puts secondary cores into WFI, so
+ * poke_milo() no longer gets the cores moving; we need
+ * to send a soft interrupt to wake the secondary core.
+ * Use smp_cross_call() for this, since there's little
+ * point duplicating the code here
+ */
+ smp_cross_call(cpumask_of(cpu));
+
+ timeout = jiffies + (1 * HZ);
+ while (time_before(jiffies, timeout)) {
+ smp_rmb();
+ if (pen_release == -1)
+ break;
+
+ udelay(10);
+ }
+
+ /*
+ * now the secondary core is starting up let it run its
+ * calibrations, then wait for it to finish
+ */
+ spin_unlock(boot_lock);
+
+ return pen_release != -1 ? -ENOSYS : 0;
+}
+
+static void __init poke_milo(void)
+{
+ /* nobody is to be released from the pen yet */
+ pen_release = -1;
+
+ /*
+ * Write the address of secondary startup into the system-wide flags
+ * register. The BootMonitor waits for this register to become
+ * non-zero.
+ */
+ __raw_writel(BSYM(virt_to_phys(s5pv310_secondary_startup)),
S5P_INFORM0);
+
+ mb();
+}
+
+/*
+ * Initialise the CPU possible map early - this describes the CPUs
+ * which may be present or become present in the system.
+ */
+void __init smp_init_cpus(void)
+{
+ unsigned int i, ncores = get_core_count();
+
+ for (i = 0; i ncores; i++)
+ set_cpu_possible(i, true);
+}
+
+void __init
Re: [PATCH v3 1/7] ARM: S5PV210: Add a Kconfig entry S5PC110_EVT0_WORKAROUND
On Mon, Jul 19, 2010 at 4:59 PM, Kukjin Kim kgene@samsung.com wrote: MyungJoo Ham wrote: Early S5PC110 (EVT0) chip had some issues required workaround from a kernel. We can add such workaround codes with this Kconfig entry. Signed-off-by: MyungJoo Ham myungjoo@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- arch/arm/mach-s5pv210/Kconfig | 7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig index 631019a..18802e7 100644 --- a/arch/arm/mach-s5pv210/Kconfig +++ b/arch/arm/mach-s5pv210/Kconfig @@ -101,4 +101,11 @@ config MACH_SMDKC110 Machine support for Samsung SMDKC110 S5PC110(MCP) is one of package option of S5PV210 +config S5PC110_EVT0_WORKAROUND + bool S5PC110 Early Chip Workaround (EVT0) + help + Early S5PC110 (so called EVT0) has errata items that should be + addressed; otherwise the kernel may panic or be locked up. Enable + this option to execute workaround instructions. + endif -- As I said earlier, EVT0 is not real chip and not for mass production. Why do you submit the EVT0 patch which can only available for you? It is better to not add code into mainline that is not going to be used. Did you read the previous mail? I explain that. The LSI focus the latest SoCs. but we got the early chip and used it. You see the chip itself but I see the product which used the chips whether for mass production or not. Actually it's management and maintenance problem. you only show the latest codes and chips to outside. but I want to maintain our board at mainline. Thank you, Kyungmin 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
Re: [PATCH v3 2/8] ARM: S5PV310: Add new CPU initialization support
On Tue, Jul 20, 2010 at 9:11 PM, Kukjin Kim kgene@samsung.com wrote:
From: Changhwan Youn chaos.y...@samsung.com
This patch adds Samsung S5PV310/S5PC210 CPU support.
The S5PV310/S5PC210 integrates a ARM Cortex A9 multi-core.
Signed-off-by: Changhwan Youn chaos.y...@samsung.com
Signed-off-by: Jongpill Lee boyko@samsung.com
Signed-off-by: Jiseong Oh jiseong...@samsung.com
Signed-off-by: Kukjin Kim kgene@samsung.com
---
Changes since v2:
- Re-model platsmp.c on the Versatile Express as per Russell King's
suggestion.
And tested on the board.
- Compared Versatile Express SMP code with Realview SMP code and modified as
needed.
arch/arm/mach-s5pv310/cpu.c | 122 ++
arch/arm/mach-s5pv310/headsmp.S | 41 +
arch/arm/mach-s5pv310/include/mach/debug-macro.S | 36
arch/arm/mach-s5pv310/include/mach/entry-macro.S | 84 ++
arch/arm/mach-s5pv310/include/mach/gpio.h | 135 +++
arch/arm/mach-s5pv310/include/mach/hardware.h | 18 ++
arch/arm/mach-s5pv310/include/mach/io.h | 26 +++
arch/arm/mach-s5pv310/include/mach/map.h | 66
arch/arm/mach-s5pv310/include/mach/memory.h | 22 +++
arch/arm/mach-s5pv310/include/mach/smp.h | 29
arch/arm/mach-s5pv310/include/mach/system.h | 22 +++
arch/arm/mach-s5pv310/include/mach/timex.h | 29
arch/arm/mach-s5pv310/include/mach/uncompress.h | 27 +++
arch/arm/mach-s5pv310/include/mach/vmalloc.h | 22 +++
arch/arm/mach-s5pv310/init.c | 41 +
arch/arm/mach-s5pv310/platsmp.c | 192
++
arch/arm/mach-s5pv310/setup-i2c0.c | 20 +++
arch/arm/plat-s5p/cpu.c | 12 ++
arch/arm/plat-s5p/include/plat/map-s5p.h | 12 ++
arch/arm/plat-s5p/include/plat/s5pv310.h | 33
20 files changed, 989 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-s5pv310/cpu.c
create mode 100644 arch/arm/mach-s5pv310/headsmp.S
create mode 100644 arch/arm/mach-s5pv310/include/mach/debug-macro.S
create mode 100644 arch/arm/mach-s5pv310/include/mach/entry-macro.S
create mode 100644 arch/arm/mach-s5pv310/include/mach/gpio.h
create mode 100644 arch/arm/mach-s5pv310/include/mach/hardware.h
create mode 100644 arch/arm/mach-s5pv310/include/mach/io.h
create mode 100644 arch/arm/mach-s5pv310/include/mach/map.h
create mode 100644 arch/arm/mach-s5pv310/include/mach/memory.h
create mode 100644 arch/arm/mach-s5pv310/include/mach/smp.h
create mode 100644 arch/arm/mach-s5pv310/include/mach/system.h
create mode 100644 arch/arm/mach-s5pv310/include/mach/timex.h
create mode 100644 arch/arm/mach-s5pv310/include/mach/uncompress.h
create mode 100644 arch/arm/mach-s5pv310/include/mach/vmalloc.h
create mode 100644 arch/arm/mach-s5pv310/init.c
create mode 100644 arch/arm/mach-s5pv310/platsmp.c
create mode 100644 arch/arm/mach-s5pv310/setup-i2c0.c
create mode 100644 arch/arm/plat-s5p/include/plat/s5pv310.h
diff --git a/arch/arm/mach-s5pv310/cpu.c b/arch/arm/mach-s5pv310/cpu.c
new file mode 100644
index 000..196c9f1
--- /dev/null
+++ b/arch/arm/mach-s5pv310/cpu.c
@@ -0,0 +1,122 @@
+/* linux/arch/arm/mach-s5pv310/cpu.c
+ *
+ * Copyright (c) 2010 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * 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/sched.h
+#include linux/sysdev.h
+
+#include asm/mach/map.h
+#include asm/mach/irq.h
+
+#include asm/proc-fns.h
+
+#include plat/cpu.h
+#include plat/clock.h
+#include plat/s5pv310.h
+
+#include mach/regs-irq.h
+
+void __iomem *gic_cpu_base_addr;
+
+extern int combiner_init(unsigned int combiner_nr, void __iomem *base,
+ unsigned int irq_start);
+extern void combiner_cascade_irq(unsigned int combiner_nr, unsigned int irq);
+
+/* Initial IO mappings */
+static struct map_desc s5pv310_iodesc[] __initdata = {
+ {
+ .virtual = (unsigned long)S5P_VA_COREPERI_BASE,
+ .pfn = __phys_to_pfn(S5PV310_PA_COREPERI),
+ .length = SZ_8K,
+ .type = MT_DEVICE,
+ }, {
+ .virtual = (unsigned long)S5P_VA_COMBINER_BASE,
+ .pfn = __phys_to_pfn(S5PV310_PA_COMBINER),
+ .length = SZ_4K,
+ .type = MT_DEVICE,
+ }, {
+ .virtual = (unsigned long)S5P_VA_L2CC,
+ .pfn = __phys_to_pfn(S5PV310_PA_L2CC),
+ .length = SZ_4K,
+ .type = MT_DEVICE,
+ },
+};
+
+static void
Re: [PATCH] ARM: SAMSUNG: Make RTC driver dependency SoC specific instead of machine specific
I don't see the Samsung SoCs don't have RTC feature. I think S3C_RTC only depends on PLAT_SAMSUNG so PLAT_SAMSUNG select HAVE_S3C_RTC is enough. Thank you, Kyungmin Park On Wed, Jul 21, 2010 at 6:00 PM, Kukjin Kim kgene@samsung.com wrote: From: Atul Dahiya atul.dah...@samsung.com This patch moves the dependency of RTC driver from MACH_XXX(board) to ARCH_XXX(SoC). This will enable all machines using Samsung S5P6440, S5PC100 and S5PV210 SoCs to use RTC driver by default. Signed-off-by: Atul Dahiya atul.dah...@samsung.com Signed-off-by: Kukjin Kim kgene@samsung.com --- arch/arm/Kconfig | 3 +++ arch/arm/mach-s5p6440/Kconfig | 1 - arch/arm/mach-s5pc100/Kconfig | 1 - arch/arm/mach-s5pv210/Kconfig | 2 -- 4 files changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 98922f7..ea668a4 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -672,6 +672,7 @@ config ARCH_S5P6440 select GENERIC_GPIO select HAVE_CLK select ARCH_USES_GETTIMEOFFSET + select HAVE_S3C_RTC help Samsung S5P6440 CPU based systems @@ -691,6 +692,7 @@ config ARCH_S5PC100 select CPU_V7 select ARM_L1_CACHE_SHIFT_6 select ARCH_USES_GETTIMEOFFSET + select HAVE_S3C_RTC help Samsung S5PC100 series based systems @@ -701,6 +703,7 @@ config ARCH_S5PV210 select HAVE_CLK select ARM_L1_CACHE_SHIFT_6 select ARCH_USES_GETTIMEOFFSET + select HAVE_S3C_RTC help Samsung S5PV210/S5PC110 series based systems diff --git a/arch/arm/mach-s5p6440/Kconfig b/arch/arm/mach-s5p6440/Kconfig index b2d4716..de8f08d 100644 --- a/arch/arm/mach-s5p6440/Kconfig +++ b/arch/arm/mach-s5p6440/Kconfig @@ -20,7 +20,6 @@ config MACH_SMDK6440 select SAMSUNG_DEV_ADC select S3C_DEV_RTC select S3C_DEV_WDT - select HAVE_S3C_RTC select HAVE_S3C2410_WATCHDOG help Machine support for the Samsung SMDK6440 diff --git a/arch/arm/mach-s5pc100/Kconfig b/arch/arm/mach-s5pc100/Kconfig index 2602895..e9c3d98 100644 --- a/arch/arm/mach-s5pc100/Kconfig +++ b/arch/arm/mach-s5pc100/Kconfig @@ -48,7 +48,6 @@ config MACH_SMDKC100 select S5PC100_SETUP_FB_24BPP select S5PC100_SETUP_I2C1 select S5PC100_SETUP_SDHCI - select HAVE_S3C_RTC help Machine support for the Samsung SMDKC100 diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig index 04597cc..7f029d1 100644 --- a/arch/arm/mach-s5pv210/Kconfig +++ b/arch/arm/mach-s5pv210/Kconfig @@ -75,7 +75,6 @@ config MACH_SMDKV210 select SAMSUNG_DEV_TS select S3C_DEV_RTC select S3C_DEV_WDT - select HAVE_S3C_RTC select HAVE_S3C2410_WATCHDOG help Machine support for Samsung SMDKV210 @@ -86,7 +85,6 @@ config MACH_SMDKC110 select ARCH_SPARSEMEM_ENABLE select S3C_DEV_RTC select S3C_DEV_WDT - select HAVE_S3C_RTC select HAVE_S3C2410_WATCHDOG help Machine support for Samsung SMDKC110 -- 1.6.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 -- 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 2/3] ARM: S5PV210: Add support for I2C devices on SMDKV210 and SMDKC110
which tree do you use? If not fix the s5pv210_IIC2_IRQ correcly, it
can't compile it.
but I'm not see related patch at mailing list.
Thank you,
Kyungmin Park
On Wed, Jul 21, 2010 at 9:58 PM, Kukjin Kim kgene@samsung.com wrote:
From: Naveen Krishna Ch ch.nav...@samsung.com
This patch adds support I2C-0/1/2 devices to the SMDKV210/SMDKC110.
Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com
Signed-off-by: Kukjin Kim kgene@samsung.com
---
Changes since v1:
- Fixed the wrong name as per Kyungmin Park's comments
arch/arm/mach-s5pv210/Kconfig | 8
arch/arm/mach-s5pv210/mach-smdkc110.c | 28
arch/arm/mach-s5pv210/mach-smdkv210.c | 29 +
3 files changed, 65 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
index 0761eac..2a996d9 100644
--- a/arch/arm/mach-s5pv210/Kconfig
+++ b/arch/arm/mach-s5pv210/Kconfig
@@ -72,9 +72,13 @@ config MACH_SMDKV210
select CPU_S5PV210
select ARCH_SPARSEMEM_ENABLE
select SAMSUNG_DEV_ADC
+ select S3C_DEV_I2C1
+ select S3C_DEV_I2C2
select SAMSUNG_DEV_TS
select S3C_DEV_WDT
select HAVE_S3C2410_WATCHDOG
+ select S5PV210_SETUP_I2C1
+ select S5PV210_SETUP_I2C2
help
Machine support for Samsung SMDKV210
@@ -82,8 +86,12 @@ config MACH_SMDKC110
bool SMDKC110
select CPU_S5PV210
select ARCH_SPARSEMEM_ENABLE
+ select S3C_DEV_I2C1
+ select S3C_DEV_I2C2
select S3C_DEV_WDT
select HAVE_S3C2410_WATCHDOG
+ select S5PV210_SETUP_I2C1
+ select S5PV210_SETUP_I2C2
help
Machine support for Samsung SMDKC110
S5PC110(MCP) is one of package option of S5PV210
diff --git a/arch/arm/mach-s5pv210/mach-smdkc110.c
b/arch/arm/mach-s5pv210/mach-smdkc110.c
index 4c8903c..fcd475f 100644
--- a/arch/arm/mach-s5pv210/mach-smdkc110.c
+++ b/arch/arm/mach-s5pv210/mach-smdkc110.c
@@ -12,6 +12,7 @@
#include linux/types.h
#include linux/init.h
#include linux/serial_core.h
+#include linux/i2c.h
#include asm/mach/arch.h
#include asm/mach/map.h
@@ -25,6 +26,7 @@
#include plat/s5pv210.h
#include plat/devs.h
#include plat/cpu.h
+#include plat/iic.h
/* Following are default values for UCON, ULCON and UFCON UART registers */
#define S5PV210_UCON_DEFAULT (S3C2410_UCON_TXILEVEL | \
@@ -74,9 +76,24 @@ static struct s3c2410_uartcfg smdkv210_uartcfgs[]
__initdata = {
static struct platform_device *smdkc110_devices[] __initdata = {
s5pv210_device_iis0,
s5pv210_device_ac97,
+ s3c_device_i2c0,
+ s3c_device_i2c1,
+ s3c_device_i2c2,
s3c_device_wdt,
};
+static struct i2c_board_info smdkc110_i2c_devs0[] __initdata = {
+ { I2C_BOARD_INFO(24c08, 0x50), }, /* Samsung S524AD0XD1 */
+};
+
+static struct i2c_board_info smdkc110_i2c_devs1[] __initdata = {
+ /* To Be Updated */
+};
+
+static struct i2c_board_info smdkc110_i2c_devs2[] __initdata = {
+ /* To Be Updated */
+};
+
static void __init smdkc110_map_io(void)
{
s5p_init_io(NULL, 0, S5P_VA_CHIPID);
@@ -86,6 +103,17 @@ static void __init smdkc110_map_io(void)
static void __init smdkc110_machine_init(void)
{
+ /* I2C */
+ s3c_i2c0_set_platdata(NULL);
+ s3c_i2c1_set_platdata(NULL);
+ s3c_i2c2_set_platdata(NULL);
+ i2c_register_board_info(0, smdkc110_i2c_devs0,
+ ARRAY_SIZE(smdkc110_i2c_devs0));
+ i2c_register_board_info(1, smdkc110_i2c_devs1,
+ ARRAY_SIZE(smdkc110_i2c_devs1));
+ i2c_register_board_info(2, smdkc110_i2c_devs2,
+ ARRAY_SIZE(smdkc110_i2c_devs2));
+
platform_add_devices(smdkc110_devices, ARRAY_SIZE(smdkc110_devices));
}
diff --git a/arch/arm/mach-s5pv210/mach-smdkv210.c
b/arch/arm/mach-s5pv210/mach-smdkv210.c
index 0d46279..765f47e 100644
--- a/arch/arm/mach-s5pv210/mach-smdkv210.c
+++ b/arch/arm/mach-s5pv210/mach-smdkv210.c
@@ -10,6 +10,7 @@
#include linux/kernel.h
#include linux/types.h
+#include linux/i2c.h
#include linux/init.h
#include linux/serial_core.h
@@ -27,6 +28,7 @@
#include plat/cpu.h
#include plat/adc.h
#include plat/ts.h
+#include plat/iic.h
/* Following are default values for UCON, ULCON and UFCON UART registers */
#define S5PV210_UCON_DEFAULT (S3C2410_UCON_TXILEVEL | \
@@ -77,10 +79,25 @@ static struct platform_device *smdkv210_devices[]
__initdata = {
s5pv210_device_iis0,
s5pv210_device_ac97,
s3c_device_adc,
+ s3c_device_i2c0,
+ s3c_device_i2c1,
+ s3c_device_i2c2,
s3c_device_ts,
s3c_device_wdt,
};
+static struct i2c_board_info smdkv210_i2c_devs0[] __initdata = {
+ { I2C_BOARD_INFO(24c08, 0x50), }, /* Samsung S524AD0XD1
Re: [PATCH v3 2/8] ARM: S5PV310: Add new CPU initialization support
On Wed, Jul 21, 2010 at 9:55 PM, Kukjin Kim kgene@samsung.com wrote:
Kyungmin Park wrote:
On Tue, Jul 20, 2010 at 9:11 PM, Kukjin Kim kgene@samsung.com wrote:
From: Changhwan Youn chaos.y...@samsung.com
This patch adds Samsung S5PV310/S5PC210 CPU support.
The S5PV310/S5PC210 integrates a ARM Cortex A9 multi-core.
Signed-off-by: Changhwan Youn chaos.y...@samsung.com
Signed-off-by: Jongpill Lee boyko@samsung.com
Signed-off-by: Jiseong Oh jiseong...@samsung.com
Signed-off-by: Kukjin Kim kgene@samsung.com
---
Changes since v2:
- Re-model platsmp.c on the Versatile Express as per Russell King's
suggestion.
And tested on the board.
- Compared Versatile Express SMP code with Realview SMP code and
modified
as needed.
Hi,
(snip)
+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;
It's only valid when use the UART1. others 255 for UART0, 15 for others.
Ok..will fix it.
(snip)
+#define VMALLOC_END (0xE000)
Increase to 0xF000'. but it will be removed from Eric's patch.
Right now, the 0xE000 is no problem as default.
But I will check this is appropriate again.
Since maybe you use the 2g/2g configuration. try to use the 3g/1g
configuration with more the 512MiB.
And according to his '[PATCH 08/13] [ARM] Make VMALLOC_END into a global
variable if not defined',
it doesn't mean absolutely remove it. why did you say like that.
+#ifndef VMALLOC_END
+extern unsigned long vmalloc_end;
+#define VMALLOC_END (vmalloc_end)
+#endif
+
And if required modify it for some machine, you can do it later with
mach_desc after applying Eric's patch.
Or as Russell said, there is the way to do it is to specify a vmalloc=
parameter to the kernel.
I don't have confidence with HIGHMEM with VIPT (it's same as PIPT).
So I want to use lowmem if possible,
(snip)
+ /*
+ * Write the address of secondary startup into the
+ * system-wide flags register. The boot monitor waits
+ * until it receives a soft interrupt, and then the
+ * secondary CPU branches to this address.
+ */
+ __raw_writel(BSYM(virt_to_phys(s5pv310_secondary_startup)),
S5P_INFORM0);
Do you really use the INFORM0? historically it's used for sleep
wakeup. new SoC has several INFORM register. So I recommend to use
others.
It doesn't mean we should use INFORM0 for sleep wakeup even though
historically used.
...I mean it doesn't matter and as you know, just need to sync with
boot-loader for it.
that's reason I said, we got unused INFORM{3,4,5,...} so if we use it,
no problem.
(snip)
+void s3c_i2c0_cfg_gpio(struct platform_device *dev)
+{
+/* will be implemented later */
+}
Remove it and send separate patch. e.g.,I2C support on s5pc210.
I think i2c0 is un-conditionally compiled. So need to add i2c0 support in
here.
It mean all samsung SoC have i2c0. okay if you want it.
(snip)
+#define S5P_VA_COREPERI_BASE S3C_ADDR(0x0080)
+#define S5P_VA_COREPERI(x) (S5P_VA_COREPERI_BASE + (x))
+#define S5P_VA_SCU S5P_VA_COREPERI(0x0)
+#define S5P_VA_GIC_CPU S5P_VA_COREPERI(0x100)
+#define S5P_VA_TWD S5P_VA_COREPERI(0x600)
+#define S5P_VA_GIC_DIST S5P_VA_COREPERI(0x1000)
+
+#define S5P_VA_L2CC S3C_ADDR(0x0090)
I'm not sure it's proper prefix.
It's no problem.
(snip)
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, 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
--
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: Make RTC driver dependency SoC specific instead of machine specific
On Wed, Jul 21, 2010 at 9:29 PM, Kukjin Kim kgene@samsung.com wrote: Kyungmin Park wrote: I don't see the Samsung SoCs don't have RTC feature. Yes, you're right... But it doesn't mean the RTC driver can support every Samsung SoCs now. Vice versa, if there's problem, we can fix it easily. No need to modify Kconfig anymore, just fix it driver itself. I think S3C_RTC only depends on PLAT_SAMSUNG so PLAT_SAMSUNG select HAVE_S3C_RTC is enough. So I think, this is not bad. Thank you, Kyungmin Park On Wed, Jul 21, 2010 at 6:00 PM, Kukjin Kim kgene@samsung.com wrote: From: Atul Dahiya atul.dah...@samsung.com This patch moves the dependency of RTC driver from MACH_XXX(board) to ARCH_XXX(SoC). This will enable all machines using Samsung S5P6440, S5PC100 and S5PV210 SoCs to use RTC driver by default. Signed-off-by: Atul Dahiya atul.dah...@samsung.com Signed-off-by: Kukjin Kim kgene@samsung.com --- arch/arm/Kconfig | 3 +++ arch/arm/mach-s5p6440/Kconfig | 1 - arch/arm/mach-s5pc100/Kconfig | 1 - arch/arm/mach-s5pv210/Kconfig | 2 -- 4 files changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 98922f7..ea668a4 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -672,6 +672,7 @@ config ARCH_S5P6440 select GENERIC_GPIO select HAVE_CLK select ARCH_USES_GETTIMEOFFSET + select HAVE_S3C_RTC help Samsung S5P6440 CPU based systems @@ -691,6 +692,7 @@ config ARCH_S5PC100 select CPU_V7 select ARM_L1_CACHE_SHIFT_6 select ARCH_USES_GETTIMEOFFSET + select HAVE_S3C_RTC help Samsung S5PC100 series based systems @@ -701,6 +703,7 @@ config ARCH_S5PV210 select HAVE_CLK select ARM_L1_CACHE_SHIFT_6 select ARCH_USES_GETTIMEOFFSET + select HAVE_S3C_RTC help Samsung S5PV210/S5PC110 series based systems diff --git a/arch/arm/mach-s5p6440/Kconfig b/arch/arm/mach-s5p6440/Kconfig index b2d4716..de8f08d 100644 --- a/arch/arm/mach-s5p6440/Kconfig +++ b/arch/arm/mach-s5p6440/Kconfig @@ -20,7 +20,6 @@ config MACH_SMDK6440 select SAMSUNG_DEV_ADC select S3C_DEV_RTC select S3C_DEV_WDT - select HAVE_S3C_RTC select HAVE_S3C2410_WATCHDOG help Machine support for the Samsung SMDK6440 diff --git a/arch/arm/mach-s5pc100/Kconfig b/arch/arm/mach-s5pc100/Kconfig index 2602895..e9c3d98 100644 --- a/arch/arm/mach-s5pc100/Kconfig +++ b/arch/arm/mach-s5pc100/Kconfig @@ -48,7 +48,6 @@ config MACH_SMDKC100 select S5PC100_SETUP_FB_24BPP select S5PC100_SETUP_I2C1 select S5PC100_SETUP_SDHCI - select HAVE_S3C_RTC help Machine support for the Samsung SMDKC100 diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig index 04597cc..7f029d1 100644 --- a/arch/arm/mach-s5pv210/Kconfig +++ b/arch/arm/mach-s5pv210/Kconfig @@ -75,7 +75,6 @@ config MACH_SMDKV210 select SAMSUNG_DEV_TS select S3C_DEV_RTC select S3C_DEV_WDT - select HAVE_S3C_RTC select HAVE_S3C2410_WATCHDOG help Machine support for Samsung SMDKV210 @@ -86,7 +85,6 @@ config MACH_SMDKC110 select ARCH_SPARSEMEM_ENABLE select S3C_DEV_RTC select S3C_DEV_WDT - select HAVE_S3C_RTC select HAVE_S3C2410_WATCHDOG help Machine support for Samsung SMDKC110 -- Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, 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 3/3] i2c/busses: Select I2C bus support for S5PV210 and S5P6440.
I don't want to modify Kconfig anymore. it's simple to modify driver itself. Think the usage of I2c. I think there's no case don't use it. At this time modify Kconfig once, and just fix the driver if new SoCs are arrives. Of course we can modify Kconfig one more, If there's really new IPs of I2C are created. but I expect we also need to define new PLAT_SAMSUNG2 Thank you, Kyungmin Park On Wed, Jul 21, 2010 at 9:59 PM, Kukjin Kim kgene@samsung.com wrote: From: Naveen Krishna Ch ch.nav...@samsung.com This patch is to select support I2C channels 0, 1 and 2 for S5PV210 and S5P6440. Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com Signed-off-by: Kukjin Kim kgene@samsung.com --- Changes since v1: - Modifed the Kconfig help comments. drivers/i2c/busses/Kconfig | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index bceafbf..27c96ec 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -523,10 +523,10 @@ config I2C_PXA_SLAVE config I2C_S3C2410 tristate S3C2410 I2C Driver - depends on ARCH_S3C2410 || ARCH_S3C64XX + depends on ARCH_S3C2410 || ARCH_S3C64XX || ARCH_S5P6440 || ARCH_S5PV210 help - Say Y here to include support for I2C controller in the - Samsung S3C2410 based System-on-Chip devices. + Say Y here to include support for I2C controller in the Samsung + S3C2410, S3C64XX, S5P6440 and S5PV210 based System-on-Chip devices. config I2C_S6000 tristate S6000 I2C support -- 1.6.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 -- 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/7] ARM: S5PV210: Add a Kconfig entry S5PC110_EVT0_WORKAROUND
On Wed, Jul 21, 2010 at 8:47 PM, Ben Dooks b...@simtec.co.uk wrote: On 21/07/10 02:13, MyungJoo Ham wrote: On Wed, Jul 21, 2010 at 9:36 AM, Ben Dooks b...@simtec.co.uk wrote: On 07/19/10 06:31, MyungJoo Ham wrote: Early S5PC110 (EVT0) chip had some issues required workaround from a kernel. We can add such workaround codes with this Kconfig entry. Signed-off-by: MyungJoo Hammyungjoo@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com --- arch/arm/mach-s5pv210/Kconfig | 7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig index 631019a..18802e7 100644 --- a/arch/arm/mach-s5pv210/Kconfig +++ b/arch/arm/mach-s5pv210/Kconfig @@ -101,4 +101,11 @@ config MACH_SMDKC110 Machine support for Samsung SMDKC110 S5PC110(MCP) is one of package option of S5PV210 +config S5PC110_EVT0_WORKAROUND + bool S5PC110 Early Chip Workaround (EVT0) + help + Early S5PC110 (so called EVT0) has errata items that should be + addressed; otherwise the kernel may panic or be locked up. Enable + this option to execute workaround instructions. + endif What happens for non EVT0, is the a performance issue or is it exclusive? This S5PC110_EVT0_WORKAROUND addresses issues (erratic behaviors, not performance issues) of EVT-0 revisions, which is exclusive for these EVT-0 only. They do not apply to the later (EVT-1 and so on) chips. Ok, so does the fix work for just EVT0? Does it exclude supporting other EVT sillicon as well? Mr. Ham will reply it. As I know yes, just FYI now Mr. Ham works on it. you can see it http://git.infradead.org/users/kmpark/linux-2.6-samsung clock and cpufreq branch. If you have a good idea, give your opinions. Thank you, Kyungmin 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
Re: [PATCH v2 3/3] i2c/busses: Select I2C bus support for S5PV210 and S5P6440.
On Wed, Jul 21, 2010 at 10:55 PM, Kukjin Kim kgene@samsung.com wrote: Kyungmin Park wrote: I don't want to modify Kconfig anymore. it's simple to modify driver itself. Yeah, I think so. Think the usage of I2c. I think there's no case don't use it. At this time modify Kconfig once, and just fix the driver if new SoCs are arrives. Of course we can modify Kconfig one more, If there's really new IPs of I2C are created. but I expect we also need to define new PLAT_SAMSUNG2 Maybe you did see the Watchdog driver...I think, in this case, the depending on 'HAVE_xxx_I2C' is better than 'PLAT_xxx'. If there is newer I2C, the 'HAVE_xxx_I2Cv2' is enough. yes it's personal taste. I just don't want to modify each Kconfig for every samsung ARCH. Now your team enables Samsung SoCs peripherals and if you like this way, you should define all SoCs peripherals like this. Thank you, Kyungmin Park On Wed, Jul 21, 2010 at 9:59 PM, Kukjin Kim kgene@samsung.com wrote: From: Naveen Krishna Ch ch.nav...@samsung.com This patch is to select support I2C channels 0, 1 and 2 for S5PV210 and S5P6440. Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com Signed-off-by: Kukjin Kim kgene@samsung.com --- Changes since v1: - Modifed the Kconfig help comments. drivers/i2c/busses/Kconfig | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index bceafbf..27c96ec 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -523,10 +523,10 @@ config I2C_PXA_SLAVE config I2C_S3C2410 tristate S3C2410 I2C Driver - depends on ARCH_S3C2410 || ARCH_S3C64XX + depends on ARCH_S3C2410 || ARCH_S3C64XX || ARCH_S5P6440 || ARCH_S5PV210 help - Say Y here to include support for I2C controller in the - Samsung S3C2410 based System-on-Chip devices. + Say Y here to include support for I2C controller in the Samsung + S3C2410, S3C64XX, S5P6440 and S5PV210 based System-on-Chip devices. config I2C_S6000 tristate S6000 I2C support -- 1.6.2.5 -- Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, 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 v3 3/3] sdhci-s3c: Add SDHCI_QUIRK_NO_WP_BIT quirk for Samsung SoC
On Fri, Jul 23, 2010 at 8:56 PM, Kukjin Kim kgene@samsung.com wrote:
From: Hyuk Lee hyuk1@samsung.com
If host controller doesn't have WP pin which should be connnected with SDMMC
card WP pin, can implement get_ro function with using the allocated gpio.
In order to use this quirk wp_gpio in the platform data must be set.
Signed-off-by: Hyuk Lee hyuk1@samsung.com
Signed-off-by: Kukjin Kim kgene@samsung.com
---
drivers/mmc/host/sdhci-s3c.c | 43
++
drivers/mmc/host/sdhci.c | 3 ++
drivers/mmc/host/sdhci.h | 3 ++
3 files changed, 49 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index 0d25285..0b75e57 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -22,6 +22,7 @@
#include linux/mmc/host.h
+#include plat/gpio-cfg.h
#include plat/sdhci.h
#include plat/regs-sdhci.h
@@ -213,6 +214,36 @@ static void sdhci_s3c_set_clock(struct sdhci_host *host,
unsigned int clock)
}
/**
+ * sdhci_s3c_get_ro - callback for get_ro
+ * @host: The SDHCI host being changed
+ *
+ * If the WP pin is connected with GPIO, can get the value which indicates
+ * the card is locked or not.
+*/
+static int sdhci_s3c_get_ro(struct mmc_host *mmc)
+{
+ struct sdhci_s3c *sc;
+ struct sdhci_host *host;
+
+ host = mmc_priv(mmc);
+ sc = sdhci_priv(host);
+
+ return gpio_get_value(sc-pdata-wp_gpio);
+}
+
+/**
+ * sdhci_s3c_cfg_wp - configure GPIO for WP pin
+ * @gpio_num: GPIO number which connected with WP line from SD/MMC slot
+ *
+ * Configure GPIO for using WP line
+*/
+static void sdhci_s3c_cfg_wp(unsigned int gpio_num)
+{
+ s3c_gpio_cfgpin(gpio_num, S3C_GPIO_INPUT);
+ s3c_gpio_setpull(gpio_num, S3C_GPIO_PULL_UP);
+}
+
+/**
* sdhci_s3c_get_min_clock - callback to get minimal supported clock value
* @host: The SDHCI host being queried
*
@@ -375,6 +406,9 @@ static int __devinit sdhci_s3c_probe(struct
platform_device *pdev)
if (pdata-cfg_gpio)
pdata-cfg_gpio(pdev, pdata-max_width);
+ if (gpio_is_valid(pdata-wp_gpio))
+ sdhci_s3c_ops.get_ro = sdhci_s3c_get_ro;
+
host-hw_name = samsung-hsmmc;
host-ops = sdhci_s3c_ops;
host-quirks = 0;
@@ -408,6 +442,15 @@ static int __devinit sdhci_s3c_probe(struct
platform_device *pdev)
host-quirks |= (SDHCI_QUIRK_32BIT_DMA_ADDR |
SDHCI_QUIRK_32BIT_DMA_SIZE);
+ /* Controller's WP pin donsn't connected with SD card and there is an
+ * allocated GPIO for getting WP data form SD card, use this quirk and
+ * send the GPIO number in pdata-wp_gpio. */
+ host-quirks |= SDHCI_QUIRK_NO_WP_BIT;
+
+ /* to configure gpio pin as a card write protection signal */
+ if (gpio_is_valid(pdata-wp_gpio))
+ sdhci_s3c_cfg_wp(pdata-wp_gpio);
+
Put it just one place like this.
if (gpio_is_valid(pdata-wp_gpio)) {
sdhci_s3c_cfg_wp(pdata-wp_gpio);
sdhci_s3c_ops.get_ro = sdhci_s3c_get_ro;
host-quirks |= SDHCI_QUIRK_NO_WP_BIT;
}
It reduce the below quirks check by one. If you add the quriks as your
patch, host-quirks are always true whether WP use or not.
Thank you,
Kyungmin Park
ret = sdhci_add_host(host);
if (ret) {
dev_err(dev, sdhci_add_host() failed\n);
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index f9ca4c6..7fba401 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1198,6 +1198,9 @@ static int sdhci_get_ro(struct mmc_host *mmc)
host = mmc_priv(mmc);
+ if ((host-quirks SDHCI_QUIRK_NO_WP_BIT) host-ops-get_ro)
+ return host-ops-get_ro(mmc);
+
spin_lock_irqsave(host-lock, flags);
if (host-flags SDHCI_DEVICE_DEAD)
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 0de8b38..dd9a233 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -247,6 +247,8 @@ struct sdhci_host {
#define SDHCI_QUIRK_MISSING_CAPS (128)
/* Controller has nonstandard clock management */
#define SDHCI_QUIRK_NONSTANDARD_MINCLOCK (129)
+/* Controller has no write-protect pin connected with SD card */
+#define SDHCI_QUIRK_NO_WP_BIT (130)
int irq; /* Device IRQ */
void __iomem * ioaddr; /* Mapped address */
@@ -321,6 +323,7 @@ struct sdhci_ops {
unsigned int (*get_max_clock)(struct sdhci_host *host);
unsigned int (*get_min_clock)(struct sdhci_host *host);
unsigned int (*get_timeout_clock)(struct sdhci_host *host);
+ int (*get_ro)(struct mmc_host *mmc);
};
#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
--
1.6.2.5
--
To unsubscribe from this list: send the line
Re: [PATCH v4 5/8] ARM: S5PV310: Add Timer support
Can you confirm that during boot time, change the pwm2 pin to i2c
functions and still it's working correctly?
1. pwm2 is used for clock event at first boot.
2. during i2c init, pwm2 pin is changed to i2c functionality.
then where can get the clockevent?
Another possible scenarios is that.
pwm2 pin is changed to i2c function at bootloader to access the i2c chips.
Then below code is working?
Thank you,
Kyungmin Park
On Mon, Jul 26, 2010 at 9:42 PM, Kukjin Kim kgene@samsung.com wrote:
From: Changhwan Youn chaos.y...@samsung.com
This patch adds timer support for S5PV310. Until now, all S5P SoCs
use CONFIG_ARCH_USES_GETTIMEOFFSET macro as a default configuration.
Instead,S5PV310 implements clocksource and clock_event_device to
support the high resolution timer and tickless system.
Signed-off-by: Changhwan Youn chaos.y...@samsung.com
Signed-off-by: Hyuk Lee hyuk1@samsung.com
Signed-off-by: Kukjin Kim kgene@samsung.com
---
Changes since v3:
- Changes clock source from PWM2 to PWM4 because PWM4 cannot be used for
other purpose such as external output function through GPIO.
arch/arm/mach-s5pv310/include/mach/pwm-clock.h | 70 ++
arch/arm/mach-s5pv310/localtimer.c | 25 ++
arch/arm/mach-s5pv310/time.c | 287
arch/arm/plat-s5p/include/plat/s5pv310.h | 1 +
arch/arm/plat-samsung/Makefile | 2 +-
5 files changed, 384 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-s5pv310/include/mach/pwm-clock.h
create mode 100644 arch/arm/mach-s5pv310/localtimer.c
create mode 100644 arch/arm/mach-s5pv310/time.c
diff --git a/arch/arm/mach-s5pv310/include/mach/pwm-clock.h
b/arch/arm/mach-s5pv310/include/mach/pwm-clock.h
new file mode 100644
index 000..7e6da27
--- /dev/null
+++ b/arch/arm/mach-s5pv310/include/mach/pwm-clock.h
@@ -0,0 +1,70 @@
+/* linux/arch/arm/mach-s5pv310/include/mach/pwm-clock.h
+ *
+ * Copyright (c) 2010 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * Copyright 2008 Openmoko, Inc.
+ * Copyright 2008 Simtec Electronics
+ * Ben Dooks b...@simtec.co.uk
+ * http://armlinux.simtec.co.uk/
+ *
+ * Based on arch/arm/mach-s3c64xx/include/mach/pwm-clock.h
+ *
+ * S5PV310 - pwm clock and timer support
+ *
+ * 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.
+*/
+
+#ifndef __ASM_ARCH_PWMCLK_H
+#define __ASM_ARCH_PWMCLK_H __FILE__
+
+/**
+ * pwm_cfg_src_is_tclk() - return whether the given mux config is a tclk
+ * @tcfg: The timer TCFG1 register bits shifted down to 0.
+ *
+ * Return true if the given configuration from TCFG1 is a TCLK instead
+ * any of the TDIV clocks.
+ */
+static inline int pwm_cfg_src_is_tclk(unsigned long tcfg)
+{
+ return tcfg == S3C64XX_TCFG1_MUX_TCLK;
+}
+
+/**
+ * tcfg_to_divisor() - convert tcfg1 setting to a divisor
+ * @tcfg1: The tcfg1 setting, shifted down.
+ *
+ * Get the divisor value for the given tcfg1 setting. We assume the
+ * caller has already checked to see if this is not a TCLK source.
+ */
+static inline unsigned long tcfg_to_divisor(unsigned long tcfg1)
+{
+ return 1 tcfg1;
+}
+
+/**
+ * pwm_tdiv_has_div1() - does the tdiv setting have a /1
+ *
+ * Return true if we have a /1 in the tdiv setting.
+ */
+static inline unsigned int pwm_tdiv_has_div1(void)
+{
+ return 1;
+}
+
+/**
+ * pwm_tdiv_div_bits() - calculate TCFG1 divisor value.
+ * @div: The divisor to calculate the bit information for.
+ *
+ * Turn a divisor into the necessary bit field for TCFG1.
+ */
+static inline unsigned long pwm_tdiv_div_bits(unsigned int div)
+{
+ return ilog2(div);
+}
+
+#define S3C_TCFG1_MUX_TCLK S3C64XX_TCFG1_MUX_TCLK
+
+#endif /* __ASM_ARCH_PWMCLK_H */
diff --git a/arch/arm/mach-s5pv310/localtimer.c
b/arch/arm/mach-s5pv310/localtimer.c
new file mode 100644
index 000..2784036
--- /dev/null
+++ b/arch/arm/mach-s5pv310/localtimer.c
@@ -0,0 +1,25 @@
+/* linux/arch/arm/mach-s5pv310/localtimer.c
+ *
+ * Cloned from linux/arch/arm/mach-realview/localtimer.c
+ *
+ * Copyright (C) 2002 ARM Ltd.
+ * All Rights Reserved
+ *
+ * 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/clockchips.h
+
+#include asm/irq.h
+#include asm/localtimer.h
+
+/*
+ * Setup the local clock events for a CPU.
+ */
+void __cpuinit local_timer_setup(struct clock_event_device *evt)
+{
+ evt-irq = IRQ_LOCALTIMER;
+ twd_timer_setup(evt);
+}
diff --git a/arch/arm/mach-s5pv310/time.c b/arch/arm/mach-s5pv310/time.c
new file mode 100644
index 000..01b012a
--- /dev/null
+++ b/arch/arm/mach-s5pv310
Re: [PATCH v4 5/8] ARM: S5PV310: Add Timer support
On Tue, Jul 27, 2010 at 1:12 PM, Sangbeom Kim sbki...@samsung.com wrote:
Hi! Kyungmin,
After booting, clock event is generated by 2 arm private timers.
What do you mean by 'change the pwm2 pin to i2c functions' ?
What do you use for I2C emulation? (TOUT2 or gpio)
Could you explain it in detail?
In the spec, PWM2 is muxed with I2C_7. I muxed it I2C pin to use i2c chip.
Thank you,
Kyungmin Park
Thanks and regards,
Sangbeom Kim
Kyungmin Park kmp...@infradead.org wrote:
Can you confirm that during boot time, change the pwm2 pin to i2c
functions and still it's working correctly?
1. pwm2 is used for clock event at first boot.
2. during i2c init, pwm2 pin is changed to i2c functionality.
then where can get the clockevent?
Another possible scenarios is that.
pwm2 pin is changed to i2c function at bootloader to access the i2c chips.
Then below code is working?
Thank you,
Kyungmin Park
On Mon, Jul 26, 2010 at 9:42 PM, Kukjin Kim kgene@samsung.com wrote:
From: Changhwan Youn chaos.y...@samsung.com
This patch adds timer support for S5PV310. Until now, all S5P SoCs
use CONFIG_ARCH_USES_GETTIMEOFFSET macro as a default configuration.
Instead,S5PV310 implements clocksource and clock_event_device to
support the high resolution timer and tickless system.
Signed-off-by: Changhwan Youn chaos.y...@samsung.com
Signed-off-by: Hyuk Lee hyuk1@samsung.com
Signed-off-by: Kukjin Kim kgene@samsung.com
---
Changes since v3:
- Changes clock source from PWM2 to PWM4 because PWM4 cannot be used for
other purpose such as external output function through GPIO.
arch/arm/mach-s5pv310/include/mach/pwm-clock.h | 70 ++
arch/arm/mach-s5pv310/localtimer.c | 25 ++
arch/arm/mach-s5pv310/time.c | 287
arch/arm/plat-s5p/include/plat/s5pv310.h | 1 +
arch/arm/plat-samsung/Makefile | 2 +-
5 files changed, 384 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-s5pv310/include/mach/pwm-clock.h
create mode 100644 arch/arm/mach-s5pv310/localtimer.c
create mode 100644 arch/arm/mach-s5pv310/time.c
diff --git a/arch/arm/mach-s5pv310/include/mach/pwm-clock.h
b/arch/arm/mach-s5pv310/include/mach/pwm-clock.h
new file mode 100644
index 000..7e6da27
--- /dev/null
+++ b/arch/arm/mach-s5pv310/include/mach/pwm-clock.h
@@ -0,0 +1,70 @@
+/* linux/arch/arm/mach-s5pv310/include/mach/pwm-clock.h
+ *
+ * Copyright (c) 2010 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * Copyright 2008 Openmoko, Inc.
+ * Copyright 2008 Simtec Electronics
+ * Ben Dooks b...@simtec.co.uk
+ * http://armlinux.simtec.co.uk/
+ *
+ * Based on arch/arm/mach-s3c64xx/include/mach/pwm-clock.h
+ *
+ * S5PV310 - pwm clock and timer support
+ *
+ * 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.
+*/
+
+#ifndef __ASM_ARCH_PWMCLK_H
+#define __ASM_ARCH_PWMCLK_H __FILE__
+
+/**
+ * pwm_cfg_src_is_tclk() - return whether the given mux config is a tclk
+ * @tcfg: The timer TCFG1 register bits shifted down to 0.
+ *
+ * Return true if the given configuration from TCFG1 is a TCLK instead
+ * any of the TDIV clocks.
+ */
+static inline int pwm_cfg_src_is_tclk(unsigned long tcfg)
+{
+ return tcfg == S3C64XX_TCFG1_MUX_TCLK;
+}
+
+/**
+ * tcfg_to_divisor() - convert tcfg1 setting to a divisor
+ * @tcfg1: The tcfg1 setting, shifted down.
+ *
+ * Get the divisor value for the given tcfg1 setting. We assume the
+ * caller has already checked to see if this is not a TCLK source.
+ */
+static inline unsigned long tcfg_to_divisor(unsigned long tcfg1)
+{
+ return 1 tcfg1;
+}
+
+/**
+ * pwm_tdiv_has_div1() - does the tdiv setting have a /1
+ *
+ * Return true if we have a /1 in the tdiv setting.
+ */
+static inline unsigned int pwm_tdiv_has_div1(void)
+{
+ return 1;
+}
+
+/**
+ * pwm_tdiv_div_bits() - calculate TCFG1 divisor value.
+ * @div: The divisor to calculate the bit information for.
+ *
+ * Turn a divisor into the necessary bit field for TCFG1.
+ */
+static inline unsigned long pwm_tdiv_div_bits(unsigned int div)
+{
+ return ilog2(div);
+}
+
+#define S3C_TCFG1_MUX_TCLK S3C64XX_TCFG1_MUX_TCLK
+
+#endif /* __ASM_ARCH_PWMCLK_H */
diff --git a/arch/arm/mach-s5pv310/localtimer.c b/arch/arm/mach-
s5pv310/localtimer.c
new file mode 100644
index 000..2784036
--- /dev/null
+++ b/arch/arm/mach-s5pv310/localtimer.c
@@ -0,0 +1,25 @@
+/* linux/arch/arm/mach-s5pv310/localtimer.c
+ *
+ * Cloned from linux/arch/arm/mach-realview/localtimer.c
+ *
+ * Copyright (C) 2002 ARM Ltd.
+ * All Rights Reserved
+ *
+ * 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
Re: [PATCH v4 5/8] ARM: S5PV310: Add Timer support
You mean we can use pwm2 and I2c simultaneously since we don't use the Tout.
Do you also consider low power audio case? In the previous time to
this reason, HRT uses the RTC and systimer.
anyway thank you for clarification.
Thank you,
Kyungmin Park
On Tue, Jul 27, 2010 at 1:58 PM, Sangbeom Kim sbki...@samsung.com wrote:
Thanks for your answer,
If you want use to GPD0[2] as I2C_7, you can use it as I2C port.
Because We don't use PWM2 Tout.
We only use pwm timer2 for internal operation.
Thanks,
Kyungmin Park kmp...@infradead.org wrote:
On Tue, Jul 27, 2010 at 1:12 PM, Sangbeom Kim sbki...@samsung.com wrote:
Hi! Kyungmin,
After booting, clock event is generated by 2 arm private timers.
What do you mean by 'change the pwm2 pin to i2c functions' ?
What do you use for I2C emulation? (TOUT2 or gpio)
Could you explain it in detail?
In the spec, PWM2 is muxed with I2C_7. I muxed it I2C pin to use i2c chip.
Thank you,
Kyungmin Park
Thanks and regards,
Sangbeom Kim
Kyungmin Park kmp...@infradead.org wrote:
Can you confirm that during boot time, change the pwm2 pin to i2c
functions and still it's working correctly?
1. pwm2 is used for clock event at first boot.
2. during i2c init, pwm2 pin is changed to i2c functionality.
then where can get the clockevent?
Another possible scenarios is that.
pwm2 pin is changed to i2c function at bootloader to access the i2c
chips.
Then below code is working?
Thank you,
Kyungmin Park
On Mon, Jul 26, 2010 at 9:42 PM, Kukjin Kim kgene@samsung.com
wrote:
From: Changhwan Youn chaos.y...@samsung.com
This patch adds timer support for S5PV310. Until now, all S5P SoCs
use CONFIG_ARCH_USES_GETTIMEOFFSET macro as a default configuration.
Instead,S5PV310 implements clocksource and clock_event_device to
support the high resolution timer and tickless system.
Signed-off-by: Changhwan Youn chaos.y...@samsung.com
Signed-off-by: Hyuk Lee hyuk1@samsung.com
Signed-off-by: Kukjin Kim kgene@samsung.com
---
Changes since v3:
- Changes clock source from PWM2 to PWM4 because PWM4 cannot be used
for
other purpose such as external output function through GPIO.
arch/arm/mach-s5pv310/include/mach/pwm-clock.h | 70 ++
arch/arm/mach-s5pv310/localtimer.c | 25 ++
arch/arm/mach-s5pv310/time.c | 287
arch/arm/plat-s5p/include/plat/s5pv310.h | 1 +
arch/arm/plat-samsung/Makefile | 2 +-
5 files changed, 384 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-s5pv310/include/mach/pwm-clock.h
create mode 100644 arch/arm/mach-s5pv310/localtimer.c
create mode 100644 arch/arm/mach-s5pv310/time.c
diff --git a/arch/arm/mach-s5pv310/include/mach/pwm-clock.h
b/arch/arm/mach-s5pv310/include/mach/pwm-clock.h
new file mode 100644
index 000..7e6da27
--- /dev/null
+++ b/arch/arm/mach-s5pv310/include/mach/pwm-clock.h
@@ -0,0 +1,70 @@
+/* linux/arch/arm/mach-s5pv310/include/mach/pwm-clock.h
+ *
+ * Copyright (c) 2010 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * Copyright 2008 Openmoko, Inc.
+ * Copyright 2008 Simtec Electronics
+ * Ben Dooks b...@simtec.co.uk
+ * http://armlinux.simtec.co.uk/
+ *
+ * Based on arch/arm/mach-s3c64xx/include/mach/pwm-clock.h
+ *
+ * S5PV310 - pwm clock and timer support
+ *
+ * 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.
+*/
+
+#ifndef __ASM_ARCH_PWMCLK_H
+#define __ASM_ARCH_PWMCLK_H __FILE__
+
+/**
+ * pwm_cfg_src_is_tclk() - return whether the given mux config is a
tclk
+ * @tcfg: The timer TCFG1 register bits shifted down to 0.
+ *
+ * Return true if the given configuration from TCFG1 is a TCLK instead
+ * any of the TDIV clocks.
+ */
+static inline int pwm_cfg_src_is_tclk(unsigned long tcfg)
+{
+ return tcfg == S3C64XX_TCFG1_MUX_TCLK;
+}
+
+/**
+ * tcfg_to_divisor() - convert tcfg1 setting to a divisor
+ * @tcfg1: The tcfg1 setting, shifted down.
+ *
+ * Get the divisor value for the given tcfg1 setting. We assume the
+ * caller has already checked to see if this is not a TCLK source.
+ */
+static inline unsigned long tcfg_to_divisor(unsigned long tcfg1)
+{
+ return 1 tcfg1;
+}
+
+/**
+ * pwm_tdiv_has_div1() - does the tdiv setting have a /1
+ *
+ * Return true if we have a /1 in the tdiv setting.
+ */
+static inline unsigned int pwm_tdiv_has_div1(void)
+{
+ return 1;
+}
+
+/**
+ * pwm_tdiv_div_bits() - calculate TCFG1 divisor value.
+ * @div: The divisor to calculate the bit information for.
+ *
+ * Turn a divisor into the necessary bit field for TCFG1.
+ */
+static inline unsigned long pwm_tdiv_div_bits(unsigned int div)
+{
+ return ilog2(div);
+}
+
+#define S3C_TCFG1_MUX_TCLK S3C64XX_TCFG1_MUX_TCLK
+
+#endif /* __ASM_ARCH_PWMCLK_H
Re: [PATCH v3 3/3] ARM: SAMSUNG: i2c/busses: Add HAVE_S3C2410_I2C option to include I2C for Samsung SoCs
On Thu, Jul 29, 2010 at 6:42 PM, Kukjin Kim kgene@samsung.com wrote: From: Naveen Krishna Ch ch.nav...@samsung.com This patch adds HAVE_S3C2410_I2C to control inclusion of I2C bus driver on Samsung SoCs and makes I2C bus driver dependency SoC specific instead of machine specific. This will enalbe all machines using Samsung ARCH_S3C2410, _S3C64XX, _S5P6440, _S5PC100, and _S5PV210 to select the I2C driver by default What's the different from use PLAT_SAMSUNG? config I2C_S3C2410 tristate S3C2410 I2C Driver depends on PLAT_SAMSUNG Please don't populate the Kconfigs. Thank you, Kyungmin Park Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com Signed-off-by: Kukjin Kim kgene@samsung.com Cc: Ben Dooks ben-li...@fluff.org --- Changes since v2: - Added HAVE_S3C2410_I2C in drivers Kconfig - Made I2C bus driver dependency SoC specific - Selected additional support I2C bus driver for S5P6440, S5PC100, and S5PV210 Changes since v1: - Modifed the Kconfig help comments. arch/arm/Kconfig | 5 + drivers/i2c/busses/Kconfig | 11 +-- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 98922f7..e922994 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -634,6 +634,7 @@ config ARCH_S3C2410 select ARCH_HAS_CPUFREQ select HAVE_CLK select ARCH_USES_GETTIMEOFFSET + select HAVE_S3C2410_I2C help Samsung S3C2410X CPU based systems, such as the Simtec Electronics BAST (http://www.simtec.co.uk/products/EB110ITX/), the IPAQ 1940 or @@ -663,6 +664,7 @@ config ARCH_S3C64XX select S3C_DEV_NAND select USB_ARCH_HAS_OHCI select SAMSUNG_GPIOLIB_4BIT + select HAVE_S3C2410_I2C help Samsung S3C64XX series based systems @@ -672,6 +674,7 @@ config ARCH_S5P6440 select GENERIC_GPIO select HAVE_CLK select ARCH_USES_GETTIMEOFFSET + select HAVE_S3C2410_I2C help Samsung S5P6440 CPU based systems @@ -691,6 +694,7 @@ config ARCH_S5PC100 select CPU_V7 select ARM_L1_CACHE_SHIFT_6 select ARCH_USES_GETTIMEOFFSET + select HAVE_S3C2410_I2C help Samsung S5PC100 series based systems @@ -701,6 +705,7 @@ config ARCH_S5PV210 select HAVE_CLK select ARM_L1_CACHE_SHIFT_6 select ARCH_USES_GETTIMEOFFSET + select HAVE_S3C2410_I2C help Samsung S5PV210/S5PC110 series based systems diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index bceafbf..f1751da 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -521,12 +521,19 @@ config I2C_PXA_SLAVE is necessary for systems where the PXA may be a target on the I2C bus. +config HAVE_S3C2410_I2C + bool + help + This will include I2C support for Samsung SoCs. If you want to + include I2C support for any machine, kindly select this in the + respective Kconfig file. + config I2C_S3C2410 tristate S3C2410 I2C Driver - depends on ARCH_S3C2410 || ARCH_S3C64XX + depends on HAVE_S3C2410_I2C help Say Y here to include support for I2C controller in the - Samsung S3C2410 based System-on-Chip devices. + Samsung SoCs. config I2C_S6000 tristate S6000 I2C support -- 1.6.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 -- 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 3/3] ARM: SAMSUNG: i2c/busses: Add HAVE_S3C2410_I2C option to include I2C for Samsung SoCs
On Fri, Jul 30, 2010 at 10:03 AM, Kukjin Kim kgene@samsung.com wrote: Kyungmin Park wrote: On Thu, Jul 29, 2010 at 6:42 PM, Kukjin Kim kgene@samsung.com wrote: From: Naveen Krishna Ch ch.nav...@samsung.com This patch adds HAVE_S3C2410_I2C to control inclusion of I2C bus driver on Samsung SoCs and makes I2C bus driver dependency SoC specific instead of machine specific. This will enalbe all machines using Samsung ARCH_S3C2410, _S3C64XX, _S5P6440, _S5PC100, and _S5PV210 to select the I2C driver by default What's the different from use PLAT_SAMSUNG? Hi, Hmm..the difference? I remember, already said to you... Anyway actually, there was a stuff in here about that. Please refer to following...it may answer on your question. --- From Ben Dooks config RTC_DRV_S3C tristate Samsung S3C series SoC RTC - depends on ARCH_S3C2410 + depends on ARCH_S3C2410 || ARCH_S3C64XX I wonder whether just making this depend on either S3C_DEV_RTC, or simply PLAT_SAMSUNG would just be a better choice. The S3C_DEV_RTC would mean that the drivers the core of the kernel would be built, but means that we can't speculatively build drivers if the kernel hasn't any machines using them. Making it depend on PLAT_SAMSUNG would mean it is available to all, but would be selectable even if there isn't a machine supporting it being built. The current situation would mean that we have to update driver Kconfig entries each time a new SoC turns up... In other word, It can make it workable when new SoCs arrives, even though depends on PLAT_SAMSUNG. If new chip has improved i2C IP then define new I2C drivers and modify it as 'depends on PLAT_SAMUSNG if !NEW_IP_I2C' and use another i2c drivers. of course it's depends on PLAT_SAMSUNG or PLAT_S5P if NEW_IP_I2C. We could also have a HAVE_RTC_DRV_S3C so that all SoCs supporting this coudl select it independant of whether there is machine support. --- It doesn't mean that we should use HAVE_XXX in this case... But this way is better _now_ and they used same method in several drivers. And if driver IP changes, we can use with HAVE_XXXV2... config I2C_S3C2410 tristate S3C2410 I2C Driver depends on PLAT_SAMSUNG Please don't populate the Kconfigs. I hope you stop talking same issue without alternative... Thank you, Kyungmin Park Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com Signed-off-by: Kukjin Kim kgene@samsung.com Cc: Ben Dooks ben-li...@fluff.org --- Changes since v2: - Added HAVE_S3C2410_I2C in drivers Kconfig - Made I2C bus driver dependency SoC specific - Selected additional support I2C bus driver for S5P6440, S5PC100, and S5PV210 Changes since v1: - Modifed the Kconfig help comments. arch/arm/Kconfig | 5 + drivers/i2c/busses/Kconfig | 11 +-- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 98922f7..e922994 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -634,6 +634,7 @@ config ARCH_S3C2410 select ARCH_HAS_CPUFREQ select HAVE_CLK select ARCH_USES_GETTIMEOFFSET + select HAVE_S3C2410_I2C help Samsung S3C2410X CPU based systems, such as the Simtec Electronics BAST (http://www.simtec.co.uk/products/EB110ITX/), the IPAQ 1940 or @@ -663,6 +664,7 @@ config ARCH_S3C64XX select S3C_DEV_NAND select USB_ARCH_HAS_OHCI select SAMSUNG_GPIOLIB_4BIT + select HAVE_S3C2410_I2C help Samsung S3C64XX series based systems @@ -672,6 +674,7 @@ config ARCH_S5P6440 select GENERIC_GPIO select HAVE_CLK select ARCH_USES_GETTIMEOFFSET + select HAVE_S3C2410_I2C help Samsung S5P6440 CPU based systems @@ -691,6 +694,7 @@ config ARCH_S5PC100 select CPU_V7 select ARM_L1_CACHE_SHIFT_6 select ARCH_USES_GETTIMEOFFSET + select HAVE_S3C2410_I2C help Samsung S5PC100 series based systems @@ -701,6 +705,7 @@ config ARCH_S5PV210 select HAVE_CLK select ARM_L1_CACHE_SHIFT_6 select ARCH_USES_GETTIMEOFFSET + select HAVE_S3C2410_I2C help Samsung S5PV210/S5PC110 series based systems diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index bceafbf..f1751da 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -521,12 +521,19 @@ config I2C_PXA_SLAVE is necessary for systems where the PXA may be a target on the I2C bus. +config HAVE_S3C2410_I2C + bool + help + This will include I2C support for Samsung SoCs. If you want to + include I2C support for any machine, kindly select this in the + respective Kconfig file. + config I2C_S3C2410 tristate S3C2410 I2C Driver
Re: [PATCH v4 3/8] ARM: Samsung: Add platform definitions and helpers for FIMC driver
On Tue, Aug 3, 2010 at 8:58 AM, Kukjin Kim kgene@samsung.com wrote: Marek Szyprowski wrote: From: Sylwester Nawrocki s.nawro...@samsung.com FIMC (CAMIF) device is a camera interface embedded in S3C/S5P Samsung SOC series. It supports ITU-R BT.601/656 and MIPI-CSI2 standards, memory to memory operations, color conversion, resizing and rotation. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com --- This is patch is a v3 version rebased onto latest kgene/for-next tree. New entries in map.h files has been sorted by the physicall address. Thanks for your addressing. I'm resending this patch on behalf of Sylwester who is on holidays this week. Best regards -- Marek Szyprowski Samsung Poland RD Center --- arch/arm/mach-s5pc100/include/mach/map.h | 7 arch/arm/mach-s5pv210/cpu.c | 5 +++ arch/arm/mach-s5pv210/include/mach/map.h | 8 arch/arm/plat-s5p/Kconfig | 16 arch/arm/plat-s5p/Makefile | 3 ++ arch/arm/plat-s5p/dev-fimc0.c | 35 ++ arch/arm/plat-s5p/dev-fimc1.c | 35 ++ arch/arm/plat-s5p/dev-fimc2.c | 35 ++ arch/arm/plat-samsung/include/plat/fimc-core.h | 45 arch/arm/plat-samsung/include/plat/fimc.h | 22 +++ 10 files changed, 211 insertions(+), 0 deletions(-) create mode 100644 arch/arm/plat-s5p/dev-fimc0.c create mode 100644 arch/arm/plat-s5p/dev-fimc1.c create mode 100644 arch/arm/plat-s5p/dev-fimc2.c create mode 100644 arch/arm/plat-samsung/include/plat/fimc-core.h create mode 100644 arch/arm/plat-samsung/include/plat/fimc.h diff --git a/arch/arm/mach-s5pc100/include/mach/map.h b/arch/arm/mach- s5pc100/include/mach/map.h index c018697..3abe7f5 100644 --- a/arch/arm/mach-s5pc100/include/mach/map.h +++ b/arch/arm/mach-s5pc100/include/mach/map.h @@ -99,6 +99,10 @@ #define S5PC100_PA_FB (0xEE00) +#define S5PC100_PA_FIMC0 (0xEE20) +#define S5PC100_PA_FIMC1 (0xEE30) +#define S5PC100_PA_FIMC2 (0xEE40) + #define S5PC100_PA_I2S0 (0xF200) #define S5PC100_PA_I2S1 (0xF210) #define S5PC100_PA_I2S2 (0xF220) @@ -143,6 +147,9 @@ #define S3C_PA_ONENAND_BUF S5PC100_PA_ONENAND_BUF #define S3C_SZ_ONENAND_BUF S5PC100_SZ_ONENAND_BUF #define S3C_PA_RTC S5PC100_PA_RTC +#define S5P_PA_FIMC0 S5PC100_PA_FIMC0 +#define S5P_PA_FIMC1 S5PC100_PA_FIMC1 +#define S5P_PA_FIMC2 S5PC100_PA_FIMC2 #define SAMSUNG_PA_ADC S5PC100_PA_TSADC #define SAMSUNG_PA_CFCON S5PC100_PA_CFCON diff --git a/arch/arm/mach-s5pv210/cpu.c b/arch/arm/mach-s5pv210/cpu.c index ea09c32..a7446d4 100644 --- a/arch/arm/mach-s5pv210/cpu.c +++ b/arch/arm/mach-s5pv210/cpu.c @@ -37,6 +37,7 @@ #include plat/iic-core.h #include plat/keypad-core.h #include plat/sdhci.h +#include plat/fimc-core.h #include plat/reset.h /* Initial IO mappings */ @@ -104,6 +105,10 @@ void __init s5pv210_map_io(void) /* Use s5pv210-keypad instead of samsung-keypad */ samsung_keypad_setname(s5pv210-keypad); + + s3c_fimc_setname(0, s5pv210-fimc); + s3c_fimc_setname(1, s5pv210-fimc); + s3c_fimc_setname(2, s5pv210-fimc); } void __init s5pv210_init_clocks(int xtal) diff --git a/arch/arm/mach-s5pv210/include/mach/map.h b/arch/arm/mach- s5pv210/include/mach/map.h index 986b285..6a07e55 100644 --- a/arch/arm/mach-s5pv210/include/mach/map.h +++ b/arch/arm/mach-s5pv210/include/mach/map.h @@ -65,6 +65,10 @@ #define S5PV210_PA_FB (0xF800) +#define S5PV210_PA_FIMC0 (0xFB20) +#define S5PV210_PA_FIMC1 (0xFB30) +#define S5PV210_PA_FIMC2 (0xFB40) + #define S5PV210_PA_HSMMC(x) (0xEB00 + ((x) * 0x10)) #define S5PV210_PA_VIC0 (0xF200) @@ -114,4 +118,8 @@ #define SAMSUNG_PA_CFCON S5PV210_PA_CFCON #define SAMSUNG_PA_KEYPAD S5PV210_PA_KEYPAD +#define S5P_PA_FIMC0 S5PV210_PA_FIMC0 +#define S5P_PA_FIMC1 S5PV210_PA_FIMC1 +#define S5P_PA_FIMC2 S5PV210_PA_FIMC2 To use one style is better for reading, merge conflict handling and so on... The style means to add S5P_PA_XXX after S3C_PA_XXX with C100 case or to modify above C100 case like this. Use the same conversion as previous one. are you okay? #define S5PV210_PA_VIC0 (0xF200) #define S5P_PA_VIC0 S5PV210_PA_VIC0 #define S5PV210_PA_VIC1 (0xF210) #define S5P_PA_VIC1 S5PV210_PA_VIC1 #define S5PV210_PA_VIC2 (0xF220) #define S5P_PA_VIC2 S5PV210_PA_VIC2 #define S5PV210_PA_VIC3 (0xF230) #define S5P_PA_VIC3
Re: Please remind 'WARNING: about Samsung merge window over'
On Tue, Aug 3, 2010 at 9:53 AM, Kukjin Kim kgene@samsung.com wrote: Russell King wrote: On Mon, Aug 02, 2010 at 05:35:37PM +0900, Kyungmin Park wrote: As the maintainer, he merged his features freely but others can't get the chance if the implementation is not fit his taste or company policy. Look at the example. [PATCH v2 0/4] ARM: S5P: Support gpio interrupts http://marc.info/?l=linux-arm-kernelm=127840208508625w=2 We need the gpio interrupt support but he refused it since it used too many irq. Actually his board don't use this features. It is because there are too many gpio interrupts and having support of all of them is unnecessary as realistically only few of them maybe used. From my count, there's already 144 IRQs, and you'll be adding 27*8 = 216 additional IRQs to that. That's quite small compared to some platforms which have in the order of 512 or even 1024 IRQs. Can you comment this one? and previous s5pc110 cpufreq also? And current kernel don't support the sparse irq feature. then it's reasonable to merge it first and revise it later. sparse irq support has been queued for almost a month for the merge window which has just this morning opened. This doesn't help you if you instantiate all your 360 interrupts though - just because you don't _use_ an interrupt which has been declared as existing doesn't reduce the size of the arrays. Another why FIMC support is missing? we modified it as his requested and send it properly. [PATCH v3 3/8] ARM: Samsung: Add platform definitions and helpers for http://marc.info/?l=linux-arm-kernelm=127990218813931w=2 This looks like it's been missed. People get busy and miss things on the mailing list, there's nothing special about that. Yeah...actually I missed reply for it...so I requested re-submit v4 patch to Marek with some modifying and finished review it just now. [PATCH v3 1/8] ARM: Samsung: Add register definitions for Samsung S5P http://marc.info/?l=linux-arm-kernelm=127990218613922w=2 Kukjin Kim replied to this one with a point requiring an answer, but nothing came back. Looks ok...however, I'm still thinking whether really need all these definitions. Seems to be a perfectly reasonable point to raise, and if there's no reply to justify them... Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, 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/8] ARM: Samsung: Add platform definitions and helpers for FIMC driver
On Tue, Aug 3, 2010 at 10:05 AM, Kukjin Kim kgene@samsung.com wrote: Kyungmin Park wrote: On Tue, Aug 3, 2010 at 9:46 AM, Kukjin Kim kgene@samsung.com wrote: Kyungmin Park wrote: On Tue, Aug 3, 2010 at 8:58 AM, Kukjin Kim kgene@samsung.com wrote: Marek Szyprowski wrote: From: Sylwester Nawrocki s.nawro...@samsung.com FIMC (CAMIF) device is a camera interface embedded in S3C/S5P Samsung SOC series. It supports ITU-R BT.601/656 and MIPI-CSI2 standards, memory to memory operations, color conversion, resizing and rotation. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com --- This is patch is a v3 version rebased onto latest kgene/for-next tree. New entries in map.h files has been sorted by the physicall address. Thanks for your addressing. I'm resending this patch on behalf of Sylwester who is on holidays this week. Best regards -- Marek Szyprowski Samsung Poland RD Center --- (snip) diff --git a/arch/arm/mach-s5pc100/include/mach/map.h b/arch/arm/mach- s5pc100/include/mach/map.h index c018697..3abe7f5 100644 --- a/arch/arm/mach-s5pc100/include/mach/map.h +++ b/arch/arm/mach-s5pc100/include/mach/map.h @@ -99,6 +99,10 @@ #define S5PC100_PA_FB (0xEE00) +#define S5PC100_PA_FIMC0 (0xEE20) +#define S5PC100_PA_FIMC1 (0xEE30) +#define S5PC100_PA_FIMC2 (0xEE40) + #define S5PC100_PA_I2S0 (0xF200) #define S5PC100_PA_I2S1 (0xF210) #define S5PC100_PA_I2S2 (0xF220) @@ -143,6 +147,9 @@ #define S3C_PA_ONENAND_BUF S5PC100_PA_ONENAND_BUF #define S3C_SZ_ONENAND_BUF S5PC100_SZ_ONENAND_BUF #define S3C_PA_RTC S5PC100_PA_RTC +#define S5P_PA_FIMC0 S5PC100_PA_FIMC0 +#define S5P_PA_FIMC1 S5PC100_PA_FIMC1 +#define S5P_PA_FIMC2 S5PC100_PA_FIMC2 #define SAMSUNG_PA_ADC S5PC100_PA_TSADC #define SAMSUNG_PA_CFCON S5PC100_PA_CFCON diff --git a/arch/arm/mach-s5pv210/cpu.c b/arch/arm/mach-s5pv210/cpu.c (snip) diff --git a/arch/arm/mach-s5pv210/include/mach/map.h b/arch/arm/mach- s5pv210/include/mach/map.h index 986b285..6a07e55 100644 --- a/arch/arm/mach-s5pv210/include/mach/map.h +++ b/arch/arm/mach-s5pv210/include/mach/map.h @@ -65,6 +65,10 @@ #define S5PV210_PA_FB (0xF800) +#define S5PV210_PA_FIMC0 (0xFB20) +#define S5PV210_PA_FIMC1 (0xFB30) +#define S5PV210_PA_FIMC2 (0xFB40) + #define S5PV210_PA_HSMMC(x) (0xEB00 + ((x) * 0x10)) #define S5PV210_PA_VIC0 (0xF200) @@ -114,4 +118,8 @@ #define SAMSUNG_PA_CFCON S5PV210_PA_CFCON #define SAMSUNG_PA_KEYPAD S5PV210_PA_KEYPAD +#define S5P_PA_FIMC0 S5PV210_PA_FIMC0 +#define S5P_PA_FIMC1 S5PV210_PA_FIMC1 +#define S5P_PA_FIMC2 S5PV210_PA_FIMC2 To use one style is better for reading, merge conflict handling and so on... The style means to add S5P_PA_XXX after S3C_PA_XXX with C100 case or to modify above C100 case like this. Use the same conversion as previous one. are you okay? #define S5PV210_PA_VIC0 (0xF200) #define S5P_PA_VIC0 S5PV210_PA_VIC0 #define S5PV210_PA_VIC1 (0xF210) #define S5P_PA_VIC1 S5PV210_PA_VIC1 #define S5PV210_PA_VIC2 (0xF220) #define S5P_PA_VIC2 S5PV210_PA_VIC2 #define S5PV210_PA_VIC3 (0xF230) #define S5P_PA_VIC3 S5PV210_PA_VIC3 #define S5PV210_PA_SDRAM (0x3000) #define S5P_PA_SDRAM S5PV210_PA_SDRAM No. Did you see above C100? --- C100 #define S3C_PA_ONENAND_BUF S5PC100_PA_ONENAND_BUF #define S3C_SZ_ONENAND_BUF S5PC100_SZ_ONENAND_BUF #define S3C_PA_RTC S5PC100_PA_RTC +#define S5P_PA_FIMC0 S5PC100_PA_FIMC0 +#define S5P_PA_FIMC1 S5PC100_PA_FIMC1 +#define S5P_PA_FIMC2 S5PC100_PA_FIMC2 #define SAMSUNG_PA_ADC S5PC100_PA_TSADC #define SAMSUNG_PA_CFCON S5PC100_PA_CFCON --- V210 #define SAMSUNG_PA_CFCON S5PV210_PA_CFCON #define SAMSUNG_PA_KEYPAD S5PV210_PA_KEYPAD +#define S5P_PA_FIMC0 S5PV210_PA_FIMC0 +#define S5P_PA_FIMC1 S5PV210_PA_FIMC1 +#define S5P_PA_FIMC2 S5PV210_PA_FIMC2 I mean it's just ordering. Yes I also mean it don't separate the related definitions. so place adjacent as the the previous. No...maybe you misunderstood...hmm :-( Please add in map.h of V210 like following. Then please also apply the same rules at existing definitions. @@ -110,6 +110,10 @@ #define
Re: [PATCH v3 1/8] ARM: Samsung: Add register definitions for Samsung S5P SoC camera interface
On Tue, Aug 3, 2010 at 9:46 AM, Kukjin Kim kgene@samsung.com wrote: Russell King wrote: On Mon, Aug 02, 2010 at 02:08:42PM +0200, Pawel Osciak wrote: Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, Aug 02, 2010 at 12:32:20PM +0200, Pawel Osciak wrote: Well, some of them are indeed unused, but it's not an uncommon practice in kernel and might help future developers. On the other hand, arch/arm is getting soo big that we need to do something about this - and one solution is to avoid unnecessary definitions that we're not using. Another good idea is to put definitions along side the drivers which they're relevant to - maybe in a local driver-name.h file which driver-name.c includes, or maybe even within driver-name.c if they're not excessive. This has the advantage of distributing the bloat to where its actually used, and means that the driver isn't dependent so much on arch/arm or even the SoC itself. Take a look at arch/arm/mach-vexpress/include/mach/ct-ca9x4.h and arch/arm/mach-vexpress/include/mach/motherboard.h - these are the only two files which contain platform definitions which are actually used for Versatile Express. Compare that with arch/arm/mach-realview/include/mach/platform.h which contains lots more... So basically, what you and Mauro are recommending is that we move the *.h file with register definitions to drivers/media? What I'm suggesting is what's been pretty standard in Linux for a long time. Take a look at: drivers/net/3c503.[ch], or for a more recent driver, drivers/net/e1000/*.[ch]. Or drivers/mmc/host/mmci.[ch] I agree with Russell's opinion. I don't want to add unnecessary(or unavailable in arch/arm) definitions in arch/arm/*/include Putting definitions which are only used by one driver in arch/arm/*/include is silly. I also happy with this method. Thank you, Kyungmin 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
Re: [PATCH v6 5/7] ARM: S5PV210: Access for DMCx registers
On Wed, Aug 4, 2010 at 8:17 PM, Kukjin Kim kgene@samsung.com wrote:
MyungJoo Ham wrote:
The CPUFREQ driver requires an access to DMCx registers. We
define physical addresses and mapping between physical and virtual
addresses of DMCx registers.
Signed-off-by: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-s5pv210/cpu.c | 12 +++-
arch/arm/mach-s5pv210/include/mach/map.h | 4
2 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-s5pv210/cpu.c b/arch/arm/mach-s5pv210/cpu.c
index 74d4c08..2066695 100644
--- a/arch/arm/mach-s5pv210/cpu.c
+++ b/arch/arm/mach-s5pv210/cpu.c
@@ -60,7 +60,17 @@ static struct map_desc s5pv210_iodesc[] __initdata = {
.pfn = __phys_to_pfn(S5PV210_PA_SROMC),
.length = SZ_4K,
.type = MT_DEVICE,
- }
+ }, {
+ .virtual = (unsigned long)S5P_VA_DMC0,
+ .pfn = __phys_to_pfn(S5PV210_PA_DMC0),
+ .length = SZ_4K,
+ .type = MT_DEVICE,
+ }, {
+ .virtual = (unsigned long)S5P_VA_DMC1,
+ .pfn = __phys_to_pfn(S5PV210_PA_DMC1),
+ .length = SZ_4K,
+ .type = MT_DEVICE,
+ },
};
static void s5pv210_idle(void)
diff --git a/arch/arm/mach-s5pv210/include/mach/map.h b/arch/arm/mach-
s5pv210/include/mach/map.h
index 17687f0..daf6456 100644
--- a/arch/arm/mach-s5pv210/include/mach/map.h
+++ b/arch/arm/mach-s5pv210/include/mach/map.h
@@ -108,4 +108,8 @@
#define SAMSUNG_PA_ADC S5PV210_PA_ADC
#define SAMSUNG_PA_KEYPAD S5PV210_PA_KEYPAD
+/* DMC */
No need an obvious comment like above...
+#define S5PV210_PA_DMC0 (0xF000)
+#define S5PV210_PA_DMC1 (0xF140)
As I said, if you need adding new definition into the mach/map.h, please
keep the address order like others.
It can help to us for easily reading...
Good, good, good,
I'm really appreciate it if the same rules apply to LSI internal trees.
I hope you check it LSI codes also.
Thank you,
Kyungmin Park
+
#endif /* __ASM_ARCH_MAP_H */
--
And as I commented, to merge your 4th(previous, just adding VA) and 5th
patch to one is better...just for adding DMC map IO.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, 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
--
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: Fix on inclusion mach/gpio.h for Samsung SoCs
Acked-by: Kyungmin Park kyungmin.p...@samsung.com On Thu, Aug 5, 2010 at 8:07 AM, Kukjin Kim kgene@samsung.com wrote: This patch fixes on inclusion mach/gpio.h to linux/gpio.h. Signed-off-by: Kukjin Kim kgene@samsung.com Cc: Ben Dooks ben-li...@fluff.org --- arch/arm/mach-s3c64xx/dev-audio.c | 2 +- arch/arm/mach-s3c64xx/dev-spi.c | 2 +- arch/arm/mach-s3c64xx/gpiolib.c | 2 +- arch/arm/mach-s3c64xx/setup-fb-24bpp.c | 2 +- arch/arm/mach-s3c64xx/setup-i2c0.c | 2 +- arch/arm/mach-s3c64xx/setup-i2c1.c | 2 +- arch/arm/mach-s3c64xx/setup-sdhci-gpio.c | 2 +- arch/arm/mach-s5p6440/dev-audio.c | 2 +- arch/arm/mach-s5p6440/dev-spi.c | 2 +- arch/arm/mach-s5p6440/gpio.c | 4 +++- arch/arm/mach-s5p6442/dev-audio.c | 2 +- arch/arm/mach-s5p6442/dev-spi.c | 2 +- arch/arm/mach-s5pc100/dev-audio.c | 2 +- arch/arm/mach-s5pc100/dev-spi.c | 2 +- arch/arm/mach-s5pv210/dev-audio.c | 2 +- arch/arm/mach-s5pv210/dev-spi.c | 2 +- arch/arm/mach-s5pv210/setup-fb-24bpp.c | 2 +- arch/arm/mach-s5pv210/setup-i2c0.c | 2 +- arch/arm/mach-s5pv210/setup-i2c1.c | 2 +- arch/arm/mach-s5pv210/setup-i2c2.c | 2 +- arch/arm/mach-s5pv210/setup-sdhci-gpio.c | 2 +- 21 files changed, 23 insertions(+), 21 deletions(-) diff --git a/arch/arm/mach-s3c64xx/dev-audio.c b/arch/arm/mach-s3c64xx/dev-audio.c index c3e9e73..9648fbc 100644 --- a/arch/arm/mach-s3c64xx/dev-audio.c +++ b/arch/arm/mach-s3c64xx/dev-audio.c @@ -12,11 +12,11 @@ #include linux/string.h #include linux/platform_device.h #include linux/dma-mapping.h +#include linux/gpio.h #include mach/irqs.h #include mach/map.h #include mach/dma.h -#include mach/gpio.h #include plat/devs.h #include plat/audio.h diff --git a/arch/arm/mach-s3c64xx/dev-spi.c b/arch/arm/mach-s3c64xx/dev-spi.c index 29c32d0..a492b98 100644 --- a/arch/arm/mach-s3c64xx/dev-spi.c +++ b/arch/arm/mach-s3c64xx/dev-spi.c @@ -12,10 +12,10 @@ #include linux/string.h #include linux/platform_device.h #include linux/dma-mapping.h +#include linux/gpio.h #include mach/dma.h #include mach/map.h -#include mach/gpio.h #include mach/gpio-bank-c.h #include mach/spi-clocks.h diff --git a/arch/arm/mach-s3c64xx/gpiolib.c b/arch/arm/mach-s3c64xx/gpiolib.c index 60c929a..300dee4 100644 --- a/arch/arm/mach-s3c64xx/gpiolib.c +++ b/arch/arm/mach-s3c64xx/gpiolib.c @@ -15,9 +15,9 @@ #include linux/kernel.h #include linux/irq.h #include linux/io.h +#include linux/gpio.h #include mach/map.h -#include mach/gpio.h #include plat/gpio-core.h #include plat/gpio-cfg.h diff --git a/arch/arm/mach-s3c64xx/setup-fb-24bpp.c b/arch/arm/mach-s3c64xx/setup-fb-24bpp.c index 8e28e44..0007368 100644 --- a/arch/arm/mach-s3c64xx/setup-fb-24bpp.c +++ b/arch/arm/mach-s3c64xx/setup-fb-24bpp.c @@ -15,9 +15,9 @@ #include linux/kernel.h #include linux/types.h #include linux/fb.h +#include linux/gpio.h #include mach/regs-fb.h -#include mach/gpio.h #include plat/fb.h #include plat/gpio-cfg.h diff --git a/arch/arm/mach-s3c64xx/setup-i2c0.c b/arch/arm/mach-s3c64xx/setup-i2c0.c index d1b11e6..406192a 100644 --- a/arch/arm/mach-s3c64xx/setup-i2c0.c +++ b/arch/arm/mach-s3c64xx/setup-i2c0.c @@ -14,10 +14,10 @@ #include linux/kernel.h #include linux/types.h +#include linux/gpio.h struct platform_device; /* don't need the contents */ -#include mach/gpio.h #include mach/gpio-bank-b.h #include plat/iic.h #include plat/gpio-cfg.h diff --git a/arch/arm/mach-s3c64xx/setup-i2c1.c b/arch/arm/mach-s3c64xx/setup-i2c1.c index 2dce57d..1ee62c9 100644 --- a/arch/arm/mach-s3c64xx/setup-i2c1.c +++ b/arch/arm/mach-s3c64xx/setup-i2c1.c @@ -14,10 +14,10 @@ #include linux/kernel.h #include linux/types.h +#include linux/gpio.h struct platform_device; /* don't need the contents */ -#include mach/gpio.h #include mach/gpio-bank-b.h #include plat/iic.h #include plat/gpio-cfg.h diff --git a/arch/arm/mach-s3c64xx/setup-sdhci-gpio.c b/arch/arm/mach-s3c64xx/setup-sdhci-gpio.c index a58c0cc..dcf37e2 100644 --- a/arch/arm/mach-s3c64xx/setup-sdhci-gpio.c +++ b/arch/arm/mach-s3c64xx/setup-sdhci-gpio.c @@ -16,8 +16,8 @@ #include linux/interrupt.h #include linux/platform_device.h #include linux/io.h +#include linux/gpio.h -#include mach/gpio.h #include plat/gpio-cfg.h #include plat/sdhci.h diff --git a/arch/arm/mach-s5p6440/dev-audio.c b/arch/arm/mach-s5p6440/dev-audio.c index 0c53679..3ca0d2b 100644 --- a/arch/arm/mach-s5p6440/dev-audio.c +++ b/arch/arm/mach-s5p6440/dev-audio.c @@ -10,11 +10,11 @@ #include linux/platform_device.h #include linux/dma-mapping.h +#include linux/gpio.h #include plat/gpio-cfg.h #include plat/audio.h -#include mach/gpio.h #include mach/map.h #include mach/dma.h
Re: [PATCH v4] ARM: S5PV310: Add Samsung UNIVERSAL_C210 support
On Fri, Aug 6, 2010 at 9:14 PM, Kukjin Kim kgene@samsung.com wrote:
From: Kyungmin Park kyungmin.p...@samsung.com
This patch adds Samsung Mobile S5PC210 Reference Board, UNIVERSAL_C210 board
support.
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
[kgene@samsung.com: changed machine name]
Signed-off-by: Kukjin Kim kgene@samsung.com
---
Kyungmin,
Maybe as you know, should be changed all universal_ functions when adding
other universal board for avoiding confusing later. And need this so that
we can support single kernel image in future. Thanks.
Keep in mind. but as you see other universal patches. it's almost
static variables do don't make a problem when other universal board
comes.
Yes. some time later it needs to change the name, but current samsung
socs has each SoCs directory so it also don't make a problem.
Thank you,
Kyungmin Park
NOTE:
Changes since v3:
- Changed only machine name not functions based on v1 patch
Changes since v2:
- Changed machine name from 'UNIVERSAL' to 'UNIVERSAL_C210'
Changes since v1:
- Changed default UFCON tx/rx trigger level
arch/arm/mach-s5pv310/Kconfig | 9 +++
arch/arm/mach-s5pv310/Makefile | 1 +
arch/arm/mach-s5pv310/mach-universal_c210.c | 86
+++
3 files changed, 96 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-s5pv310/mach-universal_c210.c
diff --git a/arch/arm/mach-s5pv310/Kconfig b/arch/arm/mach-s5pv310/Kconfig
index f9b1892..331b5bd 100644
--- a/arch/arm/mach-s5pv310/Kconfig
+++ b/arch/arm/mach-s5pv310/Kconfig
@@ -33,4 +33,13 @@ config MACH_SMDKV310
select ARCH_SPARSEMEM_ENABLE
help
Machine support for Samsung SMDKV310
+
+config MACH_UNIVERSAL_C210
+ bool Mobile UNIVERSAL_C210 Board
+ select CPU_S5PV310
+ select ARCH_SPARSEMEM_ENABLE
+ help
+ Machine support for Samsung Mobile Universal S5PC210 Reference
+ Board. S5PC210(MCP) is one of package option of S5PV310
+
endif
diff --git a/arch/arm/mach-s5pv310/Makefile b/arch/arm/mach-s5pv310/Makefile
index 967e2c8..d5b51c7 100644
--- a/arch/arm/mach-s5pv310/Makefile
+++ b/arch/arm/mach-s5pv310/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
# machine support
obj-$(CONFIG_MACH_SMDKV310) += mach-smdkv310.o
+obj-$(CONFIG_MACH_UNIVERSAL_C210) += mach-universal_c210.o
# device support
diff --git a/arch/arm/mach-s5pv310/mach-universal_c210.c
b/arch/arm/mach-s5pv310/mach-universal_c210.c
new file mode 100644
index 000..2388cb9
--- /dev/null
+++ b/arch/arm/mach-s5pv310/mach-universal_c210.c
@@ -0,0 +1,86 @@
+/* linux/arch/arm/mach-s5pv310/mach-universal_c210.c
+ *
+ * Copyright (c) 2010 Samsung Electronics Co., Ltd.
+ *
+ * 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/serial_core.h
+
+#include asm/mach/arch.h
+#include asm/mach-types.h
+#include asm/hardware/cache-l2x0.h
+
+#include plat/regs-serial.h
+#include plat/s5pv310.h
+#include plat/cpu.h
+
+#include mach/map.h
+
+/* Following are default values for UCON, ULCON and UFCON UART registers */
+#define UNIVERSAL_UCON_DEFAULT (S3C2410_UCON_TXILEVEL | \
+ S3C2410_UCON_RXILEVEL | \
+ S3C2410_UCON_TXIRQMODE | \
+ S3C2410_UCON_RXIRQMODE | \
+ S3C2410_UCON_RXFIFO_TOI | \
+ S3C2443_UCON_RXERR_IRQEN)
+
+#define UNIVERSAL_ULCON_DEFAULT S3C2410_LCON_CS8
+
+#define UNIVERSAL_UFCON_DEFAULT (S3C2410_UFCON_FIFOMODE | \
+ S5PV210_UFCON_TXTRIG256 | \
+ S5PV210_UFCON_RXTRIG256)
+
+static struct s3c2410_uartcfg universal_uartcfgs[] __initdata = {
+ [0] = {
+ .hwport = 0,
+ .ucon = UNIVERSAL_UCON_DEFAULT,
+ .ulcon = UNIVERSAL_ULCON_DEFAULT,
+ .ufcon = UNIVERSAL_UFCON_DEFAULT,
+ },
+ [1] = {
+ .hwport = 1,
+ .ucon = UNIVERSAL_UCON_DEFAULT,
+ .ulcon = UNIVERSAL_ULCON_DEFAULT,
+ .ufcon = UNIVERSAL_UFCON_DEFAULT,
+ },
+ [2] = {
+ .hwport = 2,
+ .ucon = UNIVERSAL_UCON_DEFAULT,
+ .ulcon = UNIVERSAL_ULCON_DEFAULT,
+ .ufcon = UNIVERSAL_UFCON_DEFAULT,
+ },
+ [3] = {
+ .hwport = 3,
+ .ucon = UNIVERSAL_UCON_DEFAULT,
+ .ulcon = UNIVERSAL_ULCON_DEFAULT,
+ .ufcon
Re: 'error: 'SDHCI_QUIRK_NO_HISPD_BIT' undeclared' and 'undefined reference to `sdhci_card_detect''
On Thu, Aug 19, 2010 at 3:33 AM, Andrew Morton a...@linux-foundation.org wrote: On Fri, 13 Aug 2010 10:13:04 +0200 Marek Szyprowski m.szyprow...@samsung.com wrote: Hello, On Friday, August 13, 2010 9:32 AM Kukjin Kim wrote: This is just information about Samsung sdmmc stuff building error now. I found Marek's 'sdhci-s3c: enable SDHCI_QUIRK_NO_HISPD_BIT quirk' in the Linus' tree. (commit ID: a1d5646005af1247d6ae78434bb4db15b07a07b2) But not defined the quirk yet...so following build error happened with s3c6400_defconfig in Linus' latest. drivers/mmc/host/sdhci-s3c.c: In function 'sdhci_s3c_probe': drivers/mmc/host/sdhci-s3c.c:400: error: 'SDHCI_QUIRK_NO_HISPD_BIT' undeclared (first use in this function) drivers/mmc/host/sdhci-s3c.c:400: error: (Each undeclared identifier is reported only once drivers/mmc/host/sdhci-s3c.c:400: error: for each function it appears in.) make[4]: *** [drivers/mmc/host/sdhci-s3c.o] Error 1 make[3]: *** [drivers/mmc/host] Error 2 make[2]: *** [drivers/mmc] Error 2 make[1]: *** [drivers] Error 2 Kyungmin Park's below patch can solve this and it is in mmotm now. (commit ID: 2935b9e7fcc4bea3751b8d039b383b2036a7d36d) But I think, to update quirk definition should being in Marek's patch for avoiding build error. Of course, I'm not sure whether the commit order changed. Anyway, in this case, will be solved after merging mm tree. And second case is same. Marek's 'sdhci-s3c: add support for new card detection methods' cause following build error. (commit ID:17866e14f3a4f219e94f1374ece7226479418ff8) drivers/built-in.o: In function `sdhci_s3c_notify_change': /home/kgene/linux/linux-2.6-mainline-dev/drivers/mmc/host/sdhci-s3c.c:255: undefined reference to `sdhci_card_detect' make[1]: *** [.tmp_vmlinux1] Error 1 make: *** [sub-make] Error 2 And Andrew's patch(b567e5dd5a34c184e5642100e752cb87e064bb97) can solve this. (of course this needs another patches...) Anyway... Marek, in future please make sure your patch has no building problem before submitting. (or it can help to add some kind of dependency note in your patch) My patches submited to Andrew Morton had the description and a note that they have been prepared especially for his tree, taking into account all patches that are already there (mainly a tasklets to threaded irq conversion). For me it was quite obvious that they will be merged after all other sdhci changes from that tree. I have no idea why the order of the patches has been reversed and my sdhci patches has been submitted to Linus before the other sdhci changes. We're talking about these: s5pc110-sdhci-s3c-can-override-host-capabilities.patch s5pc110-sdhci-s3c-support-on-s5pc110.patch sdhci-add-no-hi-speed-bit-quirk-support.patch I have a note that these await an ack from Ben Dooks so I held them back for a closer look after -rc1. I was unaware of this dependency. Ben, are you OK with those patches? These are required for support s5pc110 s5pc210. Current sdhci on s5p has some wrong assumption. only support 4-bit bandwidth. and don't consider the embedded mmc like eMMC. http://userweb.kernel.org/~akpm/mmotm/broken-out/s5pc110-sdhci-s3c-can-override-host-capabilities.patch It required for override the host caps and pass to the mmc with correct caps http://userweb.kernel.org/~akpm/mmotm/broken-out/s5pc110-sdhci-s3c-support-on-s5pc110.patch required for support s5pc110 and also s5pc210 http://userweb.kernel.org/~akpm/mmotm/broken-out/sdhci-add-no-hi-speed-bit-quirk-support.patch As SDHCI on s5p don't has HISPD bit in controller register. need to quirks. Thanks. -- 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: 'error: 'SDHCI_QUIRK_NO_HISPD_BIT' undeclared' and 'undefined reference to `sdhci_card_detect''
On Thu, Aug 19, 2010 at 10:10 AM, Kyungmin Park kmp...@infradead.org wrote: On Thu, Aug 19, 2010 at 3:33 AM, Andrew Morton a...@linux-foundation.org wrote: On Fri, 13 Aug 2010 10:13:04 +0200 Marek Szyprowski m.szyprow...@samsung.com wrote: Hello, On Friday, August 13, 2010 9:32 AM Kukjin Kim wrote: This is just information about Samsung sdmmc stuff building error now. I found Marek's 'sdhci-s3c: enable SDHCI_QUIRK_NO_HISPD_BIT quirk' in the Linus' tree. (commit ID: a1d5646005af1247d6ae78434bb4db15b07a07b2) But not defined the quirk yet...so following build error happened with s3c6400_defconfig in Linus' latest. drivers/mmc/host/sdhci-s3c.c: In function 'sdhci_s3c_probe': drivers/mmc/host/sdhci-s3c.c:400: error: 'SDHCI_QUIRK_NO_HISPD_BIT' undeclared (first use in this function) drivers/mmc/host/sdhci-s3c.c:400: error: (Each undeclared identifier is reported only once drivers/mmc/host/sdhci-s3c.c:400: error: for each function it appears in.) make[4]: *** [drivers/mmc/host/sdhci-s3c.o] Error 1 make[3]: *** [drivers/mmc/host] Error 2 make[2]: *** [drivers/mmc] Error 2 make[1]: *** [drivers] Error 2 Kyungmin Park's below patch can solve this and it is in mmotm now. (commit ID: 2935b9e7fcc4bea3751b8d039b383b2036a7d36d) But I think, to update quirk definition should being in Marek's patch for avoiding build error. Of course, I'm not sure whether the commit order changed. Anyway, in this case, will be solved after merging mm tree. And second case is same. Marek's 'sdhci-s3c: add support for new card detection methods' cause following build error. (commit ID:17866e14f3a4f219e94f1374ece7226479418ff8) drivers/built-in.o: In function `sdhci_s3c_notify_change': /home/kgene/linux/linux-2.6-mainline-dev/drivers/mmc/host/sdhci-s3c.c:255: undefined reference to `sdhci_card_detect' make[1]: *** [.tmp_vmlinux1] Error 1 make: *** [sub-make] Error 2 and this issue is another. check the this. http://marc.info/?l=linux-mmcm=128201811218629w=3 And Andrew's patch(b567e5dd5a34c184e5642100e752cb87e064bb97) can solve this. (of course this needs another patches...) Anyway... Marek, in future please make sure your patch has no building problem before submitting. (or it can help to add some kind of dependency note in your patch) My patches submited to Andrew Morton had the description and a note that they have been prepared especially for his tree, taking into account all patches that are already there (mainly a tasklets to threaded irq conversion). For me it was quite obvious that they will be merged after all other sdhci changes from that tree. I have no idea why the order of the patches has been reversed and my sdhci patches has been submitted to Linus before the other sdhci changes. We're talking about these: s5pc110-sdhci-s3c-can-override-host-capabilities.patch s5pc110-sdhci-s3c-support-on-s5pc110.patch sdhci-add-no-hi-speed-bit-quirk-support.patch I have a note that these await an ack from Ben Dooks so I held them back for a closer look after -rc1. I was unaware of this dependency. Ben, are you OK with those patches? These are required for support s5pc110 s5pc210. Current sdhci on s5p has some wrong assumption. only support 4-bit bandwidth. and don't consider the embedded mmc like eMMC. http://userweb.kernel.org/~akpm/mmotm/broken-out/s5pc110-sdhci-s3c-can-override-host-capabilities.patch It required for override the host caps and pass to the mmc with correct caps http://userweb.kernel.org/~akpm/mmotm/broken-out/s5pc110-sdhci-s3c-support-on-s5pc110.patch required for support s5pc110 and also s5pc210 http://userweb.kernel.org/~akpm/mmotm/broken-out/sdhci-add-no-hi-speed-bit-quirk-support.patch As SDHCI on s5p don't has HISPD bit in controller register. need to quirks. Thanks. -- 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 3/3] ARM: S5PV310: Add support HSMMC on SMDKC210 and SMDKV310
On Fri, Aug 20, 2010 at 9:33 PM, Kukjin Kim kgene@samsung.com wrote:
From: Hyuk Lee hyuk1@samsung.com
This patch adds support HSMMC on SMDKC210 and SMDKV310, and adds
setup functions for it. S5PV310/S5PC210 can support 4 hsmmc such
as hsmmc0, hsmmc1, hsmmc2 and hsmmc3.
Signed-off-by: Hyuk Lee hyuk1@samsung.com
Signed-off-by: Kukjin Kim kgene@samsung.com
---
arch/arm/mach-s5pv310/Kconfig | 21
arch/arm/mach-s5pv310/Makefile | 2 +
arch/arm/mach-s5pv310/cpu.c | 8 ++
arch/arm/mach-s5pv310/mach-smdkc210.c | 50 ++
arch/arm/mach-s5pv310/mach-smdkv310.c | 50 ++
arch/arm/mach-s5pv310/setup-sdhci-gpio.c | 141
arch/arm/mach-s5pv310/setup-sdhci.c | 56 +++
arch/arm/plat-samsung/include/plat/sdhci.h | 58 +++
8 files changed, 386 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-s5pv310/setup-sdhci-gpio.c
create mode 100644 arch/arm/mach-s5pv310/setup-sdhci.c
diff --git a/arch/arm/mach-s5pv310/Kconfig b/arch/arm/mach-s5pv310/Kconfig
index 9ac29fe..bebad32 100644
--- a/arch/arm/mach-s5pv310/Kconfig
+++ b/arch/arm/mach-s5pv310/Kconfig
@@ -25,6 +25,17 @@ config S5PV310_SETUP_I2C2
help
Common setup code for i2c bus 2.
+config S5PV310_SETUP_SDHCI
+ bool
+ select S5PV310_SETUP_SDHCI_GPIO
+ help
+ Internal helper functions for S5PV310 based SDHCI systems.
+
+config S5PV310_SETUP_SDHCI_GPIO
+ bool
+ help
+ Common setup code for SDHCI GPIO.
+
# machine support
menu S5PC210 Machines
@@ -33,6 +44,11 @@ config MACH_SMDKC210
bool SMDKC210
select CPU_S5PV310
select ARCH_SPARSEMEM_ENABLE
+ select S3C_DEV_HSMMC
+ select S3C_DEV_HSMMC1
+ select S3C_DEV_HSMMC2
+ select S3C_DEV_HSMMC3
+ select S5PV310_SETUP_SDHCI
help
Machine support for Samsung SMDKC210
S5PC210(MCP) is one of package option of S5PV310
@@ -53,6 +69,11 @@ config MACH_SMDKV310
bool SMDKV310
select CPU_S5PV310
select ARCH_SPARSEMEM_ENABLE
+ select S3C_DEV_HSMMC
+ select S3C_DEV_HSMMC1
+ select S3C_DEV_HSMMC2
+ select S3C_DEV_HSMMC3
+ select S5PV310_SETUP_SDHCI
help
Machine support for Samsung SMDKV310
diff --git a/arch/arm/mach-s5pv310/Makefile b/arch/arm/mach-s5pv310/Makefile
index aefb14f..c89b6b0 100644
--- a/arch/arm/mach-s5pv310/Makefile
+++ b/arch/arm/mach-s5pv310/Makefile
@@ -29,3 +29,5 @@ obj-$(CONFIG_MACH_UNIVERSAL_C210) +=
mach-universal_c210.o
obj-$(CONFIG_S5PV310_SETUP_I2C1) += setup-i2c1.o
obj-$(CONFIG_S5PV310_SETUP_I2C2) += setup-i2c2.o
+obj-$(CONFIG_S5PV310_SETUP_SDHCI) += setup-sdhci.o
+obj-$(CONFIG_S5PV310_SETUP_SDHCI_GPIO) += setup-sdhci-gpio.o
diff --git a/arch/arm/mach-s5pv310/cpu.c b/arch/arm/mach-s5pv310/cpu.c
index db4f55a..3514e87 100644
--- a/arch/arm/mach-s5pv310/cpu.c
+++ b/arch/arm/mach-s5pv310/cpu.c
@@ -19,6 +19,7 @@
#include plat/cpu.h
#include plat/clock.h
#include plat/s5pv310.h
+#include plat/sdhci.h
#include mach/regs-irq.h
@@ -73,6 +74,13 @@ static void s5pv310_idle(void)
void __init s5pv310_map_io(void)
{
iotable_init(s5pv310_iodesc, ARRAY_SIZE(s5pv310_iodesc));
+
+ /* initialize device information early */
+
+ s5pv310_default_sdhci0();
+ s5pv310_default_sdhci1();
+ s5pv310_default_sdhci2();
+ s5pv310_default_sdhci3();
}
void __init s5pv310_init_clocks(int xtal)
diff --git a/arch/arm/mach-s5pv310/mach-smdkc210.c
b/arch/arm/mach-s5pv310/mach-smdkc210.c
index 71a3bec..52c85de 100644
--- a/arch/arm/mach-s5pv310/mach-smdkc210.c
+++ b/arch/arm/mach-s5pv310/mach-smdkc210.c
@@ -9,6 +9,7 @@
*/
#include linux/serial_core.h
+#include linux/gpio.h
#include asm/mach/arch.h
#include asm/mach-types.h
@@ -16,7 +17,9 @@
#include plat/regs-serial.h
#include plat/s5pv310.h
+#include plat/devs.h
#include plat/cpu.h
+#include plat/sdhci.h
#include mach/map.h
@@ -65,6 +68,49 @@ static struct s3c2410_uartcfg smdkc210_uartcfgs[]
__initdata = {
},
};
+static struct s3c_sdhci_platdata smdkc210_hsmmc0_pdata __initdata = {
+ .max_width = 4,
+ .cd_type = S3C_SDHCI_CD_GPIO,
+ .ext_cd_gpio = S5PV310_GPK0(2),
+ .ext_cd_gpio_invert = 1,
+};
+
+static struct s3c_sdhci_platdata smdkc210_hsmmc1_pdata __initdata = {
+ .max_width = 4,
+ .cd_type = S3C_SDHCI_CD_GPIO,
+ .ext_cd_gpio = S5PV310_GPK0(2),
+ .ext_cd_gpio_invert = 1,
+};
+
+static struct s3c_sdhci_platdata smdkc210_hsmmc2_pdata __initdata = {
+ .max_width = 4,
+ .cd_type = S3C_SDHCI_CD_GPIO,
+ .ext_cd_gpio =
Re: [PATCH 1/3] ARM: SAMSUNG: Change the 3rd HSMMC interrupt name for compatibility
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
On Fri, Aug 20, 2010 at 9:33 PM, Kukjin Kim kgene@samsung.com wrote:
This patch changes the 3rd HSMMC interrupt name for compatibility
from IRQ_MMC to IRQ_HSMMC3.
Signed-off-by: Kukjin Kim kgene@samsung.com
---
arch/arm/mach-s5pv210/include/mach/irqs.h | 2 +-
arch/arm/mach-s5pv310/include/mach/irqs.h | 5 +
arch/arm/plat-samsung/dev-hsmmc3.c | 4 ++--
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-s5pv210/include/mach/irqs.h
b/arch/arm/mach-s5pv210/include/mach/irqs.h
index e1c020e..cdb8ae4 100644
--- a/arch/arm/mach-s5pv210/include/mach/irqs.h
+++ b/arch/arm/mach-s5pv210/include/mach/irqs.h
@@ -109,7 +109,7 @@
#define IRQ_IPC S5P_IRQ_VIC3(0)
#define IRQ_HOSTIF S5P_IRQ_VIC3(1)
-#define IRQ_MMC3 S5P_IRQ_VIC3(2)
+#define IRQ_HSMMC3 S5P_IRQ_VIC3(2)
#define IRQ_CEC S5P_IRQ_VIC3(3)
#define IRQ_TSI S5P_IRQ_VIC3(4)
#define IRQ_MDNIE0 S5P_IRQ_VIC3(5)
diff --git a/arch/arm/mach-s5pv310/include/mach/irqs.h
b/arch/arm/mach-s5pv310/include/mach/irqs.h
index 4cdedda..522352f 100644
--- a/arch/arm/mach-s5pv310/include/mach/irqs.h
+++ b/arch/arm/mach-s5pv310/include/mach/irqs.h
@@ -68,6 +68,11 @@
#define IRQ_IIC COMBINER_IRQ(27, 0)
+#define IRQ_HSMMC0 COMBINER_IRQ(29, 0)
+#define IRQ_HSMMC1 COMBINER_IRQ(29, 1)
+#define IRQ_HSMMC2 COMBINER_IRQ(29, 2)
+#define IRQ_HSMMC3 COMBINER_IRQ(29, 3)
+
/* Set the default NR_IRQS */
#define NR_IRQS COMBINER_IRQ(MAX_COMBINER_NR, 0)
diff --git a/arch/arm/plat-samsung/dev-hsmmc3.c
b/arch/arm/plat-samsung/dev-hsmmc3.c
index 85aaf0f..335bc35 100644
--- a/arch/arm/plat-samsung/dev-hsmmc3.c
+++ b/arch/arm/plat-samsung/dev-hsmmc3.c
@@ -33,8 +33,8 @@ static struct resource s3c_hsmmc3_resource[] = {
.flags = IORESOURCE_MEM,
},
[1] = {
- .start = IRQ_MMC3,
- .end = IRQ_MMC3,
+ .start = IRQ_HSMMC3,
+ .end = IRQ_HSMMC3,
.flags = IORESOURCE_IRQ,
}
};
--
1.6.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
--
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/3] ARM: S5P: Add initial map for GPIO2 and GPIO3
On Mon, Aug 23, 2010 at 9:18 AM, Kukjin Kim kgene@samsung.com wrote:
Kyungmin Park wrote:
NAK.
I don't know why I need your ack for this...if any opinions, just comments
is enough.
Okay I said in other word, I can't agree this patch.
This approach don't make a common GPIO framework. I already send the
common GPIO framework which send the base address to GPIO framework
and handle it regradless GPIO is one or three.
I don't think that your that RFC GPIO patch is common GPIO framework.
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-August/022513.htm
l
With this patch, we can use the common GPIO framework and remove the
VA_GPIO dependency.
Why do you think your patch is common?
In another patch, you just write the driver strength with
readl/writel. even though gpiolib already has interface,
s5p_gpio_set_drvstr
and how to you implement the gpio_to_irq at both GPIO and EINT?
The common means GPIO related function should use the gpiolib
functions only. No direct access.
If your patch match these criteria then I'll ack your patch.
All
Thank you,
Kyungmin Park
On Fri, Aug 20, 2010 at 9:33 PM, Kukjin Kim kgene@samsung.com wrote:
From: Jongpill Lee boyko@samsung.com
This patch adds initial map for GPIO2 and GPIO3.
S5PV310/S5PC210 has separated GPIO1, GPIO2 and GPIO3.
Signed-off-by: Jongpill Lee boyko@samsung.com
Signed-off-by: Kukjin Kim kgene@samsung.com
---
arch/arm/mach-s5pv310/cpu.c | 10 ++
arch/arm/plat-s5p/include/plat/map-s5p.h | 2 ++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s5pv310/cpu.c b/arch/arm/mach-s5pv310/cpu.c
index 196c9f1..db4f55a 100644
--- a/arch/arm/mach-s5pv310/cpu.c
+++ b/arch/arm/mach-s5pv310/cpu.c
@@ -45,6 +45,16 @@ static struct map_desc s5pv310_iodesc[] __initdata =
{
.pfn = __phys_to_pfn(S5PV310_PA_L2CC),
.length = SZ_4K,
.type = MT_DEVICE,
+ }, {
+ .virtual = (unsigned long)S5P_VA_GPIO2,
+ .pfn = __phys_to_pfn(S5PV310_PA_GPIO2),
+ .length = SZ_4K,
+ .type = MT_DEVICE,
+ }, {
+ .virtual = (unsigned long)S5P_VA_GPIO3,
+ .pfn = __phys_to_pfn(S5PV310_PA_GPIO3),
+ .length = SZ_256K,
+ .type = MT_DEVICE,
},
};
diff --git a/arch/arm/plat-s5p/include/plat/map-s5p.h b/arch/arm/plat-
s5p/include/plat/map-s5p.h
index 54e9fb9..bc52595 100644
--- a/arch/arm/plat-s5p/include/plat/map-s5p.h
+++ b/arch/arm/plat-s5p/include/plat/map-s5p.h
@@ -15,6 +15,8 @@
#define S5P_VA_CHIPID S3C_ADDR(0x0070)
#define S5P_VA_GPIO S3C_ADDR(0x0050)
+#define S5P_VA_GPIO2 S3C_ADDR(0x0051)
+#define S5P_VA_GPIO3 S3C_ADDR(0x0052)
#define S5P_VA_SYSTIMER S3C_ADDR(0x0120)
#define S5P_VA_SROMC S3C_ADDR(0x0110)
--
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, 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
--
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 00/14] ARM: S5PV310: Updates clock
Well, The current V310 clock codes don't work. I wonder these codes are should be tested by your team. but it's just hang at clock init. With this patch, it's also don't boot. We also fixed the wrong uart clock bit. but same. don't works. Question? Do you can boot with this codes at your board? Thank you, Kyungmin Park Uncompressing Linux... done, booting the kernel. [0.00] Linux version 2.6.36-rc1-ga400ca7-dirty (dofm...@dofmind-linux) (gcc version 4.4.1 (GCC) ) #334 PREEMPT Mon Aug 23 10:45:59 KST 2010 [0.00] CPU: ARMv7 Processor [412fc091] revision 1 (ARMv7), cr=10c53c7f [0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [0.00] Machine: UNIVERSAL_C210 [0.00] bootconsole [earlycon0] enabled [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] CPU S5PV310 (id 0x43200200) [0.00] S3C24XX Clocks, Copyright 2004 Simtec Electronics [0.00] s3c_register_clksrc: clock armclk has no registers set [0.00] S5PV310: PLL settings, A=8, M=66000, E=9600 V=10800 [0.00] S5PV310: ARMCLK=8, DMC=33000, ACLK200=16500 [0.00] ACLK100=8250, ACLK160=13200, ACLK133=11000 [0.00] uclk1: source is mout_mpll (6), rate is 8250 [0.00] uclk1: source is mout_mpll (6), rate is 8250 [0.00] uclk1: source is mout_mpll (6), rate is 8250 [0.00] uclk1: source is mout_mpll (6), rate is 8250 [0.00] sclk_pwm: source is mout_mpll (6), rate is 7333 [0.00] sclk_csis: source is ext_xtal (0), rate is 2400 [0.00] sclk_csis: source is ext_xtal (0), rate is 2400 [0.00] sclk_cam: source is ext_xtal (0), rate is 2400 [0.00] sclk_cam: source is ext_xtal (0), rate is 2400 [0.00] sclk_fimc: source is ext_xtal (0), rate is 2400 [0.00] sclk_fimc: source is ext_xtal (0), rate is 2400 [0.00] sclk_fimc: source is ext_xtal (0), rate is 2400 [0.00] sclk_fimc: source is ext_xtal (0), rate is 2400 [0.00] sclk_fimd: source is ext_xtal (0), rate is 2400 [0.00] sclk_fimd: source is ext_xtal (0), rate is 2400 [0.00] sclk_sata: source is mout_mpll (0), rate is 11000 [0.00] sclk_spi: source is ext_xtal (0), rate is 2400 [0.00] sclk_spi: source is ext_xtal (0), rate is 2400 [0.00] sclk_spi: source is ext_xtal (0), rate is 2400 [0.00] sclk_fimg2d: source is mout_g2d0 (0), rate is 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 [0.00] Kernel command line: root=ubi0!rootfs rootfstype=ubifs rootflags=bulk_read,no_chk_data_crc ubi.mtd=8 ubi.mtd=3 ubi.mtd=6 earlyprintk console=ttySAC2,115200n8 mem=512M mtdparts=samsung-onenan) [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Memory: 512MB = 512MB total [0.00] Memory: 517040k/517040k available, 7248k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] DMA : 0xffc0 - 0xffe0 ( 2 MB) [0.00] vmalloc : 0xe080 - 0xf000 ( 248 MB) [0.00] lowmem : 0xc000 - 0xe000 ( 512 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .init : 0xc0008000 - 0xc001f000 ( 92 kB) [0.00] .text : 0xc001f000 - 0xc023b000 (2160 kB) [0.00] .data : 0xc025 - 0xc0271340 ( 133 kB) [0.00] SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] Hierarchical RCU implementation. [0.00] RCU-based detection of stalled CPUs is disabled. [0.00] Verbose stalled-CPUs detection is disabled. [0.00] NR_IRQS:440 [0.00] Console: colour dummy device 80x30 s3c24xx_serial_initconsole s3c24xx_serial_init_ports: initialising ports... s3c24xx_serial_init_port: port=c026caa0, platdev=c0271b20 s3c24xx_serial_init_port: c026caa0 (hw 0)... resource c02564b8 (1380..13800100) port: map=1380, mem=f500, irq=16 (16,18), clock=1 s3c24xx_serial_init_port: port=c026cb68, platdev=c0256f08 s3c24xx_serial_init_port: c026cb68 (hw 1)... resource c0256528 (1381..13810100) port: map=1381, mem=f501, irq=20 (20,22), clock=1 s3c24xx_serial_init_port: port=c026cc30, platdev=c0256fe8 s3c24xx_serial_init_port: c026cc30 (hw 2)... resource c0256598 (1382..13820100) port: map=1382, mem=f502, irq=24 (24,26), clock=1 s3c24xx_serial_init_port: port=c026ccf8, platdev=c02570c8 s3c24xx_serial_init_port: c026ccf8 (hw 3)... resource c0256608 (1383..13830100) port
RE: [PATCH RE-SEND] ARM: S5P: Move OneNAND device definitions in plat-s5p
Note: S5PC110 and S5PC210 have same OneNAND driver.
Yes I also think it's same device. At least Spec is same. But I heard it has
some different feature related with DMA operation.
I'm not yet receive the official release from LSI. So I can't tell the exact
one.
If it's true. we need to separate it if required.
Thank you,
Kyungmin Park
-Original Message-
From: Kukjin Kim [mailto:kgene@samsung.com]
Sent: Monday, August 23, 2010 9:07 AM
To: linux-arm-ker...@lists.infradead.org; linux-samsung-soc@vger.kernel.org
Cc: ben-li...@fluff.org; Kukjin Kim; Kyungmin Park
Subject: [PATCH RE-SEND] ARM: S5P: Move OneNAND device definitions in
plat-s5p
This patch moves OneNAND device definitions from mach-s5pv210 to plat-s5p
so that can support it commonly.
Note: S5PC110 and S5PC210 have same OneNAND driver.
Signed-off-by: Kukjin Kim kgene@samsung.com
Cc: Kyungmin Park Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-s5pv210/Kconfig |9 +-
arch/arm/mach-s5pv210/Makefile|1 -
arch/arm/mach-s5pv210/include/mach/map.h |3 ++
arch/arm/mach-s5pv210/mach-aquila.c |2 +-
arch/arm/mach-s5pv210/mach-goni.c |2 +-
arch/arm/mach-s5pv310/include/mach/irqs.h |2 +
arch/arm/mach-s5pv310/include/mach/map.h |6
arch/arm/plat-s5p/Kconfig |5 +++
arch/arm/plat-s5p/Makefile|1 +
arch/arm/{mach-s5pv210 = plat-s5p}/dev-onenand.c | 28
+++-
arch/arm/plat-samsung/include/plat/devs.h |2 +-
11 files changed, 37 insertions(+), 24 deletions(-)
rename arch/arm/{mach-s5pv210 = plat-s5p}/dev-onenand.c (59%)
diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
index d3a3895..5315fec 100644
--- a/arch/arm/mach-s5pv210/Kconfig
+++ b/arch/arm/mach-s5pv210/Kconfig
@@ -53,11 +53,6 @@ config S5PV210_SETUP_SDHCI_GPIO
help
Common setup code for SDHCI gpio.
-config S5PC110_DEV_ONENAND
- bool
- help
- Compile in platform device definition for OneNAND1 controller
-
menu S5PC110 Machines
config MACH_AQUILA
@@ -71,7 +66,7 @@ config MACH_AQUILA
select S3C_DEV_HSMMC
select S3C_DEV_HSMMC1
select S3C_DEV_HSMMC2
- select S5PC110_DEV_ONENAND
+ select S5P_DEV_ONENAND
select S5PV210_SETUP_FB_24BPP
select S5PV210_SETUP_SDHCI
help
@@ -88,7 +83,7 @@ config MACH_GONI
select S3C_DEV_HSMMC
select S3C_DEV_HSMMC1
select S3C_DEV_HSMMC2
- select S5PC110_DEV_ONENAND
+ select S5P_DEV_ONENAND
select S5PV210_SETUP_FB_24BPP
select S5PV210_SETUP_SDHCI
help
diff --git a/arch/arm/mach-s5pv210/Makefile b/arch/arm/mach-s5pv210/Makefile
index 05048c5..7045489 100644
--- a/arch/arm/mach-s5pv210/Makefile
+++ b/arch/arm/mach-s5pv210/Makefile
@@ -26,7 +26,6 @@ obj-$(CONFIG_MACH_GONI) += mach-goni.o
obj-y += dev-audio.o
obj-$(CONFIG_S3C64XX_DEV_SPI) += dev-spi.o
-obj-$(CONFIG_S5PC110_DEV_ONENAND) += dev-onenand.o
obj-$(CONFIG_S5PV210_SETUP_FB_24BPP) += setup-fb-24bpp.o
obj-$(CONFIG_S5PV210_SETUP_I2C1) += setup-i2c1.o
diff --git a/arch/arm/mach-s5pv210/include/mach/map.h
b/arch/arm/mach-s5pv210/include/mach/map.h
index dd4fb6b..aa19d2f 100644
--- a/arch/arm/mach-s5pv210/include/mach/map.h
+++ b/arch/arm/mach-s5pv210/include/mach/map.h
@@ -17,7 +17,10 @@
#include plat/map-s5p.h
#define S5PC110_PA_ONENAND (0xB000)
+#define S5P_PA_ONENAND S5PC110_PA_ONENAND
+
#define S5PC110_PA_ONENAND_DMA (0xB060)
+#define S5P_PA_ONENAND_DMA S5PC110_PA_ONENAND_DMA
#define S5PV210_PA_CHIPID (0xE000)
#define S5P_PA_CHIPID S5PV210_PA_CHIPID
diff --git a/arch/arm/mach-s5pv210/mach-aquila.c
b/arch/arm/mach-s5pv210/mach-aquila.c
index 0dda801..bf772de 100644
--- a/arch/arm/mach-s5pv210/mach-aquila.c
+++ b/arch/arm/mach-s5pv210/mach-aquila.c
@@ -477,7 +477,7 @@ static struct platform_device *aquila_devices[]
__initdata = {
aquila_i2c_gpio_pmic,
aquila_device_gpiokeys,
s3c_device_fb,
- s5pc110_device_onenand,
+ s5p_device_onenand,
s3c_device_hsmmc0,
s3c_device_hsmmc1,
s3c_device_hsmmc2,
diff --git a/arch/arm/mach-s5pv210/mach-goni.c
b/arch/arm/mach-s5pv210/mach-goni.c
index 53754d7..fdc5cca 100644
--- a/arch/arm/mach-s5pv210/mach-goni.c
+++ b/arch/arm/mach-s5pv210/mach-goni.c
@@ -456,7 +456,7 @@ static void goni_setup_sdhci(void)
static struct platform_device *goni_devices[] __initdata = {
s3c_device_fb,
- s5pc110_device_onenand,
+ s5p_device_onenand,
goni_i2c_gpio_pmic,
goni_device_gpiokeys,
s5p_device_fimc0,
diff --git a/arch/arm/mach-s5pv310/include/mach/irqs.h
b/arch/arm/mach-s5pv310/include/mach/irqs.h
index 522352f..7b4b09f 100644
--- a/arch/arm/mach-s5pv310/include/mach
Re: [PATCH 2/3] ARM: S5P: Add initial map for GPIO2 and GPIO3
On Mon, Aug 23, 2010 at 11:15 AM, Kukjin Kim kgene@samsung.com wrote:
Kyungmin Park wrote:
On Mon, Aug 23, 2010 at 9:18 AM, Kukjin Kim kgene@samsung.com wrote:
Kyungmin Park wrote:
NAK.
I don't know why I need your ack for this...if any opinions, just
comments
is enough.
Okay I said in other word, I can't agree this patch.
This approach don't make a common GPIO framework. I already send the
common GPIO framework which send the base address to GPIO framework
and handle it regradless GPIO is one or three.
I don't think that your that RFC GPIO patch is common GPIO framework.
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-August/022513.htm
l
With this patch, we can use the common GPIO framework and remove the
VA_GPIO dependency.
Why do you think your patch is common?
In another patch, you just write the driver strength with
readl/writel. even though gpiolib already has interface,
s5p_gpio_set_drvstr
I missed gpio driver strength driver. Will fix it.
But this issue is not regarding gpio driver strength.
and how to you implement the gpio_to_irq at both GPIO and EINT?
Will sort it out.
The common means GPIO related function should use the gpiolib
functions only. No direct access.
It means don't need to use your previous patch which is just RFC regarding
removing VA_GPIO.
and make it for multiple GPIOs such as s5pc210. also make it simple
for GPIOs and EINT.
It's also cover the gpio_to_irq to use the similar scheme either GPIOs or EINT.
If your patch match these criteria then I'll ack your patch.
Hmm...
All
Thank you,
Kyungmin Park
On Fri, Aug 20, 2010 at 9:33 PM, Kukjin Kim kgene@samsung.com
wrote:
From: Jongpill Lee boyko@samsung.com
This patch adds initial map for GPIO2 and GPIO3.
S5PV310/S5PC210 has separated GPIO1, GPIO2 and GPIO3.
Signed-off-by: Jongpill Lee boyko@samsung.com
Signed-off-by: Kukjin Kim kgene@samsung.com
---
arch/arm/mach-s5pv310/cpu.c | 10 ++
arch/arm/plat-s5p/include/plat/map-s5p.h | 2 ++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s5pv310/cpu.c
b/arch/arm/mach-s5pv310/cpu.c
index 196c9f1..db4f55a 100644
--- a/arch/arm/mach-s5pv310/cpu.c
+++ b/arch/arm/mach-s5pv310/cpu.c
@@ -45,6 +45,16 @@ static struct map_desc s5pv310_iodesc[] __initdata
=
{
.pfn = __phys_to_pfn(S5PV310_PA_L2CC),
.length = SZ_4K,
.type = MT_DEVICE,
+ }, {
+ .virtual = (unsigned long)S5P_VA_GPIO2,
+ .pfn = __phys_to_pfn(S5PV310_PA_GPIO2),
+ .length = SZ_4K,
+ .type = MT_DEVICE,
+ }, {
+ .virtual = (unsigned long)S5P_VA_GPIO3,
+ .pfn = __phys_to_pfn(S5PV310_PA_GPIO3),
+ .length = SZ_256K,
+ .type = MT_DEVICE,
},
};
diff --git a/arch/arm/plat-s5p/include/plat/map-s5p.h
b/arch/arm/plat-
s5p/include/plat/map-s5p.h
index 54e9fb9..bc52595 100644
--- a/arch/arm/plat-s5p/include/plat/map-s5p.h
+++ b/arch/arm/plat-s5p/include/plat/map-s5p.h
@@ -15,6 +15,8 @@
#define S5P_VA_CHIPID S3C_ADDR(0x0070)
#define S5P_VA_GPIO S3C_ADDR(0x0050)
+#define S5P_VA_GPIO2 S3C_ADDR(0x0051)
+#define S5P_VA_GPIO3 S3C_ADDR(0x0052)
#define S5P_VA_SYSTIMER S3C_ADDR(0x0120)
#define S5P_VA_SROMC S3C_ADDR(0x0110)
--
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, 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 RE-SEND] ARM: S5P: Move OneNAND device definitions in plat-s5p
On Mon, Aug 23, 2010 at 11:35 AM, Kukjin Kim kgene@samsung.com wrote:
Kyungmin Park wrote:
Note: S5PC110 and S5PC210 have same OneNAND driver.
Yes I also think it's same device. At least Spec is same. But I heard it
has
some different feature related with DMA operation.
I'm not yet receive the official release from LSI. So I can't tell the
exact
one.
If it's true. we need to separate it if required.
No need to separate this stuff.
It means that no problem to use this commonly for S5PC110 and S5PC210.
As DMA operation is changed, we need to register onenand device
separately like s5pc210-onenand.
to use the different read operations.
But...I will check it again before applying.
Thank you,
Kyungmin Park
-Original Message-
From: Kukjin Kim [mailto:kgene@samsung.com]
Sent: Monday, August 23, 2010 9:07 AM
To: linux-arm-ker...@lists.infradead.org;
linux-samsung-soc@vger.kernel.org
Cc: ben-li...@fluff.org; Kukjin Kim; Kyungmin Park
Subject: [PATCH RE-SEND] ARM: S5P: Move OneNAND device definitions in
plat-s5p
This patch moves OneNAND device definitions from mach-s5pv210 to plat-s5p
so that can support it commonly.
Note: S5PC110 and S5PC210 have same OneNAND driver.
Signed-off-by: Kukjin Kim kgene@samsung.com
Cc: Kyungmin Park Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-s5pv210/Kconfig | 9 +-
arch/arm/mach-s5pv210/Makefile | 1 -
arch/arm/mach-s5pv210/include/mach/map.h | 3 ++
arch/arm/mach-s5pv210/mach-aquila.c | 2 +-
arch/arm/mach-s5pv210/mach-goni.c | 2 +-
arch/arm/mach-s5pv310/include/mach/irqs.h | 2 +
arch/arm/mach-s5pv310/include/mach/map.h | 6
arch/arm/plat-s5p/Kconfig | 5 +++
arch/arm/plat-s5p/Makefile | 1 +
arch/arm/{mach-s5pv210 = plat-s5p}/dev-onenand.c | 28
+++-
arch/arm/plat-samsung/include/plat/devs.h | 2 +-
11 files changed, 37 insertions(+), 24 deletions(-)
rename arch/arm/{mach-s5pv210 = plat-s5p}/dev-onenand.c (59%)
diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
index d3a3895..5315fec 100644
--- a/arch/arm/mach-s5pv210/Kconfig
+++ b/arch/arm/mach-s5pv210/Kconfig
@@ -53,11 +53,6 @@ config S5PV210_SETUP_SDHCI_GPIO
help
Common setup code for SDHCI gpio.
-config S5PC110_DEV_ONENAND
- bool
- help
- Compile in platform device definition for OneNAND1 controller
-
menu S5PC110 Machines
config MACH_AQUILA
@@ -71,7 +66,7 @@ config MACH_AQUILA
select S3C_DEV_HSMMC
select S3C_DEV_HSMMC1
select S3C_DEV_HSMMC2
- select S5PC110_DEV_ONENAND
+ select S5P_DEV_ONENAND
select S5PV210_SETUP_FB_24BPP
select S5PV210_SETUP_SDHCI
help
@@ -88,7 +83,7 @@ config MACH_GONI
select S3C_DEV_HSMMC
select S3C_DEV_HSMMC1
select S3C_DEV_HSMMC2
- select S5PC110_DEV_ONENAND
+ select S5P_DEV_ONENAND
select S5PV210_SETUP_FB_24BPP
select S5PV210_SETUP_SDHCI
help
diff --git a/arch/arm/mach-s5pv210/Makefile
b/arch/arm/mach-s5pv210/Makefile
index 05048c5..7045489 100644
--- a/arch/arm/mach-s5pv210/Makefile
+++ b/arch/arm/mach-s5pv210/Makefile
@@ -26,7 +26,6 @@ obj-$(CONFIG_MACH_GONI) += mach-goni.o
obj-y += dev-audio.o
obj-$(CONFIG_S3C64XX_DEV_SPI) += dev-spi.o
-obj-$(CONFIG_S5PC110_DEV_ONENAND) += dev-onenand.o
obj-$(CONFIG_S5PV210_SETUP_FB_24BPP) += setup-fb-24bpp.o
obj-$(CONFIG_S5PV210_SETUP_I2C1) += setup-i2c1.o
diff --git a/arch/arm/mach-s5pv210/include/mach/map.h
b/arch/arm/mach-s5pv210/include/mach/map.h
index dd4fb6b..aa19d2f 100644
--- a/arch/arm/mach-s5pv210/include/mach/map.h
+++ b/arch/arm/mach-s5pv210/include/mach/map.h
@@ -17,7 +17,10 @@
#include plat/map-s5p.h
#define S5PC110_PA_ONENAND (0xB000)
+#define S5P_PA_ONENAND S5PC110_PA_ONENAND
+
#define S5PC110_PA_ONENAND_DMA (0xB060)
+#define S5P_PA_ONENAND_DMA S5PC110_PA_ONENAND_DMA
#define S5PV210_PA_CHIPID (0xE000)
#define S5P_PA_CHIPID S5PV210_PA_CHIPID
diff --git a/arch/arm/mach-s5pv210/mach-aquila.c
b/arch/arm/mach-s5pv210/mach-aquila.c
index 0dda801..bf772de 100644
--- a/arch/arm/mach-s5pv210/mach-aquila.c
+++ b/arch/arm/mach-s5pv210/mach-aquila.c
@@ -477,7 +477,7 @@ static struct platform_device *aquila_devices[]
__initdata = {
aquila_i2c_gpio_pmic,
aquila_device_gpiokeys,
s3c_device_fb,
- s5pc110_device_onenand,
+ s5p_device_onenand,
s3c_device_hsmmc0,
s3c_device_hsmmc1,
s3c_device_hsmmc2,
diff --git a/arch/arm/mach-s5pv210/mach-goni.c
b/arch/arm/mach-s5pv210/mach-goni.c
index 53754d7..fdc5cca 100644
--- a/arch/arm/mach-s5pv210/mach-goni.c
+++ b/arch/arm/mach-s5pv210/mach-goni.c
