[PATCH 0/3] ARM: EXYNOS: Fix Exynos5410 boot
Hello, This mini-series unbreaks booting on 5410 based ODROID-XU. Since I do not have access to a TRM, the address is a guess based on 5250 and 5410. Such a node was not present in the 3.14 downstream tree. Regards, Andreas Andreas Färber (3): Documentation: devicetree: Document exynos5410 PMU ARM: dts: exynos: Add PMU to Exynos5410 ARM: EXYNOS: Add support for Exynos5410 PMU Documentation/devicetree/bindings/arm/samsung/pmu.txt | 1 + arch/arm/boot/dts/exynos5410.dtsi | 5 + arch/arm/mach-exynos/exynos.c | 1 + 3 files changed, 7 insertions(+) -- 1.9.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
[PATCH 1/3] Documentation: devicetree: Document exynos5410 PMU
We will start using samsung,exynos5410-pmu. Signed-off-by: Andreas Färber afaer...@suse.de --- Documentation/devicetree/bindings/arm/samsung/pmu.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt b/Documentation/devicetree/bindings/arm/samsung/pmu.txt index 2a4ab046a8a1..fe14d8118093 100644 --- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt +++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt @@ -7,6 +7,7 @@ Properties: - samsung,exynos4212-pmu - for Exynos4212 SoC, - samsung,exynos4412-pmu - for Exynos4412 SoC, - samsung,exynos5250-pmu - for Exynos5250 SoC, + - samsung,exynos5410-pmu - for Exynos5410 SoC, - samsung,exynos5420-pmu - for Exynos5420 SoC. second value must be always syscon. -- 1.9.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
[PATCH 2/3] ARM: dts: exynos: Add PMU to Exynos5410
Exynos initialization code now relies on obtaining the PMU address,
so prepare a PMU node for Exynos5410.
Fixes: fce9e5bb2526 (ARM: EXYNOS: Add support for mapping PMU base address via
DT)
Signed-off-by: Andreas Färber afaer...@suse.de
---
arch/arm/boot/dts/exynos5410.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index 9d0b8cc1409c..790d4886d7b5 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -91,6 +91,11 @@
reg = 0x1000 0x100;
};
+ pmu_system_controller: system-controller@1004 {
+ compatible = samsung,exynos5410-pmu, syscon;
+ reg = 0x1004 0x5000;
+ };
+
mct: mct@101C {
compatible = samsung,exynos4210-mct;
reg = 0x101C 0xB00;
--
1.9.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
[PATCH 3/3] ARM: EXYNOS: Add support for Exynos5410 PMU
Exynos initialization code now relies on obtaining the PMU address,
so add the new 5410 value to the list of compatible string matches.
This unbreaks booting on 5410 based boards.
Fixes: fce9e5bb2526 (ARM: EXYNOS: Add support for mapping PMU base address via
DT)
Signed-off-by: Andreas Färber afaer...@suse.de
---
arch/arm/mach-exynos/exynos.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index df41bd190dfb..a83a312299a3 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -252,6 +252,7 @@ static const struct of_device_id exynos_dt_pmu_match[] = {
{ .compatible = samsung,exynos4212-pmu },
{ .compatible = samsung,exynos4412-pmu },
{ .compatible = samsung,exynos5250-pmu },
+ { .compatible = samsung,exynos5410-pmu },
{ .compatible = samsung,exynos5420-pmu },
{ /*sentinel*/ },
};
--
1.9.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
Re: [PATCH 0/3] ARM: EXYNOS: Fix Exynos5410 boot
Am 27.07.2014 14:22, schrieb Andreas Färber: Hello, This mini-series unbreaks booting on 5410 based ODROID-XU. Since I do not have access to a TRM, the address is a guess based on 5250 and 5410. Such a node was not present in the 3.14 downstream tree. s/5410/5420/ Regards, Andreas Andreas Färber (3): Documentation: devicetree: Document exynos5410 PMU ARM: dts: exynos: Add PMU to Exynos5410 ARM: EXYNOS: Add support for Exynos5410 PMU Documentation/devicetree/bindings/arm/samsung/pmu.txt | 1 + arch/arm/boot/dts/exynos5410.dtsi | 5 + arch/arm/mach-exynos/exynos.c | 1 + 3 files changed, 7 insertions(+) -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- 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: kgene's for-next branch broken, and boot regressions
Am 27.07.2014 07:57, schrieb Andreas Färber: Am 27.07.2014 05:08, schrieb Andreas Färber: On the ODROID-XU (with local patches based on smdk5410) I get the following with earlyprintk: [...] [0.00] Kernel panic - not syncing: failed to find exynos pmu register [...] Reverting ARM: EXYNOS: Refactored code for using PMU address via DT and ARM: EXYNOS: Add support for mapping PMU base address via DT fixed the latter. Adding a samsung,exynos5410-pmu system-controller node like on 5420 fixes this as well. Patchset being prepared. http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34686.html Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- 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] mmc: dw_mmc: Make sure we don't get stuck when we get an error
Hi Chris Ulf,
I hope you find this patch for next.
Thanks,
Seungwon Jeon
On Wed, May 21, 2014, Seungwon Jeon wrote:
On Wed, May 21, 2014, Doug Anderson wrote:
If we happened to get a data error at just the wrong time the dw_mmc
driver could get into a state where it would never complete its
request. That would leave the caller just hanging there.
We fix this two ways and both of the two fixes on their own appear to
fix the problems we've seen:
1. Fix a race in the tasklet where the interrupt setting the data
error happens _just after_ we check for it, then we get a
EVENT_XFER_COMPLETE. We fix this by repeating a bit of code.
2. Fix it so that if we detect that we've got an error in the data
busy state and we're not going to do anything else we end the
request and unblock anyone waiting.
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Yuvaraj Kumar C D yuvaraj...@gmail.com
It will be applied after mmc: dw_mmc: change to use recommended reset
procedure
Acked-by: Seungwon Jeon tgih@samsung.com
Thanks,
Seungwon Jeon
---
Changes in v2:
- Removed TODO
- Set cmd to NULL before calling dw_mci_request_end()
drivers/mmc/host/dw_mmc.c | 46
++
1 file changed, 46 insertions(+)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index cced599..54ec8b0 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1318,6 +1318,14 @@ static void dw_mci_tasklet_func(unsigned long priv)
/* fall through */
case STATE_SENDING_DATA:
+ /*
+* We could get a data error and never a transfer
+* complete so we'd better check for it here.
+*
+* Note that we don't really care if we also got a
+* transfer complete; stopping the DMA and sending an
+* abort won't hurt.
+*/
if (test_and_clear_bit(EVENT_DATA_ERROR,
host-pending_events)) {
dw_mci_stop_dma(host);
@@ -1331,7 +1339,29 @@ static void dw_mci_tasklet_func(unsigned long priv)
break;
set_bit(EVENT_XFER_COMPLETE, host-completed_events);
+
+ /*
+* Handle an EVENT_DATA_ERROR that might have shown up
+* before the transfer completed. This might not have
+* been caught by the check above because the interrupt
+* could have gone off between the previous check and
+* the check for transfer complete.
+*
+* Technically this ought not be needed assuming we
+* get a DATA_COMPLETE eventually (we'll notice the
+* error and end the request), but it shouldn't hurt.
+*
+* This has the advantage of sending the stop command.
+*/
+ if (test_and_clear_bit(EVENT_DATA_ERROR,
+ host-pending_events)) {
+ dw_mci_stop_dma(host);
+ send_stop_abort(host, data);
+ state = STATE_DATA_ERROR;
+ break;
+ }
prev_state = state = STATE_DATA_BUSY;
+
/* fall through */
case STATE_DATA_BUSY:
@@ -1354,6 +1384,22 @@ static void dw_mci_tasklet_func(unsigned long priv)
/* stop command for open-ended transfer*/
if (data-stop)
send_stop_abort(host, data);
+ } else {
+ /*
+* If we don't have a command complete now we'll
+* never get one since we just reset everything;
+* better end the request.
+*
+* If we do have a command complete we'll fall
+* through to the SENDING_STOP command and
+* everything will be peachy keen.
+*/
+ if (!test_bit(EVENT_CMD_COMPLETE,
+ host-pending_events)) {
+ host-cmd = NULL;
+ dw_mci_request_end(host, mrq);
+ goto unlock;
+ }
}
/*
--
1.9.1.423.g4596e3a
--
To unsubscribe from this
Re: kgene's for-next branch broken, and boot regressions
Am 27.07.2014 05:08, schrieb Andreas Färber: On the Arndale Octa (5420) I see an asynchronous external abort on serial console when systemd gets started. http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34680.html This turned out to be somehow caused by MCPM driver. Disabling MCPM and ARM_BIG_LITTLE_CPUIDLE worked around it. On the Spring Chromebook (5250) the screen goes dark after a few lines, and USB is not initialized. Thus unclear to me why. Using boot_delay=1000 I tracked this down to the DRM initialization. Reverting the previously working DRM bridge series v4 and commenting out spring's dp-controller node worked around this. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- 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 0/8] drm/exynos: few patches to enhance bridge chip support
Hi Ajay, Am 25.07.2014 21:22, schrieb Ajay Kumar: This series is based on exynos-drm-next branch of Inki Dae's tree at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git I have tested this after adding few DT changes for exynos5250-snow, exynos5420-peach-pit and exynos5800-peach-pi boards. I'm trying to test this with a modified exynos5250-spring DT based off kgene's for-next branch due to DT, and I run into the following: CC drivers/gpu/drm/bridge/ptn3460.o drivers/gpu/drm/bridge/ptn3460.c: In function ‘ptn3460_post_encoder_init’: drivers/gpu/drm/bridge/ptn3460.c:275:2: error: implicit declaration of function ‘drm_connector_register’ [-Werror=implicit-function-declaration] drm_connector_register(ptn_bridge-connector); ^ cc1: some warnings being treated as errors scripts/Makefile.build:257: recipe for target 'drivers/gpu/drm/bridge/ptn3460.o' failed make[4]: *** [drivers/gpu/drm/bridge/ptn3460.o] Error 1 scripts/Makefile.build:404: recipe for target 'drivers/gpu/drm/bridge' failed make[3]: *** [drivers/gpu/drm/bridge] Error 2 make[3]: *** Warte auf noch nicht beendete Prozesse... scripts/Makefile.build:404: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:404: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:899: recipe for target 'drivers' failed make: *** [drivers] Error 2 Any hint which prerequisite I'm missing? Didn't spot it in Inki's tree, and it must be new since v4. Thanks, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- 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] iio: adc: exynos_adc: add support for s3c64xx adc
Chanwoo Choi schrieb:
From: Arnd Bergmann a...@arndb.de
The ADC in s3c64xx is almost the same as exynosv1, but
has a different 'select' method. Adding this here will be
helpful to move over the existing s3c64xx platform from the
legacy plat-samsung/adc driver to the new exynos-adc.
Signed-off-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
.../devicetree/bindings/arm/samsung/exynos-adc.txt | 2 ++
drivers/iio/adc/exynos_adc.c | 32
+-
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index 6d34891..b6e3989 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -16,6 +16,8 @@ Required properties:
future controllers.
Must be samsung,exynos3250-adc for
controllers compatible with ADC of Exynos3250.
+ Must be samsung,s3c6410-adc for
+ the ADC in s3c6410 and compatibles
- reg: Contains ADC register address range (base
address and
length) and the address of the phy enable register.
- interrupts:Contains the interrupt information for the
timer. The
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 87e0895..05bdd2f12 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -40,12 +40,16 @@
#include linux/iio/machine.h
#include linux/iio/driver.h
-/* EXYNOS4412/5250 ADC_V1 registers definitions */
+/* S3C/EXYNOS4412/5250 ADC_V1 registers definitions */
#define ADC_V1_CON(x)((x) + 0x00)
+#define ADC_V1_TSC(x)((x) + 0x04)
#define ADC_V1_DLY(x)((x) + 0x08)
#define ADC_V1_DATX(x) ((x) + 0x0C)
+#define ADC_V1_DATY(x) ((x) + 0x10)
+#define ADC_V1_UPDN(x) ((x) + 0x14)
#define ADC_V1_INTCLR(x) ((x) + 0x18)
#define ADC_V1_MUX(x)((x) + 0x1c)
+#define ADC_V1_CLRINTPNDNUP(x) ((x) + 0x20)
/* Future ADC_V2 registers definitions */
#define ADC_V2_CON1(x) ((x) + 0x00)
@@ -61,6 +65,9 @@
#define ADC_V1_CON_PRSCLV(x) (((x) 0xFF) 6)
#define ADC_V1_CON_STANDBY (1u 2)
+/* Bit definitions for S3C2410 ADC */
+#define ADC_S3C2410_CON_SELMUX(x) (((x) 7) 3)
There is a whitespace missing.
+
/* Bit definitions for ADC_V2 */
#define ADC_V2_CON1_SOFT_RESET (1u 2)
@@ -217,6 +224,26 @@ static const struct exynos_adc_data const
exynos_adc_v1_data = {
.start_conv = exynos_adc_v1_start_conv,
};
+static void exynos_adc_s3c64xx_start_conv(struct exynos_adc *info,
+ unsigned long addr)
+{
+ u32 con1;
+
+ con1 = readl(ADC_V1_CON(info-regs));
+ con1 = ~ADC_S3C2410_CON_SELMUX(7);
+ con1 |= ADC_S3C2410_CON_SELMUX(addr);
+ writel(con1 | ADC_CON_EN_START, ADC_V1_CON(info-regs));
+}
+
+static struct exynos_adc_data const exynos_adc_s3c64xx_data = {
+ .num_channels = MAX_ADC_V1_CHANNELS,
+
+ .init_hw= exynos_adc_v1_init_hw,
+ .exit_hw= exynos_adc_v1_exit_hw,
+ .clear_irq = exynos_adc_v1_clear_irq,
+ .start_conv = exynos_adc_s3c64xx_start_conv,
+};
+
static void exynos_adc_v2_init_hw(struct exynos_adc *info)
{
u32 con1, con2;
@@ -285,6 +312,9 @@ static const struct exynos_adc_data const
exynos3250_adc_data = {
static const struct of_device_id exynos_adc_match[] = {
{
+ .compatible = samsung,s3c6410-adc,
+ .data = exynos_adc_s3c64xx_data,
+ }, {
.compatible = samsung,exynos-adc-v1,
.data = exynos_adc_v1_data,
}, {
--
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] iio: adc: exynos_adc: Add support for S3C24xx ADC
Chanwoo Choi schrieb:
This patch add support for s3c2410/s3c2416/s3c2440/s3c2443 ADC. The s3c24xx
is alomost same as ADCv1. But, There are a little difference as following:
- ADCMUX register address to select channel
- ADCDAT mask (10bit or 12bit ADC resolution according to SoC version)
Hi, just some style issues: better separate things like 10bit with a space to
10 bit, there are some instances of this type in your code. Another issue
inline.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Arnd Bergmann a...@arndb.de
---
.../devicetree/bindings/arm/samsung/exynos-adc.txt | 10 ++-
drivers/iio/adc/exynos_adc.c | 89
+-
2 files changed, 96 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index b6e3989..fe34c76 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -11,11 +11,19 @@ New driver handles the following
Required properties:
- compatible:Must be samsung,exynos-adc-v1
- for exynos4412/5250 controllers.
+ for exynos4412/5250 and s5pv210 controllers.
Must be samsung,exynos-adc-v2 for
future controllers.
Must be samsung,exynos3250-adc for
controllers compatible with ADC of Exynos3250.
+ Must be samsung,s3c2410-adc for
+ the ADC in s3c2410 and compatibles
+ Must be samsung,s3c2416-adc for
+ the ADC in s3c2416 and compatibles
+ Must be samsung,s3c2440-adc for
+ the ADC in s3c2440 and compatibles
+ Must be samsung,s3c2443-adc for
+ the ADC in s3c2443 and compatibles
Must be samsung,s3c6410-adc for
the ADC in s3c6410 and compatibles
- reg: Contains ADC register address range (base
address and
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 05bdd2f12..7d28032 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -51,6 +51,9 @@
#define ADC_V1_MUX(x)((x) + 0x1c)
#define ADC_V1_CLRINTPNDNUP(x) ((x) + 0x20)
+/* S3C2410 ADC registers definitions */
+#define ADC_S3C2410_MUX(x) ((x) + 0x18)
+
/* Future ADC_V2 registers definitions */
#define ADC_V2_CON1(x) ((x) + 0x00)
#define ADC_V2_CON2(x) ((x) + 0x04)
@@ -67,6 +70,8 @@
/* Bit definitions for S3C2410 ADC */
#define ADC_S3C2410_CON_SELMUX(x) (((x) 7) 3)
+#define ADC_S3C2410_DATX_MASK0x3FF
+#define ADC_S3C2416_CON_RES_SEL (1 3)
Since it is done this way in this driver, better use (1u 3) here.
/* Bit definitions for ADC_V2 */
#define ADC_V2_CON1_SOFT_RESET (1u 2)
@@ -84,6 +89,7 @@
/* Bit definitions common for ADC_V1 and ADC_V2 */
#define ADC_CON_EN_START (1u 0)
+#define ADC_CON_EN_START_MASK(0x3 0)
#define ADC_DATX_MASK0xFFF
#define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
@@ -101,12 +107,14 @@ struct exynos_adc {
struct completion completion;
u32 value;
+ u32 value2;
unsigned intversion;
};
struct exynos_adc_data {
int num_channels;
bool needs_sclk;
+ u32 mask;
void (*init_hw)(struct exynos_adc *info);
void (*exit_hw)(struct exynos_adc *info);
@@ -217,6 +225,17 @@ static void exynos_adc_v1_start_conv(struct exynos_adc
*info,
static const struct exynos_adc_data const exynos_adc_v1_data = {
.num_channels = MAX_ADC_V1_CHANNELS,
+ .mask = ADC_DATX_MASK, /* 12bit ADC resolution */
+
+ .init_hw= exynos_adc_v1_init_hw,
+ .exit_hw= exynos_adc_v1_exit_hw,
+ .clear_irq = exynos_adc_v1_clear_irq,
+ .start_conv = exynos_adc_v1_start_conv,
+};
+
+static struct exynos_adc_data const exynos_adc_s3c24xx_data = {
+ .num_channels = MAX_ADC_V1_CHANNELS,
+ .mask = ADC_S3C2410_DATX_MASK, /* 10bit ADC resolution */
.init_hw= exynos_adc_v1_init_hw,
.exit_hw= exynos_adc_v1_exit_hw,
@@ -224,6 +243,55 @@ static const struct exynos_adc_data const
exynos_adc_v1_data = {
.start_conv = exynos_adc_v1_start_conv,
};
+static void exynos_adc_s3c2416_start_conv(struct exynos_adc *info,
+ unsigned long addr)
+{
+ u32 con1;
+
+ /* Enable 12bit ADC resolution */
+ con1 = readl(ADC_V1_CON(info-regs));
+
Re: [PATCH v2] iio: exynos-adc: add experimental touchscreen support
Arnd Bergmann schrieb:
This adds support for the touchscreen on Samsung s3c64xx.
The driver is completely untested but shows roughly how
it could be done, following the example of the at91 driver.
Open questions include:
- compared to the old plat-samsung/adc driver, there is
no support for prioritizing ts over other clients, nor
for oversampling. From my reading of the code, the
priorities didn't actually have any effect at all, but
the oversampling might be needed. Maybe the original
authors have some insight.
- We probably need to add support for platform_data as well,
I've skipped this so far.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
This should address all previous comments, and I've also added
a write to ADC_V1_DLY() as the old driver does.
Just two minor issues inline.
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index cad81b666a67..ba30836c73cb 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -43,6 +43,10 @@ Required properties:
and compatible ADC block)
- vdd-supply VDD input supply.
+Optional properties:
+- has-touchscreen: If present, indicates that a touchscreen is
+ connected an usable.
Typo: and
+
Note: child nodes can be added for auto probing from device tree.
Example: adding device info in dtsi file
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 420c5cda09c3..3b684a117b9c 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -34,6 +34,7 @@
#include linux/regulator/consumer.h
#include linux/of_platform.h
#include linux/err.h
+#include linux/input.h
#include linux/iio/iio.h
#include linux/iio/machine.h
@@ -66,6 +67,9 @@
#define ADC_S3C2410_CON_SELMUX(x) (((x)0x7)3)
+/* touch screen always uses channel 0 */
+#define ADC_S3C2410_MUX_TS 0
+
/* ADCTSC Register Bits */
#define ADC_S3C2443_TSC_UD_SEN (1u 8)
#define ADC_S3C2410_TSC_YM_SEN (1u 7)
@@ -103,24 +107,32 @@
/* Bit definitions common for ADC_V1 and ADC_V2 */
#define ADC_CON_EN_START (1u 0)
+#define ADC_DATX_PRESSED (1u 15)
#define ADC_DATX_MASK0xFFF
+#define ADC_DATY_MASK0xFFF
#define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
struct exynos_adc {
struct exynos_adc_data *data;
struct device *dev;
+ struct input_dev*input;
void __iomem*regs;
void __iomem*enable_reg;
struct clk *clk;
struct clk *sclk;
unsigned intirq;
+ unsigned inttsirq;
struct regulator*vdd;
struct completion completion;
u32 value;
unsigned intversion;
+
+ boolread_ts;
+ u32 ts_x;
+ u32 ts_y;
};
struct exynos_adc_data {
@@ -205,6 +217,9 @@ static void exynos_adc_v1_init_hw(struct exynos_adc *info)
/* Enable 12-bit ADC resolution */
con1 |= ADC_V1_CON_RES;
writel(con1, ADC_V1_CON(info-regs));
+
+ /* set default touchscreen delay */
Any information about how many µs/ms it is actually set with this value?
+ writel(1, ADC_V1_DLY(info-regs));
}
static void exynos_adc_v1_exit_hw(struct exynos_adc *info)
@@ -390,12 +405,54 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
return ret;
}
+static int exynos_read_s3c64xx_ts(struct iio_dev *indio_dev, int *x, int *y)
+{
+ struct exynos_adc *info = iio_priv(indio_dev);
+ unsigned long timeout;
+ int ret;
+
+ mutex_lock(indio_dev-mlock);
+ info-read_ts = true;
+
+ reinit_completion(info-completion);
+
+ writel(ADC_S3C2410_TSC_PULL_UP_DISABLE | ADC_TSC_AUTOPST,
+ADC_V1_TSC(info-regs));
+
+ /* Select the ts channel to be used and Trigger conversion */
+ info-data-start_conv(info, ADC_S3C2410_MUX_TS);
+
+ timeout = wait_for_completion_timeout
+ (info-completion, EXYNOS_ADC_TIMEOUT);
+ if (timeout == 0) {
+ dev_warn(indio_dev-dev, Conversion timed out! Resetting\n);
+ if (info-data-init_hw)
+ info-data-init_hw(info);
+ ret = -ETIMEDOUT;
+ } else {
+ *x = info-ts_x;
+ *y = info-ts_y;
+ ret = 0;
+ }
+
+ info-read_ts = false;
+ mutex_unlock(indio_dev-mlock);
+
+ return ret;
+}
+
static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
{
struct exynos_adc *info = (struct exynos_adc *)dev_id;
/* Read value */
- info-value =
Re: [PATCH v2] iio: exynos-adc: add experimental touchscreen support
Am Sonntag, 27. Juli 2014, 23:10:21 schrieb Hartmut Knaack: Arnd Bergmann schrieb: @@ -205,6 +217,9 @@ static void exynos_adc_v1_init_hw(struct exynos_adc *info) /* Enable 12-bit ADC resolution */ con1 |= ADC_V1_CON_RES; writel(con1, ADC_V1_CON(info-regs)); + + /* set default touchscreen delay */ Any information about how many µs/ms it is actually set with this value? ADC conversion is delayed by counting this value. Counting clock is pclk. So, I guess here 1 pclk ticks. Heiko + writel(1, ADC_V1_DLY(info-regs)); } -- 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: kgene's for-next branch broken, and boot regressions
Andreas Färber wrote: Hi Kukjin, Hi, Are you aware that `make dtbs` fails on your for-next branch (4533046)? DTC arch/arm/boot/dts/exynos5420-peach-pit.dtb arch/arm/boot/dts/exynos5420-peach-pit.dts:447:33: fatal error: cros-ec-keyboard.dtsi: No such file or directory #include cros-ec-keyboard.dtsi ^ compilation terminated. scripts/Makefile.lib:273: recipe for target 'arch/arm/boot/dts/exynos5420-peach-pit.dtb' failed make[1]: *** [arch/arm/boot/dts/exynos5420-peach-pit.dtb] Error 1 arch/arm/Makefile:314: recipe for target 'dtbs' failed make: *** [dtbs] Error 2 Oops, I always use my script to check kernel build like follow... $ mt building exynos_defconfig done building s3c2410_defconfig done building s3c6400_defconfig done building s5pv210_defconfig done but seems it couldn't detect the breakage from dtb :( On https://patchwork.kernel.org/patch/4297431/ Doug had pointed out that a topic branch merge would be needed for cros-ec-keyboard.dtsi (which I also pointed out for my spring series). Can you please fix this through some merge? Your affected branch is v3.17-next/dt-samsung with ARM: dts: Add cros_ec to exynos5420-peach-pit and exynos5800-peach-pi. There's a topic branch in the Tegra tree: http://git.kernel.org/cgit/linux/kernel/git/tegra/linux.git/log/?h=for-3.17/dt-cros-ec-kbd and it's been merged into arm-soc recently. https://git.kernel.org/cgit/linux/kernel/git/arm/arm-soc.git/tree/arch/arm/boot/dts?h=for-next Sure I'll fix it soon. Thanks for your report. - Kukjin Also, I've run into some boot regressions: On the Arndale Octa (5420) I see an asynchronous external abort on serial console when systemd gets started. http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34680.html On the Spring Chromebook (5250) the screen goes dark after a few lines, and USB is not initialized. Thus unclear to me why. On the ODROID-XU (with local patches based on smdk5410) I get the following with earlyprintk: Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.16.0-rc6+ (andreas@droide) (gcc version 4.8.2 20140404 [gcc-4_8-branch revision 209122] (SUSE Linux) ) #2 SMP PREEMPT Sun Jul 27 02:31:31 CEST 2014 [0.00] CPU: ARMv7 Processor [412fc0f3] revision 3 (ARMv7), cr=30c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] Machine model: ODROID-XU based on EXYNOS5410 [0.00] bootconsole [earlycon0] enabled [0.00] Forcing write-allocate cache policy for SMP [0.00] Memory policy: Data cache writealloc [0.00] Running under secure firmware. [0.00] PERCPU: Embedded 7 pages/cpu @ee7b3000 s7872 r8192 d12608 u32768 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 522256 [0.00] Kernel command line: console=ttySAC2,115200n8 earlyprintk root=/dev/mmcblk0p2 rootfstype=ext4 rw rootwait [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 2070984K/2095104K available (4364K kernel code, 271K rwdata, 1420K rodata, 271K init, 283K bss, 24120K reserved, 1316864K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xffc0 - 0xffe0 (2048 kB) [0.00] vmalloc : 0xf000 - 0xff00 ( 240 MB) [0.00] lowmem : 0xc000 - 0xef80 ( 760 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc05ae384 (5785 kB) [0.00] .init : 0xc05af000 - 0xc05f2ec0 ( 272 kB) [0.00] .data : 0xc05f4000 - 0xc0637d80 ( 272 kB) [0.00].bss : 0xc0637d8c - 0xc067eb00 ( 284 kB) [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [0.00] Preemptible hierarchical RCU implementation. [0.00] RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4. [0.00] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] GIC physical location is 0x10481000 [0.00] Kernel panic - not syncing: failed to find exynos pmu register [0.00] [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16.0-rc6+ #2 [0.00] [c0022214] (unwind_backtrace) from [c001f3b4] (show_stack+0x10/0x14) [0.00] [c001f3b4] (show_stack) from [c04204d4] (dump_stack+0x80/0xc0) [0.00] [c04204d4] (dump_stack) from [c041d9a4] (panic+0xa4/0x200) [0.00] [c041d9a4] (panic) from [c05b745c]
RE: [PATCH 0/3] ARM: EXYNOS: Fix Exynos5410 boot
Andreas Färber wrote: Am 27.07.2014 14:22, schrieb Andreas Färber: Hello, This mini-series unbreaks booting on 5410 based ODROID-XU. Since I do not have access to a TRM, the address is a guess based on 5250 and 5410. Such a node was not present in the 3.14 downstream tree. s/5410/5420/ OK. Regards, Andreas Andreas Färber (3): Documentation: devicetree: Document exynos5410 PMU ARM: dts: exynos: Add PMU to Exynos5410 ARM: EXYNOS: Add support for Exynos5410 PMU Documentation/devicetree/bindings/arm/samsung/pmu.txt | 1 + arch/arm/boot/dts/exynos5410.dtsi | 5 + arch/arm/mach-exynos/exynos.c | 1 + 3 files changed, 7 insertions(+) Andreas, thanks. I'll apply this whole series. - Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: kgene's for-next branch broken, and boot regressions
Andreas Färber wrote: Am 27.07.2014 05:08, schrieb Andreas Färber: On the ODROID-XU (with local patches based on smdk5410) I get the following with earlyprintk: Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.16.0-rc6+ (andreas@droide) (gcc version 4.8.2 20140404 [gcc-4_8-branch revision 209122] (SUSE Linux) ) #2 SMP PREEMPT Sun Jul 27 02:31:31 CEST 2014 [0.00] CPU: ARMv7 Processor [412fc0f3] revision 3 (ARMv7), cr=30c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] Machine model: ODROID-XU based on EXYNOS5410 [0.00] bootconsole [earlycon0] enabled [0.00] Forcing write-allocate cache policy for SMP [0.00] Memory policy: Data cache writealloc [0.00] Running under secure firmware. [0.00] PERCPU: Embedded 7 pages/cpu @ee7b3000 s7872 r8192 d12608 u32768 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 522256 [0.00] Kernel command line: console=ttySAC2,115200n8 earlyprintk root=/dev/mmcblk0p2 rootfstype=ext4 rw rootwait [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 2070984K/2095104K available (4364K kernel code, 271K rwdata, 1420K rodata, 271K init, 283K bss, 24120K reserved, 1316864K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xffc0 - 0xffe0 (2048 kB) [0.00] vmalloc : 0xf000 - 0xff00 ( 240 MB) [0.00] lowmem : 0xc000 - 0xef80 ( 760 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc05ae384 (5785 kB) [0.00] .init : 0xc05af000 - 0xc05f2ec0 ( 272 kB) [0.00] .data : 0xc05f4000 - 0xc0637d80 ( 272 kB) [0.00].bss : 0xc0637d8c - 0xc067eb00 ( 284 kB) [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [0.00] Preemptible hierarchical RCU implementation. [0.00] RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4. [0.00] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] GIC physical location is 0x10481000 [0.00] Kernel panic - not syncing: failed to find exynos pmu register [0.00] [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16.0-rc6+ #2 [0.00] [c0022214] (unwind_backtrace) from [c001f3b4] (show_stack+0x10/0x14) [0.00] [c001f3b4] (show_stack) from [c04204d4] (dump_stack+0x80/0xc0) [0.00] [c04204d4] (dump_stack) from [c041d9a4] (panic+0xa4/0x200) [0.00] [c041d9a4] (panic) from [c05b745c] (exynos_reserve+0x0/0x4c) [0.00] [c05b745c] (exynos_reserve) from [] ( (null)) [0.00] ---[ end Kernel panic - not syncing: failed to find exynos pmu register [0.00] Reverting ARM: EXYNOS: Refactored code for using PMU address via DT and ARM: EXYNOS: Add support for mapping PMU base address via DT fixed the latter. Adding a samsung,exynos5410-pmu system-controller node like on 5420 fixes this as well. Patchset being prepared. Thanks again ;) - Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] drm/mipi-dsi: support lpm (low power mode) transfer
This patch series adds lpm tranfer support for video and command data. for this, this patch adds two flags, and makes mipi dsi host to send commands to lcd panel device with lpm if mode_flags of lcd panel driver includes lpm flag. and also it applies this feature to exynos mipi dsi driver. Changelog v2: - Add more describtions. - Enable High Speed clock only in case of stand by request. Inki Dae (2): drm/mipi-dsi: add (LPM) Low Power Mode transfer support drm/exynos: dsi: add LPM (Low Power Mode) transfer support drivers/gpu/drm/drm_mipi_dsi.c |3 +++ drivers/gpu/drm/exynos/exynos_drm_dsi.c | 22 -- include/drm/drm_mipi_dsi.h |4 3 files changed, 27 insertions(+), 2 deletions(-) -- 1.7.9.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
[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
This patch adds below two flags for LPM transfer, and it attaches LPM flags
to a msg in accordance with master's mode_flags set by LCD Panel driver.
MIPI_DSI_MODE_CMD_LPM
- If this flag is set by Panel driver, MIPI-DSI controller will tranfer
command data to Panel device in Low Power Mode.
MIPI_DSI_MODE_VIDEO_LPM
- If this flag is set by Panel driver, MIPI-DSI controller will tranfer
image data to Panel device in Low Power Mode.
And above two flags can be combined together to transfer command and video
data to Panel device.
MIPI DSI spec says,
the host processor controls the desired mode of clock operation.
Host protocol and applications control Clock Lane operating mode
(High Speed or Low Power mode). System designers are responsible
for understanding the clock requirements for peripherals attached
to DSI and controlling clock behavior in accordance with those
requirements.
Some LCD Panel devices, nt35502a, would need LPM transfer support
because they should receive some initial commands with LPM by default
hardware setting.
Changelog v2: just add more descriptions.
Signed-off-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/drm_mipi_dsi.c |3 +++
include/drm/drm_mipi_dsi.h |4
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index e633df2..6b2bbda 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -232,6 +232,9 @@ int mipi_dsi_dcs_write(struct mipi_dsi_device *dsi,
unsigned int channel,
break;
}
+ if (dsi-mode_flags MIPI_DSI_MODE_CMD_LPM)
+ msg.flags = MIPI_DSI_MSG_USE_LPM;
+
return ops-transfer(dsi-host, msg);
}
EXPORT_SYMBOL(mipi_dsi_dcs_write);
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 944f33f..1c41e49 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -94,6 +94,10 @@ void mipi_dsi_host_unregister(struct mipi_dsi_host *host);
#define MIPI_DSI_MODE_VSYNC_FLUSH BIT(8)
/* disable EoT packets in HS mode */
#define MIPI_DSI_MODE_EOT_PACKET BIT(9)
+/* command low power mode */
+#define MIPI_DSI_MODE_CMD_LPM BIT(10)
+/* video low power mode */
+#define MIPI_DSI_MODE_VIDEO_LPMBIT(11)
enum mipi_dsi_pixel_format {
MIPI_DSI_FMT_RGB888,
--
1.7.9.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
[PATCH v2 2/2] drm/exynos: dsi: add LPM (Low Power Mode) transfer support
This patch adds LPM transfer support for video or command data.
With this patch, Exynos MIPI DSI controller can transfer command or
video data with HS or LP mode in accordance with mode_flags set
by LCD Panel driver.
Changelog v2: Enable High Speed clock only in case of stand by request.
Signed-off-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 5e78d45..1bed105 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -493,8 +493,11 @@ static int exynos_dsi_enable_clock(struct exynos_dsi *dsi)
| DSIM_ESC_PRESCALER(esc_div)
| DSIM_LANE_ESC_CLK_EN_CLK
| DSIM_LANE_ESC_CLK_EN_DATA(BIT(dsi-lanes) - 1)
- | DSIM_BYTE_CLK_SRC(0)
- | DSIM_TX_REQUEST_HSCLK;
+ | DSIM_BYTE_CLK_SRC(0);
+
+ if (!(dsi-mode_flags MIPI_DSI_MODE_CMD_LPM))
+ reg |= DSIM_TX_REQUEST_HSCLK;
+
writel(reg, dsi-reg_base + DSIM_CLKCTRL_REG);
return 0;
@@ -553,6 +556,18 @@ static void exynos_dsi_set_phy_ctrl(struct exynos_dsi *dsi)
writel(reg, dsi-reg_base + DSIM_PHYTIMING2_REG);
}
+static void exynos_dsi_enable_hs_clock(struct exynos_dsi *dsi,
+ bool enable)
+{
+ u32 reg = readl(dsi-reg_base + DSIM_CLKCTRL_REG);
+
+ reg = ~DSIM_TX_REQUEST_HSCLK;
+ if (enable)
+ reg |= DSIM_TX_REQUEST_HSCLK;
+
+ writel(reg, dsi-reg_base + DSIM_CLKCTRL_REG);
+}
+
static void exynos_dsi_disable_clock(struct exynos_dsi *dsi)
{
u32 reg;
@@ -705,6 +720,9 @@ static void exynos_dsi_set_display_enable(struct exynos_dsi
*dsi, bool enable)
{
u32 reg;
+ if (!(dsi-mode_flags MIPI_DSI_MODE_VIDEO_LPM) enable)
+ exynos_dsi_enable_hs_clock(dsi, true);
+
reg = readl(dsi-reg_base + DSIM_MDRESOL_REG);
if (enable)
reg |= DSIM_MAIN_STAND_BY;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6 1/5] mmc: dw_mmc: modify the dt-binding for removing slot-node and supports-highspeed
Hi, Andreas,
On 07/25/2014 09:11 PM, Andreas Färber wrote:
Hi Jaehoon,
Am 25.07.2014 03:11, schrieb Jaehoon Chung:
Almost Soc is used the slot per a host.
Something's very wrong with this sentence. What are you trying to say?
Almost all SoCs use one slot only per host controller device?
If you are confusion for this sentence, sorry.
It means that we recommend only one slot per host controller.
Some controller can be supported the multiple slot per a host controller.
But i didn't find anywhere it used the multiple slot per a host controller.
Best Regards,
Jaehoon Chung
Don't use the slot-node and deprecated the supports-highsped property.
s/deprecated/deprecate/ ?
s/highsped/highspeed/
Instead, use the cap-mmc/sd-highspeed.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Reviewed-by: Tushar Behera trbli...@gmail.com
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
Tested-by: Sachin Kamat sachin.ka...@samsung.com
Acked-by: Seungwon Jeon tgih@samsung.com
---
.../devicetree/bindings/mmc/exynos-dw-mshc.txt | 17 +
.../devicetree/bindings/mmc/k3-dw-mshc.txt | 12 +---
.../devicetree/bindings/mmc/synopsys-dw-mshc.txt | 12 +---
3 files changed, 15 insertions(+), 26 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
index 532b1d4..9308325 100644
--- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
@@ -46,13 +46,14 @@ Required Properties:
- if CIU clock divider value is 0 (that is divide by 1), both tx and
rx
phase shift clocks should be 0.
-Required properties for a slot:
+Required properties for a slot (Deprecated - Recommend to use one slot per
a host):
per host
* 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.
+ (Deprecated - Refer to
Documentaion/devicetree/binding/pinctrl/samsung-pinctrl.txt)
Documentation/
Nit: Is the indentation intentional? (parenthesis not aligned with text)
Example:
@@ -69,21 +70,13 @@ Example:
dwmmc0@1220 {
num-slots = 1;
-supports-highspeed;
+cap-mmc-highspeed;
+cap-sd-highspeed;
broken-cd;
fifo-depth = 0x80;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
samsung,dw-mshc-ddr-timing = 1 2;
-
-slot@0 {
-reg = 0;
-bus-width = 8;
-gpios = gpc0 0 2 0 3, gpc0 1 2 0 3,
-gpc1 0 2 3 3, gpc1 1 2 3 3,
-gpc1 2 2 3 3, gpc1 3 2 3 3,
-gpc0 3 2 3 3, gpc0 4 2 3 3,
-gpc0 5 2 3 3, gpc0 6 2 3 3;
-};
+bus-width = 8;
};
diff --git a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
index e5bc49f..3b35449 100644
--- a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
@@ -34,13 +34,11 @@ Example:
num-slots = 1;
vmmc-supply = ldo12;
fifo-depth = 0x100;
-supports-highspeed;
pinctrl-names = default;
pinctrl-0 = sd_pmx_pins sd_cfg_func1 sd_cfg_func2;
-slot@0 {
-reg = 0;
-bus-width = 4;
-disable-wp;
-cd-gpios = gpio10 3 0;
-};
+bus-width = 4;
+disable-wp;
+cd-gpios = gpio10 3 0;
+cap-mmc-highspeed;
+cap-sd-highspeed;
};
diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
index 2d4a725..346c609 100644
--- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
@@ -67,7 +67,8 @@ Optional properties:
* 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 (up to 50MHz)
+* supports-highspeed (DEPRECATED): Enables support for high speed cards (up
to 50MHz)
+ (use cap-mmc-highspeed or cap-sd-highspeed
instead)
* broken-cd: as documented in mmc core bindings.
@@ -98,14 +99,11 @@ board specific portions as listed
[PATCHv7 3/5] ARM: dts: socfpga: unuse the slot-node and deprecated the supports-highspeed for dw-mmc
dw-mmc controller can support multiple slots.
But, there are no use-cases anywhere. So we don't need to support the
slot-node for dw-mmc controller.
And supports-highspeed property in dw-mmc is deprecated.
supports-highspeed property can be replaced to cap-sd/mmc-highspeed.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Reviewed-by: Tushar Behera trbli...@gmail.com
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
Acked-by: Seungwon Jeon tgih@samsung.com
Acked-by: Dinh Nguyen dingu...@altera.com
---
arch/arm/boot/dts/socfpga_arria5.dtsi |9 +++--
arch/arm/boot/dts/socfpga_cyclone5.dtsi |9 +++--
arch/arm/boot/dts/socfpga_vt.dts|9 +++--
3 files changed, 9 insertions(+), 18 deletions(-)
diff --git a/arch/arm/boot/dts/socfpga_arria5.dtsi
b/arch/arm/boot/dts/socfpga_arria5.dtsi
index 12d1c2c..468fc4c 100644
--- a/arch/arm/boot/dts/socfpga_arria5.dtsi
+++ b/arch/arm/boot/dts/socfpga_arria5.dtsi
@@ -29,13 +29,10 @@
dwmmc0@ff704000 {
num-slots = 1;
- supports-highspeed;
broken-cd;
-
- slot@0 {
- reg = 0;
- bus-width = 4;
- };
+ bus-width = 4;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
};
sysmgr@ffd08000 {
diff --git a/arch/arm/boot/dts/socfpga_cyclone5.dtsi
b/arch/arm/boot/dts/socfpga_cyclone5.dtsi
index bf51182..1ee03c4 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5.dtsi
+++ b/arch/arm/boot/dts/socfpga_cyclone5.dtsi
@@ -30,13 +30,10 @@
dwmmc0@ff704000 {
num-slots = 1;
- supports-highspeed;
broken-cd;
-
- slot@0 {
- reg = 0;
- bus-width = 4;
- };
+ bus-width = 4;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
};
ethernet@ff702000 {
diff --git a/arch/arm/boot/dts/socfpga_vt.dts b/arch/arm/boot/dts/socfpga_vt.dts
index 09792b4..f9345e0 100644
--- a/arch/arm/boot/dts/socfpga_vt.dts
+++ b/arch/arm/boot/dts/socfpga_vt.dts
@@ -43,13 +43,10 @@
dwmmc0@ff704000 {
num-slots = 1;
- supports-highspeed;
broken-cd;
-
- slot@0 {
- reg = 0;
- bus-width = 4;
- };
+ bus-width = 4;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
};
ethernet@ff70 {
--
1.7.9.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
[PATCHv7 4/5] ARM: dts: rockchip: unuse the slot-node and deprecated the supports-highspeed for dw-mmc
dw-mmc controller can support multiple slots.
But, there are no use-cases anywhere. So we don't need to support the
slot-node for dw-mmc controller.
And supports-highspeed property in dw-mmc is deprecated.
supports-highspeed property can be replaced to cap-sd/mmc-highspeed.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Reviewed-by: Tushar Behera trbli...@gmail.com
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
Reviewed-by: Heiko Stuebner he...@sntech.de
Acked-by: Seungwon Jeon tgih@samsung.com
---
arch/arm/boot/dts/rk3066a-bqcurie2.dts | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/rk3066a-bqcurie2.dts
b/arch/arm/boot/dts/rk3066a-bqcurie2.dts
index afb3273..ecea889 100644
--- a/arch/arm/boot/dts/rk3066a-bqcurie2.dts
+++ b/arch/arm/boot/dts/rk3066a-bqcurie2.dts
@@ -59,12 +59,8 @@
pinctrl-names = default;
pinctrl-0 = sd0_clk sd0_cmd sd0_cd sd0_bus4;
vmmc-supply = vcc_sd0;
-
- slot@0 {
- reg = 0;
- bus-width = 4;
- disable-wp;
- };
+ bus-width = 4;
+ disable-wp;
};
dwmmc@10218000 { /* wifi */
@@ -74,12 +70,8 @@
pinctrl-names = default;
pinctrl-0 = sd1_clk sd1_cmd sd1_bus4;
-
- slot@0 {
- reg = 0;
- bus-width = 4;
- disable-wp;
- };
+ bus-width = 4;
+ disable-wp;
};
gpio-keys {
--
1.7.9.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
[PATCHv7 1/5] mmc: dw_mmc: modify the dt-binding for removing slot-node and supports-highspeed
Almost SoCs use one slot per host controller.
(Even if controller can support the multiple slot, Recommend to use one slot
per host controller.)
Don't use the slot-node and deprecate the supports-highspeed property.
Instead, use the cap-mmc/sd-highspeed.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Reviewed-by: Tushar Behera trbli...@gmail.com
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
Tested-by: Sachin Kamat sachin.ka...@samsung.com
Acked-by: Seungwon Jeon tgih@samsung.com
---
.../devicetree/bindings/mmc/exynos-dw-mshc.txt | 17 +
.../devicetree/bindings/mmc/k3-dw-mshc.txt | 12 +---
.../devicetree/bindings/mmc/synopsys-dw-mshc.txt | 12 +---
3 files changed, 15 insertions(+), 26 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
index 532b1d4..6cd3525 100644
--- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
@@ -46,13 +46,14 @@ Required Properties:
- if CIU clock divider value is 0 (that is divide by 1), both tx and rx
phase shift clocks should be 0.
-Required properties for a slot:
+Required properties for a slot (Deprecated - Recommend to use one slot per
host):
* 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.
+(Deprecated - Refer to
Documentation/devicetree/binding/pinctrl/samsung-pinctrl.txt)
Example:
@@ -69,21 +70,13 @@ Example:
dwmmc0@1220 {
num-slots = 1;
- supports-highspeed;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
broken-cd;
fifo-depth = 0x80;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
samsung,dw-mshc-ddr-timing = 1 2;
-
- slot@0 {
- reg = 0;
- bus-width = 8;
- gpios = gpc0 0 2 0 3, gpc0 1 2 0 3,
- gpc1 0 2 3 3, gpc1 1 2 3 3,
- gpc1 2 2 3 3, gpc1 3 2 3 3,
- gpc0 3 2 3 3, gpc0 4 2 3 3,
- gpc0 5 2 3 3, gpc0 6 2 3 3;
- };
+ bus-width = 8;
};
diff --git a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
index e5bc49f..3b35449 100644
--- a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
@@ -34,13 +34,11 @@ Example:
num-slots = 1;
vmmc-supply = ldo12;
fifo-depth = 0x100;
- supports-highspeed;
pinctrl-names = default;
pinctrl-0 = sd_pmx_pins sd_cfg_func1 sd_cfg_func2;
- slot@0 {
- reg = 0;
- bus-width = 4;
- disable-wp;
- cd-gpios = gpio10 3 0;
- };
+ bus-width = 4;
+ disable-wp;
+ cd-gpios = gpio10 3 0;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
};
diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
index 2d4a725..346c609 100644
--- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
@@ -67,7 +67,8 @@ Optional properties:
* 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 (up to 50MHz)
+* supports-highspeed (DEPRECATED): Enables support for high speed cards (up to
50MHz)
+ (use cap-mmc-highspeed or cap-sd-highspeed
instead)
* broken-cd: as documented in mmc core bindings.
@@ -98,14 +99,11 @@ board specific portions as listed below.
clock-frequency = 4;
clock-freq-min-max = 40 2;
num-slots = 1;
- supports-highspeed;
broken-cd;
fifo-depth = 0x80;
card-detect-delay = 200;
vmmc-supply = buck8;
-
- slot@0 {
- reg = 0;
- bus-width = 8;
- };
+ bus-width = 8;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
};
--
1.7.9.5
--
To unsubscribe from this list: send
[PATCHv7 0/5] ARM: remove the sub-node and deprecate supports-highspeed property for dwmmc.
Since used the mmc_of_parse(), didn't parse the sub-node. So we can remove the sub-node, because almost SoC used the only one card per a host. And supports-highspeed can be replaced to cap-mmc/sd-highspeed property. Chnagelog V7: - Fixed typo and modified the commit message. Changelog V6: - Fixed Wrong bit control for host's quirks and rename. - Add Acked-by for each SoC maintainers. Changelog V5: - Rebased on v3.16-rc4. - Add Acked-by. Changelog V4: - Fix the checkpatch error. Changelog V3: - Fix the wrong bus-width value. - Use the slot-host-quirks instead of brq-quirks. - Add tested-by and reviewd-by. Changelog V2: - Add the mmc: dw_mmc: replace disable-wp from slot's quirks to host's quirk Jaehoon Chung (5): mmc: dw_mmc: modify the dt-binding for removing slot-node and supports-highspeed ARM: dts: exynos: unuse the slot-node and deprecated the supports-highspeed for dw-mmc ARM: dts: socfpga: unuse the slot-node and deprecated the supports-highspeed for dw-mmc ARM: dts: rockchip: unuse the slot-node and deprecated the supports-highspeed for dw-mmc mmc: dw_mmc: replace disable-wp from slot's quirk to host's quirk .../devicetree/bindings/mmc/exynos-dw-mshc.txt | 17 - .../devicetree/bindings/mmc/k3-dw-mshc.txt | 12 - .../devicetree/bindings/mmc/synopsys-dw-mshc.txt | 12 - arch/arm/boot/dts/exynos4412-odroidx.dts |8 ++ arch/arm/boot/dts/exynos4412-origen.dts|8 ++ arch/arm/boot/dts/exynos4412-trats2.dts|8 ++ arch/arm/boot/dts/exynos5250-arndale.dts | 18 -- arch/arm/boot/dts/exynos5250-cros-common.dtsi | 26 ++-- arch/arm/boot/dts/exynos5250-smdk5250.dts | 18 -- arch/arm/boot/dts/exynos5250-snow.dts |6 ++--- arch/arm/boot/dts/exynos5260-xyref5260.dts | 18 -- arch/arm/boot/dts/exynos5410-smdk5410.dts | 18 -- arch/arm/boot/dts/exynos5420-arndale-octa.dts | 16 +++- arch/arm/boot/dts/exynos5420-peach-pit.dts | 16 +++- arch/arm/boot/dts/exynos5420-smdk5420.dts | 16 +++- arch/arm/boot/dts/exynos5800-peach-pi.dts | 16 +++- arch/arm/boot/dts/rk3066a-bqcurie2.dts | 16 +++- arch/arm/boot/dts/socfpga_arria5.dtsi |9 +++ arch/arm/boot/dts/socfpga_cyclone5.dtsi|9 +++ arch/arm/boot/dts/socfpga_vt.dts |9 +++ drivers/mmc/host/dw_mmc.c | 12 - include/linux/mmc/dw_mmc.h |6 ++--- 22 files changed, 86 insertions(+), 208 deletions(-) -- 1.7.9.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
[PATCHv7 2/5] ARM: dts: exynos: unuse the slot-node and deprecated the supports-highspeed for dw-mmc
dw-mmc controller can support multiple slots.
But, there are no use-cases anywhere. So we don't need to support the
slot-node for dw-mmc controller.
And supports-highspeed property in dw-mmc is deprecated.
supports-highspeed property can be replaced to cap-sd/mmc-highspeed.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Reviewed-by: Tushar Behera trbli...@gmail.com
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
Tested-by: Sachin Kamat sachin.ka...@samsung.com
Acked-by: Seungwon Jeon tgih@samsung.com
Acked-by: Kukjin Kim kgene@samsung.com
---
arch/arm/boot/dts/exynos4412-odroidx.dts |8 ++--
arch/arm/boot/dts/exynos4412-origen.dts |8 ++--
arch/arm/boot/dts/exynos4412-trats2.dts |8 ++--
arch/arm/boot/dts/exynos5250-arndale.dts | 18 +
arch/arm/boot/dts/exynos5250-cros-common.dtsi | 26 +++--
arch/arm/boot/dts/exynos5250-smdk5250.dts | 18 +
arch/arm/boot/dts/exynos5250-snow.dts |6 ++
arch/arm/boot/dts/exynos5260-xyref5260.dts| 18 +
arch/arm/boot/dts/exynos5410-smdk5410.dts | 18 +
arch/arm/boot/dts/exynos5420-arndale-octa.dts | 16 ---
arch/arm/boot/dts/exynos5420-peach-pit.dts| 16 ---
arch/arm/boot/dts/exynos5420-smdk5420.dts | 16 ---
arch/arm/boot/dts/exynos5800-peach-pi.dts | 16 ---
13 files changed, 51 insertions(+), 141 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts
b/arch/arm/boot/dts/exynos4412-odroidx.dts
index 31db28a..778aec6 100644
--- a/arch/arm/boot/dts/exynos4412-odroidx.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -45,17 +45,13 @@
status = okay;
num-slots = 1;
- supports-highspeed;
broken-cd;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
samsung,dw-mshc-ddr-timing = 1 2;
-
- slot@0 {
- reg = 0;
- bus-width = 8;
- };
+ bus-width = 8;
+ cap-mmc-highspeed;
};
regulator_p3v3 {
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts
b/arch/arm/boot/dts/exynos4412-origen.dts
index e925c9f..de15114 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -137,17 +137,13 @@
status = okay;
num-slots = 1;
- supports-highspeed;
broken-cd;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
samsung,dw-mshc-ddr-timing = 1 2;
-
- slot@0 {
- reg = 0;
- bus-width = 8;
- };
+ bus-width = 8;
+ cap-mmc-highspeed;
};
codec@1340 {
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 7787844..65ab885 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -520,7 +520,6 @@
mmc@1255 {
num-slots = 1;
- supports-highspeed;
broken-cd;
non-removable;
card-detect-delay = 200;
@@ -532,11 +531,8 @@
pinctrl-0 = sd4_clk sd4_cmd sd4_bus4 sd4_bus8;
pinctrl-names = default;
status = okay;
-
- slot@0 {
- reg = 0;
- bus-width = 8;
- };
+ bus-width = 8;
+ cap-mmc-highspeed;
};
serial@1380 {
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index d0de1f5..42a3590 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -401,7 +401,6 @@
mmc_0: mmc@1220 {
status = okay;
num-slots = 1;
- supports-highspeed;
broken-cd;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
@@ -410,17 +409,13 @@
vmmc-supply = mmc_reg;
pinctrl-names = default;
pinctrl-0 = sd0_clk sd0_cmd sd0_bus4 sd0_bus8;
-
- slot@0 {
- reg = 0;
- bus-width = 8;
- };
+ bus-width = 8;
+ cap-mmc-highspeed;
};
mmc_2: mmc@1222 {
status = okay;
num-slots = 1;
- supports-highspeed;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
@@ -428,12
[PATCHv7 5/5] mmc: dw_mmc: replace disable-wp from slot's quirk to host's quirk
Replaced the disable-wp into host's quirks.
(Because the slot-node is removed at dt-file.)
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Tested-by: Sachin Kamat sachin.ka...@samsung.com
Acked-by: Seungwon Jeon tgih@samsung.com
---
drivers/mmc/host/dw_mmc.c | 12 +---
include/linux/mmc/dw_mmc.h |6 ++
2 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 1ac227c..4a4f66f 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -997,7 +997,7 @@ static int dw_mci_get_ro(struct mmc_host *mmc)
int gpio_ro = mmc_gpio_get_ro(mmc);
/* Use platform get_ro function, else try on board write protect */
- if (slot-quirks DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT)
+ if (slot-host-quirks DW_MCI_QUIRK_NO_WRITE_PROTECT)
read_only = 0;
else if (!IS_ERR_VALUE(gpio_ro))
read_only = gpio_ro;
@@ -2006,12 +2006,7 @@ static struct device_node
*dw_mci_of_find_slot_node(struct device *dev, u8 slot)
static struct dw_mci_of_slot_quirks {
char *quirk;
int id;
-} of_slot_quirks[] = {
- {
- .quirk = disable-wp,
- .id = DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT,
- },
-};
+} of_slot_quirks[] = {};
static int dw_mci_of_get_slot_quirks(struct device *dev, u8 slot)
{
@@ -2238,6 +2233,9 @@ static struct dw_mci_of_quirks {
{
.quirk = broken-cd,
.id = DW_MCI_QUIRK_BROKEN_CARD_DETECTION,
+ }, {
+ .quirk = disable-wp,
+ .id = DW_MCI_QUIRK_NO_WRITE_PROTECT,
},
};
diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
index babaea9..8b4b2d8 100644
--- a/include/linux/mmc/dw_mmc.h
+++ b/include/linux/mmc/dw_mmc.h
@@ -213,10 +213,8 @@ struct dw_mci_dma_ops {
#define DW_MCI_QUIRK_HIGHSPEED BIT(2)
/* Unreliable card detection */
#define DW_MCI_QUIRK_BROKEN_CARD_DETECTION BIT(3)
-
-/* Slot level quirks */
-/* This slot has no write protect */
-#define DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT BIT(0)
+/* No write protect */
+#define DW_MCI_QUIRK_NO_WRITE_PROTECT BIT(4)
struct dma_pdata;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v7 3/4] ARM: EXYNOS: Add platform driver support for Exynos PMU
Hi Tomasz, On Friday, July 25, 2014 Tomasz Figa wrote: To: Pankaj Dubey; 'Kukjin Kim'; linux-arm-ker...@lists.infradead.org; linux- samsung-...@vger.kernel.org; linux-ker...@vger.kernel.org Cc: li...@arm.linux.org.uk; t.f...@samsung.com; vikas.saj...@samsung.com; jo...@samsung.com; naus...@samsung.com; thomas...@samsung.com; chow@samsung.com Subject: Re: [PATCH v7 3/4] ARM: EXYNOS: Add platform driver support for Exynos PMU Hi Pankaj, Kukjin, On 25.07.2014 07:32, Pankaj Dubey wrote: Hi Kukjin, On Friday, July 25, 2014 Kukjin Kim wrote: [snip] Looks good to me, will apply this and 4/4. We need to hold these two patches until dependent patch [1] from Tomasz Figa gets merged. [1]: mfd: syscon: Decouple syscon interface from syscon devices https://lkml.org/lkml/2014/6/24/188 That RFC patch had few comments from Arnd needed to be addressed, so it needs a new revision. Pankaj, If I remember correctly, we had talked about this and the conclusion was that you would take care of addressing the comments and sending new version of the patch. Any update on this or have I missed something? Well, I don't think we concluded as such anything. Since this patch needs to get in so that Exynos PMU and PM related changes can go in, I discussed with you saying that I am not able to understand about Arnd's comments and if possible and time permits I will look into it. Meanwhile I got busy with some other official work, so could not get time to look into it. Best regards, Tomasz -- 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: kgene's for-next branch broken, and boot regressions
Kukjin, On Sun, Jul 27, 2014 at 5:30 PM, Kukjin Kim kgene@samsung.com wrote: Oops, I always use my script to check kernel build like follow... $ mt building exynos_defconfig done building s3c2410_defconfig done building s3c6400_defconfig done building s5pv210_defconfig done but seems it couldn't detect the breakage from dtb :( Could you add a make dtbs in there? Is there any chance you could get a boot farm on this, or somehow try to piggyback on Olof's or Kevin's boot farms (assuming they are willing to build/boot your branch on relevant hardware)? -Doug -- 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: kgene's for-next branch broken, and boot regressions
On Sun, Jul 27, 2014 at 8:30 PM, Doug Anderson diand...@chromium.org wrote: Kukjin, On Sun, Jul 27, 2014 at 5:30 PM, Kukjin Kim kgene@samsung.com wrote: Oops, I always use my script to check kernel build like follow... $ mt building exynos_defconfig done building s3c2410_defconfig done building s3c6400_defconfig done building s5pv210_defconfig done but seems it couldn't detect the breakage from dtb :( Could you add a make dtbs in there? Is there any chance you could get a boot farm on this, or somehow try to piggyback on Olof's or Kevin's boot farms (assuming they are willing to build/boot your branch on relevant hardware)? I boot -next on the farm, and it had found the 5410 issues, which I forwarded on to some of the relevant parties (but maybe not all). I don't have any 5410 hardware so I couldn't bisect the problem and narrow it down to a single patch. Hardware currently in there is 4412 (ODROID-U3), 5250 (Arndale and Snow), 5420 and 5800 (Pit/Pi). I have a 6410-based board that I have not yet hooked up. I also boot arm-soc's for-next branch, so as soon as we merge something in I'll notice breakage, if it's somehow masked by other parts of linux-next (i.e. dependent but not described driver changes, etc). -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
RE: [PATCH RFC] mfd: syscon: Decouple syscon interface from syscon devices
Hi Arnd, On Wednesday, June 18, 2014 Arnd wrote: To: Tomasz Figa Cc: linux-arm-ker...@lists.infradead.org; mark.br...@linaro.org; Tomasz Figa; linux-samsung-soc@vger.kernel.org; Kukjin Kim; Russell King - ARM Linux; Samuel Ortiz; Pankaj Dubey; linux-ker...@vger.kernel.org; jo...@samsung.com; vikas.saj...@samsung.com; chow@samsung.com; Lee Jones Subject: Re: [PATCH RFC] mfd: syscon: Decouple syscon interface from syscon devices On Tuesday 17 June 2014 23:26:22 Tomasz Figa wrote: On 17.06.2014 17:42, Arnd Bergmann wrote: This seems like a reasonable way of solving the problem, but I think there is an even better one that we have about in the past: if we promote syscon from a platform driver into a a drivers/base/ helper that is independent of the platform device matching, we can use call syscon_regmap_lookup_* for any device node, whether it's already bound to a driver or not, which do what you need. It would also make it easier to call the syscon code before the platform_device infrastructure gets initialized, which is something a number of people have asked for, e.g. for using regmap to do SMP bringup or for clock registration. Basically, unless I'm missing your point, this is what my patch does, except that I don't move it to drivers/base/ and the registration function I added require a pointer to struct device. Indeed, decoupling it further from the driver model, by adding of_syscon_register() should be useful for early users. I believe the part you are missing is that with the approach I suggested, there would be no registration function at all. You can easily do the lookup from the client drivers using the DT data structures, with no need for the device at all. Will you please elaborate more on this? The only exception today is the clps711x platform using syscon_regmap_lookup_by_pdevname(), but that should be solved in 3.17 when clps711x becomes DT-only. Does it mean that this may become a blocking issue for this patch to go before 3.17? If yes, isn't it will be good to accept this patch as it is if it's not causing issue or breaking anything with existing users of syscon. At least for our use of converting Exynos PMU and PM related consolidation this change is working fine and we have verified it. Should I move this to drivers/base/, even though from current location it can be used outside the platform driver anyway? Thinking about it some more, drivers/of might be better than drivers/base. It depends a bit where we are heading with this, in particular if we expect to see non- DT users in the future. Arnd Thanks, Pankaj Dubey -- 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: kgene's for-next branch broken, and boot regressions
On Sun, Jul 27, 2014 at 8:44 PM, Olof Johansson o...@lixom.net wrote: On Sun, Jul 27, 2014 at 8:30 PM, Doug Anderson diand...@chromium.org wrote: Kukjin, On Sun, Jul 27, 2014 at 5:30 PM, Kukjin Kim kgene@samsung.com wrote: Oops, I always use my script to check kernel build like follow... $ mt building exynos_defconfig done building s3c2410_defconfig done building s3c6400_defconfig done building s5pv210_defconfig done but seems it couldn't detect the breakage from dtb :( Could you add a make dtbs in there? Is there any chance you could get a boot farm on this, or somehow try to piggyback on Olof's or Kevin's boot farms (assuming they are willing to build/boot your branch on relevant hardware)? I boot -next on the farm, and it had found the 5410 issues, which I forwarded on to some of the relevant parties (but maybe not all). I don't have any 5410 hardware so I couldn't bisect the problem and narrow it down to a single patch. Obviously those two sentences are contradictory, and it was indeed Kevin that found the issues with his boards, not me. -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
