Re: [PATCH v2 10/10] mfd: cros_ec: move EC interrupt to cros_ec_keyb
On 18 June 2014 12:14, Doug Anderson wrote: > From: Andrew Bresticker > > If we receive EC interrupts after the cros_ec driver has probed, but > before the cros_ec_keyb driver has probed, the cros_ec IRQ handler > will not run the cros_ec_keyb notifier and the EC will leave the IRQ > line asserted. The cros_ec IRQ handler then returns IRQ_HANDLED and > the resulting flood of interrupts causes the machine to hang. > > Since the EC interrupt is currently only used for the keyboard, move > the setup and handling of the EC interrupt to the cros_ec_keyb driver. > > Signed-off-by: Andrew Bresticker > Signed-off-by: Doug Anderson Reviewed-by: Simon Glass We never needed an EC-level interrupt, and have shipped at least three products now that use this code, so I think it is safe enough to declare that we won't need it. Regards, Simon -- 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 08/10] mfd: cros_ec: Check result code from EC messages
On 18 June 2014 12:14, Doug Anderson wrote: > From: Bill Richardson > > Just because the host was able to talk to the EC doesn't mean that the EC > was happy with what it was told. Errors in communincation are not the same > as error messages from the EC itself. > > This change lets the EC report its errors separately. > > [dianders: Added common function to cros_ec.c] > > Signed-off-by: Bill Richardson > Signed-off-by: Doug Anderson This is better. Reviewed-by: Simon Glass -- 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 05/10] mfd: cros_ec: Use struct cros_ec_command to communicate with the EC
On 18 June 2014 12:14, Doug Anderson wrote: > From: Bill Richardson > > This is some internal structure reorganization / renaming to prepare > for future patches that will add a userspace API to cros_ec. There > should be no visible changes. > > Signed-off-by: Bill Richardson > Signed-off-by: Doug Anderson > Acked-by: Lee Jones Reviewed-by: Simon Glass -- 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: MMC error on Exynos4210 board
On Thu, Jun 19, 2014 at 6:11 PM, Jaehoon Chung wrote: > On 06/19/2014 07:40 PM, Sachin Kamat wrote: >> On Thu, Jun 19, 2014 at 2:40 PM, Tim Kryger wrote: >>> On Thu, Jun 19, 2014 at 1:49 AM, Sachin Kamat wrote: +cc Some relevant guys from Samsung On Thu, Jun 19, 2014 at 2:12 PM, Tim Kryger wrote: > On Wed, Jun 18, 2014 at 8:54 PM, Sachin Kamat wrote: > >>> On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat >>> wrote: > I see the below error on Exynos4210 based Origen board with linux-next (20140618). Reverting the below commit works fine. Commit: 8d02e775a6 "mmc: sdhci: Use mmc core regulator infrastucture" > -- [2.068992] sdhci: Secure Digital Host Controller Interface driver [2.075059] sdhci: Copyright(c) Pierre Ossman [2.079762] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1251[0]' [2.088021] s3c-sdhci 1251.sdhci: clock source 2: mmc_busclk.2 (5000 Hz) [2.095322] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1251[0]' [2.103794] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1251[0]' [2.112478] s3c-sdhci 1251.sdhci: No vqmmc regulator found [2.118117] mmc0: Hardware doesn't report any support voltages. [2.124004] s3c-sdhci 1251.sdhci: sdhci_add_host() failed [2.130080] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1253[0]' [2.138352] s3c-sdhci 1253.sdhci: clock source 2: mmc_busclk.2 (1667 Hz) [2.145661] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1253[0]' [2.154139] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1253[0]' [2.162834] s3c-sdhci 1253.sdhci: No vqmmc regulator found [2.168464] mmc0: Hardware doesn't report any support voltages. [2.174349] s3c-sdhci 1253.sdhci: sdhci_add_host() failed > [2.336148] Waiting for root device /dev/mmcblk0p1... > >> FYI, the board has a 2.8V fixed regulator supply connected to the MMC. >> You may refer to arch/arm/boot/dts/exynos4210-origen.dts for more >> details. > > A 2.8v regulator results in mmc->ocr_avail being set to MMC_VDD_27_28 > | MMC_VDD_28_29. > > The SDHCI capabilities register only indicates support of three voltage > levels > - 1.8v: SDHCI_CAN_VDD_180 => MMC_VDD_165_195 > - 3.0v: SDHCI_CAN_VDD_300 => MMC_VDD_29_30 | MMC_VDD_30_31 > - 3.3v: SDHCI_CAN_VDD_330 => MMC_VDD_32_33 | MMC_VDD_33_34 > > Right. sdhci capabilities only indicated them. > But I think SoC can be support the specific VDD range. > > > Even if all capability bits of the host controller were set, there > still wouldn't be any overlap. Thus you see a "Hardware doesn't > report any support voltages" message. > > Previously, this issue was being swept under the rug by cec2e21 mmc: > sdhci: Use regulator min/max voltage range according to spec. That > change hacked up the voltage range checks such that with your 2.8v > fixed regulator, the driver would believe the host could support > MMC_VDD_29_30 | MMC_VDD_30_31 | MMC_VDD_32_33 | MMC_VDD_33_34. The > driver would start down the path of commanding 3.3v-3.4v (the highest > voltage range believed to be supported). At the last second, the > driver would see the regulator was fixed and blindly skip over the set > voltage operation, saving it from failure. > > Since my patch eliminates the bogus voltage range checks, your board > is now getting caught playing too loose with the SDHCI regulator > voltages. > > Furthermore, the fixed regulator special-case logic that helped hide > your issue should also be considered for removal given that fixed > regulators now behave properly thanks to c00dc35 regulator: core: > Allow regulator_set_voltage for fixed regulators. Thanks for the detailed explanation. What do you propose to get this fixed? >>> >>> I'm not really sure of the best path forward. I suppose you could >>> modify your device tree to lie about the voltage of the fixed >>> regulator. Changing it to 3.0v should allow it to boot up but that is >>> definitely a hack. > I don't want to change the 3.0V at dt file...is it hack? i don't think so. > Almost exynos4 Series is used the fixed regulator(2.8V). > I didn't know exactly why we used the 2.8V. But i guess there is some > reason.(H/W design). > > If we need to change ocr value, > then i will add the quirk or controlling function for exynos into sdhci-s3c.c > How about? That sounds good compared to adding hacks in DT files. > >> >> Or I c
Re: [PATCHv4 2/4] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
Hello Tomasz,
On 20 June 2014 06:00, Tomasz Figa wrote:
> On 20.06.2014 02:28, Chanwoo Choi wrote:
>> On 06/20/2014 09:24 AM, Tomasz Figa wrote:
>>> On 20.06.2014 02:22, Chanwoo Choi wrote:
Hi Tomasz,
On 06/18/2014 04:58 PM, Tomasz Figa wrote:
> Hi Chanwoo,
>
> On 18.06.2014 04:20, Chanwoo Choi wrote:
>> This patch control special clock for ADC in Exynos series's FSYS block.
>> If special clock of ADC is registerd on clock list of common clk
>> framework,
>> Exynos ADC drvier have to control this clock.
>>
>> Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
>> - 'adc' clock: bus clock for ADC
>>
>> Exynos3250 has additional 'sclk_adc' clock as following:
>> - 'sclk_adc' clock: special clock for ADC which provide clock to
>> internal ADC
>>
>> Exynos 4210/4212/4412 and Exynos5250/5420 has not included 'sclk_adc'
>> clock
>> in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included
>> 'sclk_adc'
>> clock in FSYS_BLK.
>>
>> Signed-off-by: Chanwoo Choi
>> Acked-by: Kyungmin Park
>> ---
>> drivers/iio/adc/exynos_adc.c | 93
>> ++--
>> 1 file changed, 81 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
>> index c30def6..6b026ac 100644
>> --- a/drivers/iio/adc/exynos_adc.c
>> +++ b/drivers/iio/adc/exynos_adc.c
>> @@ -41,7 +41,8 @@
>>
>> enum adc_version {
>> ADC_V1,
>> - ADC_V2
>> + ADC_V2,
>> + ADC_V2_EXYNOS3250,
>> };
>>
>> /* EXYNOS4412/5250 ADC_V1 registers definitions */
>> @@ -85,9 +86,11 @@ enum adc_version {
>> #define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
>>
>> struct exynos_adc {
>> + struct device *dev;
>> void __iomem*regs;
>> void __iomem*enable_reg;
>> struct clk *clk;
>> + struct clk *sclk;
>> unsigned intirq;
>> struct regulator*vdd;
>> struct exynos_adc_ops *ops;
>> @@ -96,6 +99,7 @@ struct exynos_adc {
>>
>> u32 value;
>> unsigned intversion;
>> + boolneeds_sclk;
>
> This should be rather a part of the variant struct. See my comments to
> patch 1/4.
OK, I'll include 'needs_sclk' in "variant" structure.
>
>> };
>>
>> struct exynos_adc_ops {
>> @@ -103,11 +107,21 @@ struct exynos_adc_ops {
>> void (*clear_irq)(struct exynos_adc *info);
>> void (*start_conv)(struct exynos_adc *info, unsigned long addr);
>> void (*stop_conv)(struct exynos_adc *info);
>> + void (*disable_clk)(struct exynos_adc *info);
>> + int (*enable_clk)(struct exynos_adc *info);
>> };
>>
>> static const struct of_device_id exynos_adc_match[] = {
>> - { .compatible = "samsung,exynos-adc-v1", .data = (void *)ADC_V1 },
>> - { .compatible = "samsung,exynos-adc-v2", .data = (void *)ADC_V2 },
>> + {
>> + .compatible = "samsung,exynos-adc-v1",
>> + .data = (void *)ADC_V1,
>> + }, {
>> + .compatible = "samsung,exynos-adc-v2",
>> + .data = (void *)ADC_V2,
>> + }, {
>> + .compatible = "samsung,exynos3250-adc-v2",
>> + .data = (void *)ADC_V2_EXYNOS3250,
>> + },
>> {},
>> };
>> MODULE_DEVICE_TABLE(of, exynos_adc_match);
>> @@ -156,11 +170,42 @@ static void exynos_adc_v1_stop_conv(struct
>> exynos_adc *info)
>> writel(con, ADC_V1_CON(info->regs));
>> }
>>
>> +static void exynos_adc_disable_clk(struct exynos_adc *info)
>> +{
>> + if (info->needs_sclk)
>> + clk_disable_unprepare(info->sclk);
>> + clk_disable_unprepare(info->clk);
>> +}
>> +
>> +static int exynos_adc_enable_clk(struct exynos_adc *info)
>> +{
>> + int ret;
>> +
>> + ret = clk_prepare_enable(info->clk);
>> + if (ret) {
>> + dev_err(info->dev, "failed enabling adc clock: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + if (info->needs_sclk) {
>> + ret = clk_prepare_enable(info->sclk);
>> + if (ret) {
>> + clk_disable_unprepare(info->clk);
>> + dev_err(info->dev,
>> + "failed enabling sclk_tsadc clock: %d\n", ret);
>> + }
>> + }
>> +
>> + return 0;
>> +}
>> +
>> static struct exynos_adc_ops exynos_adc_v1_ops = {
>> .init_hw= exynos_adc_v1_init_hw,
>> .clear_irq = exynos_adc_v1_clear_irq,
>> .start_conv = exynos_adc_v1_start_conv,
>> .stop_conv = exynos_adc_v1_stop_conv,
>> + .disable_clk= exynos_adc_disable_clk,
>> + .enable_clk = exynos_adc_enabl
Re: [PATCHv4 2/4] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
On 20.06.2014 02:28, Chanwoo Choi wrote:
> On 06/20/2014 09:24 AM, Tomasz Figa wrote:
>> On 20.06.2014 02:22, Chanwoo Choi wrote:
>>> Hi Tomasz,
>>>
>>> On 06/18/2014 04:58 PM, Tomasz Figa wrote:
Hi Chanwoo,
On 18.06.2014 04:20, Chanwoo Choi wrote:
> This patch control special clock for ADC in Exynos series's FSYS block.
> If special clock of ADC is registerd on clock list of common clk
> framework,
> Exynos ADC drvier have to control this clock.
>
> Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
> - 'adc' clock: bus clock for ADC
>
> Exynos3250 has additional 'sclk_adc' clock as following:
> - 'sclk_adc' clock: special clock for ADC which provide clock to internal
> ADC
>
> Exynos 4210/4212/4412 and Exynos5250/5420 has not included 'sclk_adc'
> clock
> in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included
> 'sclk_adc'
> clock in FSYS_BLK.
>
> Signed-off-by: Chanwoo Choi
> Acked-by: Kyungmin Park
> ---
> drivers/iio/adc/exynos_adc.c | 93
> ++--
> 1 file changed, 81 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
> index c30def6..6b026ac 100644
> --- a/drivers/iio/adc/exynos_adc.c
> +++ b/drivers/iio/adc/exynos_adc.c
> @@ -41,7 +41,8 @@
>
> enum adc_version {
> ADC_V1,
> - ADC_V2
> + ADC_V2,
> + ADC_V2_EXYNOS3250,
> };
>
> /* EXYNOS4412/5250 ADC_V1 registers definitions */
> @@ -85,9 +86,11 @@ enum adc_version {
> #define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
>
> struct exynos_adc {
> + struct device *dev;
> void __iomem*regs;
> void __iomem*enable_reg;
> struct clk *clk;
> + struct clk *sclk;
> unsigned intirq;
> struct regulator*vdd;
> struct exynos_adc_ops *ops;
> @@ -96,6 +99,7 @@ struct exynos_adc {
>
> u32 value;
> unsigned intversion;
> + boolneeds_sclk;
This should be rather a part of the variant struct. See my comments to
patch 1/4.
>>>
>>> OK, I'll include 'needs_sclk' in "variant" structure.
>>>
> };
>
> struct exynos_adc_ops {
> @@ -103,11 +107,21 @@ struct exynos_adc_ops {
> void (*clear_irq)(struct exynos_adc *info);
> void (*start_conv)(struct exynos_adc *info, unsigned long addr);
> void (*stop_conv)(struct exynos_adc *info);
> + void (*disable_clk)(struct exynos_adc *info);
> + int (*enable_clk)(struct exynos_adc *info);
> };
>
> static const struct of_device_id exynos_adc_match[] = {
> - { .compatible = "samsung,exynos-adc-v1", .data = (void *)ADC_V1 },
> - { .compatible = "samsung,exynos-adc-v2", .data = (void *)ADC_V2 },
> + {
> + .compatible = "samsung,exynos-adc-v1",
> + .data = (void *)ADC_V1,
> + }, {
> + .compatible = "samsung,exynos-adc-v2",
> + .data = (void *)ADC_V2,
> + }, {
> + .compatible = "samsung,exynos3250-adc-v2",
> + .data = (void *)ADC_V2_EXYNOS3250,
> + },
> {},
> };
> MODULE_DEVICE_TABLE(of, exynos_adc_match);
> @@ -156,11 +170,42 @@ static void exynos_adc_v1_stop_conv(struct
> exynos_adc *info)
> writel(con, ADC_V1_CON(info->regs));
> }
>
> +static void exynos_adc_disable_clk(struct exynos_adc *info)
> +{
> + if (info->needs_sclk)
> + clk_disable_unprepare(info->sclk);
> + clk_disable_unprepare(info->clk);
> +}
> +
> +static int exynos_adc_enable_clk(struct exynos_adc *info)
> +{
> + int ret;
> +
> + ret = clk_prepare_enable(info->clk);
> + if (ret) {
> + dev_err(info->dev, "failed enabling adc clock: %d\n", ret);
> + return ret;
> + }
> +
> + if (info->needs_sclk) {
> + ret = clk_prepare_enable(info->sclk);
> + if (ret) {
> + clk_disable_unprepare(info->clk);
> + dev_err(info->dev,
> + "failed enabling sclk_tsadc clock: %d\n", ret);
> + }
> + }
> +
> + return 0;
> +}
> +
> static struct exynos_adc_ops exynos_adc_v1_ops = {
> .init_hw= exynos_adc_v1_init_hw,
> .clear_irq = exynos_adc_v1_clear_irq,
> .start_conv = exynos_adc_v1_start_conv,
> .stop_conv = exynos_adc_v1_stop_conv,
> + .disable_clk= exynos_adc_disable_clk,
> + .enable_clk = exynos_adc_enable_clk,
> };
>
> static void exynos_adc_v2_init_hw(struct exynos_adc *info)
> @@ -210,6 +255,8 @@ static struct exynos_adc_ops exynos_adc_v2_ops = {
> .start_co
Re: [PATCHv4 2/4] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
On 06/20/2014 09:24 AM, Tomasz Figa wrote:
> On 20.06.2014 02:22, Chanwoo Choi wrote:
>> Hi Tomasz,
>>
>> On 06/18/2014 04:58 PM, Tomasz Figa wrote:
>>> Hi Chanwoo,
>>>
>>> On 18.06.2014 04:20, Chanwoo Choi wrote:
This patch control special clock for ADC in Exynos series's FSYS block.
If special clock of ADC is registerd on clock list of common clk framework,
Exynos ADC drvier have to control this clock.
Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
- 'adc' clock: bus clock for ADC
Exynos3250 has additional 'sclk_adc' clock as following:
- 'sclk_adc' clock: special clock for ADC which provide clock to internal
ADC
Exynos 4210/4212/4412 and Exynos5250/5420 has not included 'sclk_adc' clock
in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included
'sclk_adc'
clock in FSYS_BLK.
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
drivers/iio/adc/exynos_adc.c | 93
++--
1 file changed, 81 insertions(+), 12 deletions(-)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index c30def6..6b026ac 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -41,7 +41,8 @@
enum adc_version {
ADC_V1,
- ADC_V2
+ ADC_V2,
+ ADC_V2_EXYNOS3250,
};
/* EXYNOS4412/5250 ADC_V1 registers definitions */
@@ -85,9 +86,11 @@ enum adc_version {
#define EXYNOS_ADC_TIMEOUT(msecs_to_jiffies(100))
struct exynos_adc {
+ struct device *dev;
void __iomem*regs;
void __iomem*enable_reg;
struct clk *clk;
+ struct clk *sclk;
unsigned intirq;
struct regulator*vdd;
struct exynos_adc_ops *ops;
@@ -96,6 +99,7 @@ struct exynos_adc {
u32 value;
unsigned intversion;
+ boolneeds_sclk;
>>>
>>> This should be rather a part of the variant struct. See my comments to
>>> patch 1/4.
>>
>> OK, I'll include 'needs_sclk' in "variant" structure.
>>
>>>
};
struct exynos_adc_ops {
@@ -103,11 +107,21 @@ struct exynos_adc_ops {
void (*clear_irq)(struct exynos_adc *info);
void (*start_conv)(struct exynos_adc *info, unsigned long addr);
void (*stop_conv)(struct exynos_adc *info);
+ void (*disable_clk)(struct exynos_adc *info);
+ int (*enable_clk)(struct exynos_adc *info);
};
static const struct of_device_id exynos_adc_match[] = {
- { .compatible = "samsung,exynos-adc-v1", .data = (void *)ADC_V1 },
- { .compatible = "samsung,exynos-adc-v2", .data = (void *)ADC_V2 },
+ {
+ .compatible = "samsung,exynos-adc-v1",
+ .data = (void *)ADC_V1,
+ }, {
+ .compatible = "samsung,exynos-adc-v2",
+ .data = (void *)ADC_V2,
+ }, {
+ .compatible = "samsung,exynos3250-adc-v2",
+ .data = (void *)ADC_V2_EXYNOS3250,
+ },
{},
};
MODULE_DEVICE_TABLE(of, exynos_adc_match);
@@ -156,11 +170,42 @@ static void exynos_adc_v1_stop_conv(struct
exynos_adc *info)
writel(con, ADC_V1_CON(info->regs));
}
+static void exynos_adc_disable_clk(struct exynos_adc *info)
+{
+ if (info->needs_sclk)
+ clk_disable_unprepare(info->sclk);
+ clk_disable_unprepare(info->clk);
+}
+
+static int exynos_adc_enable_clk(struct exynos_adc *info)
+{
+ int ret;
+
+ ret = clk_prepare_enable(info->clk);
+ if (ret) {
+ dev_err(info->dev, "failed enabling adc clock: %d\n", ret);
+ return ret;
+ }
+
+ if (info->needs_sclk) {
+ ret = clk_prepare_enable(info->sclk);
+ if (ret) {
+ clk_disable_unprepare(info->clk);
+ dev_err(info->dev,
+ "failed enabling sclk_tsadc clock: %d\n", ret);
+ }
+ }
+
+ return 0;
+}
+
static struct exynos_adc_ops exynos_adc_v1_ops = {
.init_hw= exynos_adc_v1_init_hw,
.clear_irq = exynos_adc_v1_clear_irq,
.start_conv = exynos_adc_v1_start_conv,
.stop_conv = exynos_adc_v1_stop_conv,
+ .disable_clk= exynos_adc_disable_clk,
+ .enable_clk = exynos_adc_enable_clk,
};
static void exynos_adc_v2_init_hw(struct exynos_adc *info)
@@ -210,6 +255,8 @@ static struct exynos_adc_ops exynos_adc_v2_ops = {
.start_conv = exynos_adc_v2_start_conv,
.clear_irq = exynos_adc_v2_clear_irq,
.stop_conv = exynos_adc_v2_stop_conv,
>
Re: [PATCHv4 1/4] iio: adc: exynos_adc: Add exynos_adc_ops structure to improve readability
On 20.06.2014 02:20, Chanwoo Choi wrote:
> Hi Tomasz,
>
> On 06/18/2014 04:55 PM, Tomasz Figa wrote:
>> Hi Chanwoo,
>>
>> On 18.06.2014 04:20, Chanwoo Choi wrote:
>>> This patchset add 'exynos_adc_ops' structure which includes some functions
>>> to control ADC operation according to ADC version (v1 or v2).
>>>
>>> Signed-off-by: Chanwoo Choi
>>> Acked-by: Kyungmin Park
>>> ---
>>> drivers/iio/adc/exynos_adc.c | 174
>>> +--
>>> 1 file changed, 120 insertions(+), 54 deletions(-)
>>>
>>> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
>>> index 010578f..c30def6 100644
>>> --- a/drivers/iio/adc/exynos_adc.c
>>> +++ b/drivers/iio/adc/exynos_adc.c
>>> @@ -90,6 +90,7 @@ struct exynos_adc {
>>> struct clk *clk;
>>> unsigned intirq;
>>> struct regulator*vdd;
>>> + struct exynos_adc_ops *ops;
>>>
>>> struct completion completion;
>>>
>>> @@ -97,6 +98,13 @@ struct exynos_adc {
>>> unsigned intversion;
>>> };
>>>
>>> +struct exynos_adc_ops {
>>> + void (*init_hw)(struct exynos_adc *info);
>>> + void (*clear_irq)(struct exynos_adc *info);
>>> + void (*start_conv)(struct exynos_adc *info, unsigned long addr);
>>> + void (*stop_conv)(struct exynos_adc *info);
>>> +};
>>> +
>>> static const struct of_device_id exynos_adc_match[] = {
>>> { .compatible = "samsung,exynos-adc-v1", .data = (void *)ADC_V1 },
>>> { .compatible = "samsung,exynos-adc-v2", .data = (void *)ADC_V2 },
>>> @@ -112,30 +120,98 @@ static inline unsigned int
>>> exynos_adc_get_version(struct platform_device *pdev)
>>> return (unsigned int)match->data;
>>> }
>>>
>>> -static void exynos_adc_hw_init(struct exynos_adc *info)
>>> +static void exynos_adc_v1_init_hw(struct exynos_adc *info)
>>> +{
>>> + u32 con1;
>>> +
>>> + /* set default prescaler values and Enable prescaler */
>>> + con1 = ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
>>> +
>>> + /* Enable 12-bit ADC resolution */
>>> + con1 |= ADC_V1_CON_RES;
>>> + writel(con1, ADC_V1_CON(info->regs));
>>> +}
>>> +
>>> +static void exynos_adc_v1_start_conv(struct exynos_adc *info, unsigned
>>> long addr)
>>> +{
>>> + u32 con1;
>>> +
>>> + writel(addr, ADC_V1_MUX(info->regs));
>>> +
>>> + con1 = readl(ADC_V1_CON(info->regs));
>>> + writel(con1 | ADC_CON_EN_START, ADC_V1_CON(info->regs));
>>> +}
>>> +
>>> +static void exynos_adc_v1_clear_irq(struct exynos_adc *info)
>>> +{
>>> + writel(1, ADC_V1_INTCLR(info->regs));
>>> +}
>>> +
>>> +static void exynos_adc_v1_stop_conv(struct exynos_adc *info)
>>> +{
>>> + u32 con;
>>> +
>>> + con = readl(ADC_V1_CON(info->regs));
>>> + con |= ADC_V1_CON_STANDBY;
>>> + writel(con, ADC_V1_CON(info->regs));
>>> +}
>>> +
>>> +static struct exynos_adc_ops exynos_adc_v1_ops = {
>>> + .init_hw= exynos_adc_v1_init_hw,
>>> + .clear_irq = exynos_adc_v1_clear_irq,
>>> + .start_conv = exynos_adc_v1_start_conv,
>>> + .stop_conv = exynos_adc_v1_stop_conv,
>>> +};
>>> +
>>> +static void exynos_adc_v2_init_hw(struct exynos_adc *info)
>>> {
>>> u32 con1, con2;
>>>
>>> - if (info->version == ADC_V2) {
>>> - con1 = ADC_V2_CON1_SOFT_RESET;
>>> - writel(con1, ADC_V2_CON1(info->regs));
>>> + con1 = ADC_V2_CON1_SOFT_RESET;
>>> + writel(con1, ADC_V2_CON1(info->regs));
>>>
>>> - con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
>>> - ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
>>> - writel(con2, ADC_V2_CON2(info->regs));
>>> + con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
>>> + ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
>>> + writel(con2, ADC_V2_CON2(info->regs));
>>>
>>> - /* Enable interrupts */
>>> - writel(1, ADC_V2_INT_EN(info->regs));
>>> - } else {
>>> - /* set default prescaler values and Enable prescaler */
>>> - con1 = ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
>>> + /* Enable interrupts */
>>> + writel(1, ADC_V2_INT_EN(info->regs));
>>> +}
>>>
>>> - /* Enable 12-bit ADC resolution */
>>> - con1 |= ADC_V1_CON_RES;
>>> - writel(con1, ADC_V1_CON(info->regs));
>>> - }
>>> +static void exynos_adc_v2_start_conv(struct exynos_adc *info, unsigned
>>> long addr)
>>> +{
>>> + u32 con1, con2;
>>> +
>>> + con2 = readl(ADC_V2_CON2(info->regs));
>>> + con2 &= ~ADC_V2_CON2_ACH_MASK;
>>> + con2 |= ADC_V2_CON2_ACH_SEL(addr);
>>> + writel(con2, ADC_V2_CON2(info->regs));
>>> +
>>> + con1 = readl(ADC_V2_CON1(info->regs));
>>> + writel(con1 | ADC_CON_EN_START, ADC_V2_CON1(info->regs));
>>> +}
>>> +
>>> +static void exynos_adc_v2_clear_irq(struct exynos_adc *info)
>>> +{
>>> + writel(1, ADC_V2_INT_ST(info->regs));
>>> +}
>>> +
>>> +static void exynos_adc_v2_stop_conv(struct exynos_adc *info)
>>> +{
>>> + u32 con;
>>> +
>>> + con = readl(ADC_V2_CON1(info->regs));
>>> + con &= ~ADC_CON_EN_START;
>>>
Re: [PATCHv4 2/4] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
On 20.06.2014 02:22, Chanwoo Choi wrote:
> Hi Tomasz,
>
> On 06/18/2014 04:58 PM, Tomasz Figa wrote:
>> Hi Chanwoo,
>>
>> On 18.06.2014 04:20, Chanwoo Choi wrote:
>>> This patch control special clock for ADC in Exynos series's FSYS block.
>>> If special clock of ADC is registerd on clock list of common clk framework,
>>> Exynos ADC drvier have to control this clock.
>>>
>>> Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
>>> - 'adc' clock: bus clock for ADC
>>>
>>> Exynos3250 has additional 'sclk_adc' clock as following:
>>> - 'sclk_adc' clock: special clock for ADC which provide clock to internal
>>> ADC
>>>
>>> Exynos 4210/4212/4412 and Exynos5250/5420 has not included 'sclk_adc' clock
>>> in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included 'sclk_adc'
>>> clock in FSYS_BLK.
>>>
>>> Signed-off-by: Chanwoo Choi
>>> Acked-by: Kyungmin Park
>>> ---
>>> drivers/iio/adc/exynos_adc.c | 93
>>> ++--
>>> 1 file changed, 81 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
>>> index c30def6..6b026ac 100644
>>> --- a/drivers/iio/adc/exynos_adc.c
>>> +++ b/drivers/iio/adc/exynos_adc.c
>>> @@ -41,7 +41,8 @@
>>>
>>> enum adc_version {
>>> ADC_V1,
>>> - ADC_V2
>>> + ADC_V2,
>>> + ADC_V2_EXYNOS3250,
>>> };
>>>
>>> /* EXYNOS4412/5250 ADC_V1 registers definitions */
>>> @@ -85,9 +86,11 @@ enum adc_version {
>>> #define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
>>>
>>> struct exynos_adc {
>>> + struct device *dev;
>>> void __iomem*regs;
>>> void __iomem*enable_reg;
>>> struct clk *clk;
>>> + struct clk *sclk;
>>> unsigned intirq;
>>> struct regulator*vdd;
>>> struct exynos_adc_ops *ops;
>>> @@ -96,6 +99,7 @@ struct exynos_adc {
>>>
>>> u32 value;
>>> unsigned intversion;
>>> + boolneeds_sclk;
>>
>> This should be rather a part of the variant struct. See my comments to
>> patch 1/4.
>
> OK, I'll include 'needs_sclk' in "variant" structure.
>
>>
>>> };
>>>
>>> struct exynos_adc_ops {
>>> @@ -103,11 +107,21 @@ struct exynos_adc_ops {
>>> void (*clear_irq)(struct exynos_adc *info);
>>> void (*start_conv)(struct exynos_adc *info, unsigned long addr);
>>> void (*stop_conv)(struct exynos_adc *info);
>>> + void (*disable_clk)(struct exynos_adc *info);
>>> + int (*enable_clk)(struct exynos_adc *info);
>>> };
>>>
>>> static const struct of_device_id exynos_adc_match[] = {
>>> - { .compatible = "samsung,exynos-adc-v1", .data = (void *)ADC_V1 },
>>> - { .compatible = "samsung,exynos-adc-v2", .data = (void *)ADC_V2 },
>>> + {
>>> + .compatible = "samsung,exynos-adc-v1",
>>> + .data = (void *)ADC_V1,
>>> + }, {
>>> + .compatible = "samsung,exynos-adc-v2",
>>> + .data = (void *)ADC_V2,
>>> + }, {
>>> + .compatible = "samsung,exynos3250-adc-v2",
>>> + .data = (void *)ADC_V2_EXYNOS3250,
>>> + },
>>> {},
>>> };
>>> MODULE_DEVICE_TABLE(of, exynos_adc_match);
>>> @@ -156,11 +170,42 @@ static void exynos_adc_v1_stop_conv(struct exynos_adc
>>> *info)
>>> writel(con, ADC_V1_CON(info->regs));
>>> }
>>>
>>> +static void exynos_adc_disable_clk(struct exynos_adc *info)
>>> +{
>>> + if (info->needs_sclk)
>>> + clk_disable_unprepare(info->sclk);
>>> + clk_disable_unprepare(info->clk);
>>> +}
>>> +
>>> +static int exynos_adc_enable_clk(struct exynos_adc *info)
>>> +{
>>> + int ret;
>>> +
>>> + ret = clk_prepare_enable(info->clk);
>>> + if (ret) {
>>> + dev_err(info->dev, "failed enabling adc clock: %d\n", ret);
>>> + return ret;
>>> + }
>>> +
>>> + if (info->needs_sclk) {
>>> + ret = clk_prepare_enable(info->sclk);
>>> + if (ret) {
>>> + clk_disable_unprepare(info->clk);
>>> + dev_err(info->dev,
>>> + "failed enabling sclk_tsadc clock: %d\n", ret);
>>> + }
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> static struct exynos_adc_ops exynos_adc_v1_ops = {
>>> .init_hw= exynos_adc_v1_init_hw,
>>> .clear_irq = exynos_adc_v1_clear_irq,
>>> .start_conv = exynos_adc_v1_start_conv,
>>> .stop_conv = exynos_adc_v1_stop_conv,
>>> + .disable_clk= exynos_adc_disable_clk,
>>> + .enable_clk = exynos_adc_enable_clk,
>>> };
>>>
>>> static void exynos_adc_v2_init_hw(struct exynos_adc *info)
>>> @@ -210,6 +255,8 @@ static struct exynos_adc_ops exynos_adc_v2_ops = {
>>> .start_conv = exynos_adc_v2_start_conv,
>>> .clear_irq = exynos_adc_v2_clear_irq,
>>> .stop_conv = exynos_adc_v2_stop_conv,
>>> + .disable_clk= exynos_adc_disable_clk,
>>> + .enable_clk = exynos_adc_enable_clk,
>>
>> Based on the fact that all vari
Re: [PATCHv4 2/4] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
Hi Tomasz,
On 06/18/2014 04:58 PM, Tomasz Figa wrote:
> Hi Chanwoo,
>
> On 18.06.2014 04:20, Chanwoo Choi wrote:
>> This patch control special clock for ADC in Exynos series's FSYS block.
>> If special clock of ADC is registerd on clock list of common clk framework,
>> Exynos ADC drvier have to control this clock.
>>
>> Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
>> - 'adc' clock: bus clock for ADC
>>
>> Exynos3250 has additional 'sclk_adc' clock as following:
>> - 'sclk_adc' clock: special clock for ADC which provide clock to internal ADC
>>
>> Exynos 4210/4212/4412 and Exynos5250/5420 has not included 'sclk_adc' clock
>> in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included 'sclk_adc'
>> clock in FSYS_BLK.
>>
>> Signed-off-by: Chanwoo Choi
>> Acked-by: Kyungmin Park
>> ---
>> drivers/iio/adc/exynos_adc.c | 93
>> ++--
>> 1 file changed, 81 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
>> index c30def6..6b026ac 100644
>> --- a/drivers/iio/adc/exynos_adc.c
>> +++ b/drivers/iio/adc/exynos_adc.c
>> @@ -41,7 +41,8 @@
>>
>> enum adc_version {
>> ADC_V1,
>> -ADC_V2
>> +ADC_V2,
>> +ADC_V2_EXYNOS3250,
>> };
>>
>> /* EXYNOS4412/5250 ADC_V1 registers definitions */
>> @@ -85,9 +86,11 @@ enum adc_version {
>> #define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
>>
>> struct exynos_adc {
>> +struct device *dev;
>> void __iomem*regs;
>> void __iomem*enable_reg;
>> struct clk *clk;
>> +struct clk *sclk;
>> unsigned intirq;
>> struct regulator*vdd;
>> struct exynos_adc_ops *ops;
>> @@ -96,6 +99,7 @@ struct exynos_adc {
>>
>> u32 value;
>> unsigned intversion;
>> +boolneeds_sclk;
>
> This should be rather a part of the variant struct. See my comments to
> patch 1/4.
OK, I'll include 'needs_sclk' in "variant" structure.
>
>> };
>>
>> struct exynos_adc_ops {
>> @@ -103,11 +107,21 @@ struct exynos_adc_ops {
>> void (*clear_irq)(struct exynos_adc *info);
>> void (*start_conv)(struct exynos_adc *info, unsigned long addr);
>> void (*stop_conv)(struct exynos_adc *info);
>> +void (*disable_clk)(struct exynos_adc *info);
>> +int (*enable_clk)(struct exynos_adc *info);
>> };
>>
>> static const struct of_device_id exynos_adc_match[] = {
>> -{ .compatible = "samsung,exynos-adc-v1", .data = (void *)ADC_V1 },
>> -{ .compatible = "samsung,exynos-adc-v2", .data = (void *)ADC_V2 },
>> +{
>> +.compatible = "samsung,exynos-adc-v1",
>> +.data = (void *)ADC_V1,
>> +}, {
>> +.compatible = "samsung,exynos-adc-v2",
>> +.data = (void *)ADC_V2,
>> +}, {
>> +.compatible = "samsung,exynos3250-adc-v2",
>> +.data = (void *)ADC_V2_EXYNOS3250,
>> +},
>> {},
>> };
>> MODULE_DEVICE_TABLE(of, exynos_adc_match);
>> @@ -156,11 +170,42 @@ static void exynos_adc_v1_stop_conv(struct exynos_adc
>> *info)
>> writel(con, ADC_V1_CON(info->regs));
>> }
>>
>> +static void exynos_adc_disable_clk(struct exynos_adc *info)
>> +{
>> +if (info->needs_sclk)
>> +clk_disable_unprepare(info->sclk);
>> +clk_disable_unprepare(info->clk);
>> +}
>> +
>> +static int exynos_adc_enable_clk(struct exynos_adc *info)
>> +{
>> +int ret;
>> +
>> +ret = clk_prepare_enable(info->clk);
>> +if (ret) {
>> +dev_err(info->dev, "failed enabling adc clock: %d\n", ret);
>> +return ret;
>> +}
>> +
>> +if (info->needs_sclk) {
>> +ret = clk_prepare_enable(info->sclk);
>> +if (ret) {
>> +clk_disable_unprepare(info->clk);
>> +dev_err(info->dev,
>> +"failed enabling sclk_tsadc clock: %d\n", ret);
>> +}
>> +}
>> +
>> +return 0;
>> +}
>> +
>> static struct exynos_adc_ops exynos_adc_v1_ops = {
>> .init_hw= exynos_adc_v1_init_hw,
>> .clear_irq = exynos_adc_v1_clear_irq,
>> .start_conv = exynos_adc_v1_start_conv,
>> .stop_conv = exynos_adc_v1_stop_conv,
>> +.disable_clk= exynos_adc_disable_clk,
>> +.enable_clk = exynos_adc_enable_clk,
>> };
>>
>> static void exynos_adc_v2_init_hw(struct exynos_adc *info)
>> @@ -210,6 +255,8 @@ static struct exynos_adc_ops exynos_adc_v2_ops = {
>> .start_conv = exynos_adc_v2_start_conv,
>> .clear_irq = exynos_adc_v2_clear_irq,
>> .stop_conv = exynos_adc_v2_stop_conv,
>> +.disable_clk= exynos_adc_disable_clk,
>> +.enable_clk = exynos_adc_enable_clk,
>
> Based on the fact that all variants use the same function, I don't think
> there is a reason to add .{disable,enable}_clk in the ops struct. If
> they diverge
Re: [PATCHv4 1/4] iio: adc: exynos_adc: Add exynos_adc_ops structure to improve readability
Hi Tomasz,
On 06/18/2014 04:55 PM, Tomasz Figa wrote:
> Hi Chanwoo,
>
> On 18.06.2014 04:20, Chanwoo Choi wrote:
>> This patchset add 'exynos_adc_ops' structure which includes some functions
>> to control ADC operation according to ADC version (v1 or v2).
>>
>> Signed-off-by: Chanwoo Choi
>> Acked-by: Kyungmin Park
>> ---
>> drivers/iio/adc/exynos_adc.c | 174
>> +--
>> 1 file changed, 120 insertions(+), 54 deletions(-)
>>
>> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
>> index 010578f..c30def6 100644
>> --- a/drivers/iio/adc/exynos_adc.c
>> +++ b/drivers/iio/adc/exynos_adc.c
>> @@ -90,6 +90,7 @@ struct exynos_adc {
>> struct clk *clk;
>> unsigned intirq;
>> struct regulator*vdd;
>> +struct exynos_adc_ops *ops;
>>
>> struct completion completion;
>>
>> @@ -97,6 +98,13 @@ struct exynos_adc {
>> unsigned intversion;
>> };
>>
>> +struct exynos_adc_ops {
>> +void (*init_hw)(struct exynos_adc *info);
>> +void (*clear_irq)(struct exynos_adc *info);
>> +void (*start_conv)(struct exynos_adc *info, unsigned long addr);
>> +void (*stop_conv)(struct exynos_adc *info);
>> +};
>> +
>> static const struct of_device_id exynos_adc_match[] = {
>> { .compatible = "samsung,exynos-adc-v1", .data = (void *)ADC_V1 },
>> { .compatible = "samsung,exynos-adc-v2", .data = (void *)ADC_V2 },
>> @@ -112,30 +120,98 @@ static inline unsigned int
>> exynos_adc_get_version(struct platform_device *pdev)
>> return (unsigned int)match->data;
>> }
>>
>> -static void exynos_adc_hw_init(struct exynos_adc *info)
>> +static void exynos_adc_v1_init_hw(struct exynos_adc *info)
>> +{
>> +u32 con1;
>> +
>> +/* set default prescaler values and Enable prescaler */
>> +con1 = ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
>> +
>> +/* Enable 12-bit ADC resolution */
>> +con1 |= ADC_V1_CON_RES;
>> +writel(con1, ADC_V1_CON(info->regs));
>> +}
>> +
>> +static void exynos_adc_v1_start_conv(struct exynos_adc *info, unsigned long
>> addr)
>> +{
>> +u32 con1;
>> +
>> +writel(addr, ADC_V1_MUX(info->regs));
>> +
>> +con1 = readl(ADC_V1_CON(info->regs));
>> +writel(con1 | ADC_CON_EN_START, ADC_V1_CON(info->regs));
>> +}
>> +
>> +static void exynos_adc_v1_clear_irq(struct exynos_adc *info)
>> +{
>> +writel(1, ADC_V1_INTCLR(info->regs));
>> +}
>> +
>> +static void exynos_adc_v1_stop_conv(struct exynos_adc *info)
>> +{
>> +u32 con;
>> +
>> +con = readl(ADC_V1_CON(info->regs));
>> +con |= ADC_V1_CON_STANDBY;
>> +writel(con, ADC_V1_CON(info->regs));
>> +}
>> +
>> +static struct exynos_adc_ops exynos_adc_v1_ops = {
>> +.init_hw= exynos_adc_v1_init_hw,
>> +.clear_irq = exynos_adc_v1_clear_irq,
>> +.start_conv = exynos_adc_v1_start_conv,
>> +.stop_conv = exynos_adc_v1_stop_conv,
>> +};
>> +
>> +static void exynos_adc_v2_init_hw(struct exynos_adc *info)
>> {
>> u32 con1, con2;
>>
>> -if (info->version == ADC_V2) {
>> -con1 = ADC_V2_CON1_SOFT_RESET;
>> -writel(con1, ADC_V2_CON1(info->regs));
>> +con1 = ADC_V2_CON1_SOFT_RESET;
>> +writel(con1, ADC_V2_CON1(info->regs));
>>
>> -con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
>> -ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
>> -writel(con2, ADC_V2_CON2(info->regs));
>> +con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
>> +ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
>> +writel(con2, ADC_V2_CON2(info->regs));
>>
>> -/* Enable interrupts */
>> -writel(1, ADC_V2_INT_EN(info->regs));
>> -} else {
>> -/* set default prescaler values and Enable prescaler */
>> -con1 = ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
>> +/* Enable interrupts */
>> +writel(1, ADC_V2_INT_EN(info->regs));
>> +}
>>
>> -/* Enable 12-bit ADC resolution */
>> -con1 |= ADC_V1_CON_RES;
>> -writel(con1, ADC_V1_CON(info->regs));
>> -}
>> +static void exynos_adc_v2_start_conv(struct exynos_adc *info, unsigned long
>> addr)
>> +{
>> +u32 con1, con2;
>> +
>> +con2 = readl(ADC_V2_CON2(info->regs));
>> +con2 &= ~ADC_V2_CON2_ACH_MASK;
>> +con2 |= ADC_V2_CON2_ACH_SEL(addr);
>> +writel(con2, ADC_V2_CON2(info->regs));
>> +
>> +con1 = readl(ADC_V2_CON1(info->regs));
>> +writel(con1 | ADC_CON_EN_START, ADC_V2_CON1(info->regs));
>> +}
>> +
>> +static void exynos_adc_v2_clear_irq(struct exynos_adc *info)
>> +{
>> +writel(1, ADC_V2_INT_ST(info->regs));
>> +}
>> +
>> +static void exynos_adc_v2_stop_conv(struct exynos_adc *info)
>> +{
>> +u32 con;
>> +
>> +con = readl(ADC_V2_CON1(info->regs));
>> +con &= ~ADC_CON_EN_START;
>> +writel(con, ADC_V2_CON1(info->regs));
>> }
>>
>> +static struct exynos_adc_ops exynos_adc_v2_ops = {
>> +.init_hw
Re: [PATCH 1/2] drm/exynos/fbdev: don't set fix.smem/mmio_{start,len}
On Fri, 4 Apr 2014 17:22:01 +0800
Daniel Kurtz wrote:
> Kernel access to the eyxnos fbdev framebuffer is via its gem object's
> kernel mapping (kvaddr, stored in info->screen_base).
>
> User space access is provided by mmap(), read() and write() of /dev/fb/fb0.
> These functions also only use screen_base/screen_size().
>
> Therefore, it is not necessary to set fix->smem_{start,len} or
> fix->mmio_{start,len} fields.
>
> This avoids leaking kernel, physical and dma mapped addresses to user
> space via the ioctls FBIOGET_VSCREENINFO and FBIOGET_FSCREENINFO.
>
> Signed-off-by: Daniel Kurtz
> ---
> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index 5fa342e..2dcc589 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -123,14 +123,7 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper
> *helper,
>
> dev->mode_config.fb_base = (resource_size_t)buffer->dma_addr;
> fbi->screen_base = buffer->kvaddr + offset;
> - if (is_drm_iommu_supported(dev))
> - fbi->fix.smem_start = (unsigned long)
> - (page_to_phys(sg_page(buffer->sgt->sgl)) + offset);
> - else
> - fbi->fix.smem_start = (unsigned long)buffer->dma_addr;
> -
> fbi->screen_size = size;
> - fbi->fix.smem_len = size;
Can we keep proper initialization of 'smem_len'? Some userland
applications use it for calculating the size for mmap:
http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/fbdevhw/fbdevhw.c?id=xorg-server-1.15.99.903#n571
>
> return 0;
> }
Basically, this patch breaks the xf86-video-fbdev ddx and some users
are already unhappy.
--
Best regards,
Siarhei Siamashka
--
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: exynos5: Properly use the "noirq" variants of suspend/resume
Kevin, On Thu, Jun 19, 2014 at 11:43 AM, Kevin Hilman wrote: > Doug Anderson writes: > >> The original code for the exynos i2c controller registered for the >> "noirq" variants. However during review feedback it was moved to >> SIMPLE_DEV_PM_OPS without anyone noticing that it meant we were no >> longer actually "noirq" (despite functions named >> exynos5_i2c_suspend_noirq and exynos5_i2c_resume_noirq). >> >> i2c controllers that might have wakeup sources on them seem to need to >> resume at noirq time so that the individual drivers can actually read >> the i2c bus to handle their wakeup. > > I suspect usage of the noirq variants pre-dates the existence of the > late/early callbacks in the PM core, but based on the description above, > I suspect what you actually want is the late/early callbacks. I think it actually really needs noirq. ;) Specifically as soon as IRQs are enabled one of our children might get an interrupt. To respond to that interrupt it might want to do an i2c transfer. Here's a snippet from me moving it to "resume early". You can see that max77686 failed pretty much right away (the dummy is just the max77686 RTC for various reasons). Note that the max77686 isn't doing anything tricky. It uses regmap_irq (as per Javier's patches) and calls enable_irq_wake() at suspend time. It uses a simple threaded IRQ: [ 117.968055] PM: noirq resume of devices complete after 1.391 msecs [ 117.968200] max77686 0-0009: Failed to read IRQ status: -5 [ 117.968697] dummy 0-0006: Failed to read IRQ status: -5 [ 117.968793] calling 12c6.i2c+ @ 5891, parent: none [ 117.968805] s3c-i2c 12c6.i2c: slave address 0x00 [ 117.968814] s3c-i2c 12c6.i2c: bus frequency set to 378 KHz [ 117.968824] call 12c6.i2c+ returned 0 after 23 usecs [ 117.968831] calling 12c7.i2c+ @ 5891, parent: none [ 117.968841] s3c-i2c 12c7.i2c: slave address 0x00 [ 117.968849] s3c-i2c 12c7.i2c: bus frequency set to 378 KHz [ 117.968858] call 12c7.i2c+ returned 0 after 20 usecs [ 117.968864] calling 12c8.i2c+ @ 5891, parent: none [ 117.968874] s3c-i2c 12c8.i2c: slave address 0x00 [ 117.968882] s3c-i2c 12c8.i2c: bus frequency set to 65 KHz [ 117.968891] call 12c8.i2c+ returned 0 after 20 usecs [ 117.968897] calling 12c9.i2c+ @ 5891, parent: none [ 117.968907] s3c-i2c 12c9.i2c: slave address 0x00 [ 117.968915] s3c-i2c 12c9.i2c: bus frequency set to 65 KHz [ 117.968923] call 12c9.i2c+ returned 0 after 19 usecs [ 117.968930] calling 12ca.i2c+ @ 5891, parent: none [ 117.968940] s3c-i2c 12ca.i2c: slave address 0x00 [ 117.968948] s3c-i2c 12ca.i2c: bus frequency set to 65 KHz [ 117.968957] call 12ca.i2c+ returned 0 after 20 usecs [ 117.968964] calling 12cb.i2c+ @ 5891, parent: none [ 117.968974] s3c-i2c 12cb.i2c: slave address 0x00 [ 117.968982] s3c-i2c 12cb.i2c: bus frequency set to 65 KHz [ 117.968990] call 12cb.i2c+ returned 0 after 20 usecs [ 117.968997] calling 12cd.i2c+ @ 5891, parent: none [ 117.969006] s3c-i2c 12cd.i2c: slave address 0x00 [ 117.969014] s3c-i2c 12cd.i2c: bus frequency set to 65 KHz [ 117.969022] call 12cd.i2c+ returned 0 after 19 usecs [ 117.969029] calling 12ce.i2c+ @ 5891, parent: none [ 117.969039] s3c-i2c 12ce.i2c: slave address 0x00 [ 117.969048] s3c-i2c 12ce.i2c: bus frequency set to 378 KHz [ 117.969056] call 12ce.i2c+ returned 0 after 20 usecs [ 117.969625] PM: early resume of devices complete after 1.469 msecs -- 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: exynos: Support cluster power off on exynos5420/5800
Abhilash Kesavan writes: > Turning off a cluster when all 4 cores of the cluster are powered off > saves power significantly. Powering off the A15 L2 alone gives around > 100mW in savings. Add support for powering off the A15/A7 clusters on > exynos5420/5800. > > The patch enables specific register bits which ensure that: >- cluster L2 will be turned on before the first man is powered up. >- last man will be turned off before the cluster L2 is turned off. >- core is powered down before powering it up. > > Remove the exynos_cluster_power_control function completely as we can > rely on the above mentioned bits rather than polling the cluster power > status register. > > Signed-off-by: Abhilash Kesavan > Acked-by: Nicolas Pitre > --- > Change in v2: > Added a macro for the COMMON_OPTION register and used it in the MCPM > back-end. > > The patch is based on Linux-next 20140619. It has been tested on an > exynos5420-based chromebook using the "/dev/bL_switcher" interface as > well as the script provided by Nicolas Pitre and Dave Martin [1]. > > Patch depends on: > [v2] ARM: EXYNOS: mcpm: Don't rely on firmware's secondary_cpu_start > > [1] http://www.spinics.net/lists/linux-samsung-soc/msg31257.html Tested on exynos5800/Chromebook2 along with the dependency patch and using the script from Dave and Nico. Tested-by: Kevin Hilman Kevin -- 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: exynos5: Properly use the "noirq" variants of suspend/resume
Doug Anderson writes: > The original code for the exynos i2c controller registered for the > "noirq" variants. However during review feedback it was moved to > SIMPLE_DEV_PM_OPS without anyone noticing that it meant we were no > longer actually "noirq" (despite functions named > exynos5_i2c_suspend_noirq and exynos5_i2c_resume_noirq). > > i2c controllers that might have wakeup sources on them seem to need to > resume at noirq time so that the individual drivers can actually read > the i2c bus to handle their wakeup. I suspect usage of the noirq variants pre-dates the existence of the late/early callbacks in the PM core, but based on the description above, I suspect what you actually want is the late/early callbacks. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 01/14] mfd: max77686: Convert to use regmap_irq
By using the generic IRQ support in the Register map API, it
is possible to get rid max77686-irq.c and simplify the code.
Suggested-by: Krzysztof Kozlowski
Signed-off-by: Javier Martinez Canillas
Acked-by: Lee Jones
Reviewed-by: Doug Anderson
Tested-by: Doug Anderson
---
Changes since v2:
- Cleanup regmap irqchips on i2c_driver .remove function.
Suggested by Doug Anderson.
- Remove unused MAX77686_IRQ_NR enum. Suggested by Doug Anderson.
drivers/mfd/Kconfig | 1 +
drivers/mfd/Makefile | 2 +-
drivers/mfd/max77686-irq.c | 319 ---
drivers/mfd/max77686.c | 97 ++-
drivers/rtc/rtc-max77686.c | 27 +--
include/linux/mfd/max77686-private.h | 28 ++-
include/linux/mfd/max77686.h | 2 -
7 files changed, 123 insertions(+), 353 deletions(-)
delete mode 100644 drivers/mfd/max77686-irq.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index ee8204c..0916447 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -371,6 +371,7 @@ config MFD_MAX77686
depends on I2C=y
select MFD_CORE
select REGMAP_I2C
+ select REGMAP_IRQ
select IRQ_DOMAIN
help
Say yes here to add support for Maxim Semiconductor MAX77686.
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 8afedba..3b3b408 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -115,7 +115,7 @@ da9063-objs := da9063-core.o da9063-irq.o
da9063-i2c.o
obj-$(CONFIG_MFD_DA9063) += da9063.o
obj-$(CONFIG_MFD_MAX14577) += max14577.o
-obj-$(CONFIG_MFD_MAX77686) += max77686.o max77686-irq.o
+obj-$(CONFIG_MFD_MAX77686) += max77686.o
obj-$(CONFIG_MFD_MAX77693) += max77693.o max77693-irq.o
obj-$(CONFIG_MFD_MAX8907) += max8907.o
max8925-objs := max8925-core.o max8925-i2c.o
diff --git a/drivers/mfd/max77686-irq.c b/drivers/mfd/max77686-irq.c
deleted file mode 100644
index cdc3280..000
--- a/drivers/mfd/max77686-irq.c
+++ /dev/null
@@ -1,319 +0,0 @@
-/*
- * max77686-irq.c - Interrupt controller support for MAX77686
- *
- * Copyright (C) 2012 Samsung Electronics Co.Ltd
- * Chiwoong Byun
- *
- * 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.
- *
- * 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- *
- * This driver is based on max8997-irq.c
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-enum {
- MAX77686_DEBUG_IRQ_INFO = 1 << 0,
- MAX77686_DEBUG_IRQ_MASK = 1 << 1,
- MAX77686_DEBUG_IRQ_INT = 1 << 2,
-};
-
-static int debug_mask = 0;
-module_param(debug_mask, int, 0);
-MODULE_PARM_DESC(debug_mask, "Set debug_mask : 0x0=off 0x1=IRQ_INFO
0x2=IRQ_MASK 0x4=IRQ_INI)");
-
-static const u8 max77686_mask_reg[] = {
- [PMIC_INT1] = MAX77686_REG_INT1MSK,
- [PMIC_INT2] = MAX77686_REG_INT2MSK,
- [RTC_INT] = MAX77686_RTC_INTM,
-};
-
-static struct regmap *max77686_get_regmap(struct max77686_dev *max77686,
- enum max77686_irq_source src)
-{
- switch (src) {
- case PMIC_INT1 ... PMIC_INT2:
- return max77686->regmap;
- case RTC_INT:
- return max77686->rtc_regmap;
- default:
- return ERR_PTR(-EINVAL);
- }
-}
-
-struct max77686_irq_data {
- int mask;
- enum max77686_irq_source group;
-};
-
-#define DECLARE_IRQ(idx, _group, _mask)\
- [(idx)] = { .group = (_group), .mask = (_mask) }
-static const struct max77686_irq_data max77686_irqs[] = {
- DECLARE_IRQ(MAX77686_PMICIRQ_PWRONF,PMIC_INT1, 1 << 0),
- DECLARE_IRQ(MAX77686_PMICIRQ_PWRONR,PMIC_INT1, 1 << 1),
- DECLARE_IRQ(MAX77686_PMICIRQ_JIGONBF, PMIC_INT1, 1 << 2),
- DECLARE_IRQ(MAX77686_PMICIRQ_JIGONBR, PMIC_INT1, 1 << 3),
- DECLARE_IRQ(MAX77686_PMICIRQ_ACOKBF,PMIC_INT1, 1 << 4),
- DECLARE_IRQ(MAX77686_PMICIRQ_ACOKBR,PMIC_INT1, 1 << 5),
- DECLARE_IRQ(MAX77686_PMICIRQ_ONKEY1S, PMIC_INT1, 1 << 6),
- DECLARE_IRQ(MAX77686_PMICIRQ_MRSTB, PMIC_INT1, 1 << 7),
- DECLARE_IRQ(MAX77686_PMICIRQ_140C, PMIC_INT2, 1 << 0),
- DECLARE_IRQ(MAX77686_PMICIRQ_120C, PMIC_INT2, 1 << 1),
- DECLARE_IRQ(MAX77686_RTCIRQ_RTC60S,
[PATCH v3 03/14] clk: max77686: Add DT include for MAX77686 PMIC clock
This patch adds a dt-binding include for Maxim 77686
PMIC clock IDs that can be to be shared between the
clk-max77686 clock driver and DeviceTree source files.
Signed-off-by: Javier Martinez Canillas
---
drivers/clk/clk-max77686.c | 7 +--
include/dt-bindings/clock/maxim,max77686.h | 23 +++
2 files changed, 24 insertions(+), 6 deletions(-)
create mode 100644 include/dt-bindings/clock/maxim,max77686.h
diff --git a/drivers/clk/clk-max77686.c b/drivers/clk/clk-max77686.c
index 3d7e8dd..185b611 100644
--- a/drivers/clk/clk-max77686.c
+++ b/drivers/clk/clk-max77686.c
@@ -30,12 +30,7 @@
#include
#include
-enum {
- MAX77686_CLK_AP = 0,
- MAX77686_CLK_CP,
- MAX77686_CLK_PMIC,
- MAX77686_CLKS_NUM,
-};
+#include
struct max77686_clk {
struct max77686_dev *iodev;
diff --git a/include/dt-bindings/clock/maxim,max77686.h
b/include/dt-bindings/clock/maxim,max77686.h
new file mode 100644
index 000..7b28b09
--- /dev/null
+++ b/include/dt-bindings/clock/maxim,max77686.h
@@ -0,0 +1,23 @@
+/*
+ * Copyright (C) 2014 Google, Inc
+ *
+ * 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.
+ *
+ * Device Tree binding constants clocks for the Maxim 77686 PMIC.
+ */
+
+#ifndef _DT_BINDINGS_CLOCK_MAXIM_MAX77686_CLOCK_H
+#define _DT_BINDINGS_CLOCK_MAXIM_MAX77686_CLOCK_H
+
+/* Fixed rate clocks. */
+
+#define MAX77686_CLK_AP0
+#define MAX77686_CLK_CP1
+#define MAX77686_CLK_PMIC 2
+
+/* Total number of clocks. */
+#define MAX77686_CLKS_NUM (MAX77686_CLK_PMIC + 1)
+
+#endif /* _DT_BINDINGS_CLOCK_MAXIM_MAX77686_CLOCK_H */
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 02/14] mfd: max77686: Allow the max77686 rtc to wakeup the system
From: Doug Anderson
The max77686 includes an RTC that keeps power during suspend. It's
convenient to be able to use it as a wakeup source.
Signed-off-by: Doug Anderson
---
drivers/rtc/rtc-max77686.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/rtc/rtc-max77686.c b/drivers/rtc/rtc-max77686.c
index d20a7f0..c1c6055 100644
--- a/drivers/rtc/rtc-max77686.c
+++ b/drivers/rtc/rtc-max77686.c
@@ -583,6 +583,33 @@ static void max77686_rtc_shutdown(struct platform_device
*pdev)
#endif /* MAX77686_RTC_WTSR_SMPL */
}
+#ifdef CONFIG_PM_SLEEP
+static int max77686_rtc_suspend(struct device *dev)
+{
+ if (device_may_wakeup(dev)) {
+ struct max77686_rtc_info *info = dev_get_drvdata(dev);
+
+ return enable_irq_wake(info->virq);
+ }
+
+ return 0;
+}
+
+static int max77686_rtc_resume(struct device *dev)
+{
+ if (device_may_wakeup(dev)) {
+ struct max77686_rtc_info *info = dev_get_drvdata(dev);
+
+ return disable_irq_wake(info->virq);
+ }
+
+ return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(max77686_rtc_pm_ops,
+max77686_rtc_suspend, max77686_rtc_resume);
+
static const struct platform_device_id rtc_id[] = {
{ "max77686-rtc", 0 },
{},
@@ -592,6 +619,7 @@ static struct platform_driver max77686_rtc_driver = {
.driver = {
.name = "max77686-rtc",
.owner = THIS_MODULE,
+ .pm = &max77686_rtc_pm_ops,
},
.probe = max77686_rtc_probe,
.shutdown = max77686_rtc_shutdown,
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 04/14] clk: max77686: Improve Maxim 77686 PMIC clocks binding
Like most clock drivers, the Maxim 77686 PMIC clock binding
follows the convention that the "#clock-cells" property is
used to specify the number of cells in a clock provider.
But the binding document is not clear enough that it shall
be set to 1 since the PMIC support multiple clocks outputs.
Also, explain that the clocks identifiers are defined in a
header file that can be included by Device Tree source with
client nodes to avoid using magic numbers.
Signed-off-by: Javier Martinez Canillas
---
.../devicetree/bindings/clock/maxim,max77686.txt | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/maxim,max77686.txt
b/Documentation/devicetree/bindings/clock/maxim,max77686.txt
index 96ce71b..8dea305 100644
--- a/Documentation/devicetree/bindings/clock/maxim,max77686.txt
+++ b/Documentation/devicetree/bindings/clock/maxim,max77686.txt
@@ -9,13 +9,18 @@ The MAX77686 contains three 32.768khz clock outputs that can
be controlled
Following properties should be presend in main device node of the MFD chip.
Required properties:
-- #clock-cells: simple one-cell clock specifier format is used, where the
- only cell is used as an index of the clock inside the provider. Following
- indices are allowed:
+
+- #clock-cells: from common clock binding; shall be set to 1.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. Following indices are allowed:
- 0: 32khz_ap clock,
- 1: 32khz_cp clock,
- 2: 32khz_pmic clock.
+Clocks are defined as preprocessor macros in dt-bindings/clock/maxim,max77686.h
+header and can be used in device tree sources.
+
Example: Node of the MFD chip
max77686: max77686@09 {
@@ -33,6 +38,6 @@ Example: Clock consumer node
foo@0 {
compatible = "bar,foo";
/* ... */
- clock-names = "my-clock";
- clocks = <&max77686 2>;
+ clock-names = "32khz_pmic";
+ clocks = <&max77686 MAX77686_CLK_PMIC>;
};
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 05/14] clk: Add generic driver for Maxim PMIC clocks
Maxim Integrated Power Management ICs are very similar with
regard to their clock outputs. Most of the clock drivers for
these chips are duplicating code and are simpler enough that
can be converted to use a generic driver to consolidate code
and avoid duplication.
Signed-off-by: Javier Martinez Canillas
---
drivers/clk/Kconfig | 3 +
drivers/clk/Makefile | 1 +
drivers/clk/clk-max-gen.c | 197 ++
drivers/clk/clk-max-gen.h | 32
4 files changed, 233 insertions(+)
create mode 100644 drivers/clk/clk-max-gen.c
create mode 100644 drivers/clk/clk-max-gen.h
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 9f9c5ae..73f78e8 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -32,6 +32,9 @@ config COMMON_CLK_WM831X
source "drivers/clk/versatile/Kconfig"
+config COMMON_CLK_MAX_GEN
+bool
+
config COMMON_CLK_MAX77686
tristate "Clock driver for Maxim 77686 MFD"
depends on MFD_MAX77686
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 567f102..6c1aff6 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_ARCH_BCM2835)+= clk-bcm2835.o
obj-$(CONFIG_ARCH_EFM32) += clk-efm32gg.o
obj-$(CONFIG_ARCH_HIGHBANK)+= clk-highbank.o
obj-$(CONFIG_MACH_LOONGSON1) += clk-ls1x.o
+obj-$(CONFIG_COMMON_CLK_MAX_GEN) += clk-max-gen.o
obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
obj-$(CONFIG_ARCH_MOXART) += clk-moxart.o
obj-$(CONFIG_ARCH_NOMADIK) += clk-nomadik.o
diff --git a/drivers/clk/clk-max-gen.c b/drivers/clk/clk-max-gen.c
new file mode 100644
index 000..aa9ebbe
--- /dev/null
+++ b/drivers/clk/clk-max-gen.c
@@ -0,0 +1,197 @@
+/*
+ * clk-max-gen.c - Generic clock driver for Maxim PMICs clocks
+ *
+ * Copyright (C) 2012 Samsung Electornics
+ * Jonghwa Lee
+ *
+ * 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.
+ *
+ * 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.
+ *
+ * This driver is based on clk-max77686.c
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct max_gen_clk {
+ struct regmap *regmap;
+ u32 mask;
+ u32 reg;
+ struct clk_hw hw;
+ struct clk_lookup *lookup;
+};
+
+static struct max_gen_clk *to_max_gen_clk(struct clk_hw *hw)
+{
+ return container_of(hw, struct max_gen_clk, hw);
+}
+
+static int max_gen_clk_prepare(struct clk_hw *hw)
+{
+ struct max_gen_clk *max_gen = to_max_gen_clk(hw);
+
+ return regmap_update_bits(max_gen->regmap, max_gen->reg,
+ max_gen->mask, max_gen->mask);
+}
+
+static void max_gen_clk_unprepare(struct clk_hw *hw)
+{
+ struct max_gen_clk *max_gen = to_max_gen_clk(hw);
+
+ regmap_update_bits(max_gen->regmap, max_gen->reg,
+ max_gen->mask, ~max_gen->mask);
+}
+
+static int max_gen_clk_is_prepared(struct clk_hw *hw)
+{
+ struct max_gen_clk *max_gen = to_max_gen_clk(hw);
+ int ret;
+ u32 val;
+
+ ret = regmap_read(max_gen->regmap, max_gen->reg, &val);
+
+ if (ret < 0)
+ return -EINVAL;
+
+ return val & max_gen->mask;
+}
+
+static unsigned long max_gen_recalc_rate(struct clk_hw *hw,
+unsigned long parent_rate)
+{
+ return 32768;
+}
+
+struct clk_ops max_gen_clk_ops = {
+ .prepare= max_gen_clk_prepare,
+ .unprepare = max_gen_clk_unprepare,
+ .is_prepared= max_gen_clk_is_prepared,
+ .recalc_rate= max_gen_recalc_rate,
+};
+
+static struct clk *max_gen_clk_register(struct device *dev,
+ struct max_gen_clk *max_gen)
+{
+ struct clk *clk;
+ struct clk_hw *hw = &max_gen->hw;
+
+ clk = clk_register(dev, hw);
+ if (IS_ERR(clk))
+ return clk;
+
+ max_gen->lookup = kzalloc(sizeof(struct clk_lookup), GFP_KERNEL);
+ if (!max_gen->lookup)
+ return ERR_PTR(-ENOMEM);
+
+ max_gen->lookup->con_id = hw->init->name;
+ max_gen->lookup->clk = clk;
+
+ clkdev_add(max_gen->lookup);
+
+ return clk;
+}
+
+int max_gen_clk_probe(struct platform_device *pdev, struct regmap *regmap,
+ u32 reg, struct clk_init_data *clks_init, int num_init)
+{
+ int i, ret;
+ struct max_gen_clk **max_gen_clks;
+ struct clk **clocks;
+ struct device *dev = &pdev->dev;
+
+ clocks = devm_kzalloc(dev, si
[PATCH v3 08/14] mfd: max77802: Add DT binding documentation
Add Device Tree binding documentation for Maxim 77802 PMIC.
Signed-off-by: Javier Martinez Canillas
---
Changes since v2:
- Explain better the Dynamic Voltage Scaling (DVS) support in some Buck
regulators and the max77802,pmic-buck-{dvs,selb}-gpios properties.
Suggested by Mark Brown.
Documentation/devicetree/bindings/mfd/max77802.txt | 97 ++
1 file changed, 97 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/max77802.txt
diff --git a/Documentation/devicetree/bindings/mfd/max77802.txt
b/Documentation/devicetree/bindings/mfd/max77802.txt
new file mode 100644
index 000..f3b67c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/max77802.txt
@@ -0,0 +1,97 @@
+Maxim MAX77802 multi-function device
+
+MAX77802 is a Mulitifunction device with PMIC, RTC and Charger on chip. It is
+interfaced to host controller using i2c interface. PMIC, Charger and RTC
+submodules are addressed using same i2c slave address.
+
+Buck regulators 1, 2, 3, 4 and 6 include Dynamic Voltage Scaling (DVS) that
+allows each output voltage to change dynamically. Each Buck output voltage
+is selected using a set of external inputs: DVS1-3 and SELB1, 2, 3 and 6.
+
+There are 8 DVS registers that can be used to configure the output voltage
+for each Buck regulator and which one is active is controled by DVSx lines.
+
+SELBx lines are used to control if individual Buck lines are ON or OFF.
+
+This document describes the binding for mfd device and PMIC submodule.
+
+Binding for the built-in 32k clock generator block is defined separately
+in bindings/clk/maxim,max77802.txt file.
+
+Required properties:
+- compatible : Must be "maxim,max77802";
+- reg : Specifies the i2c slave address of PMIC block.
+- interrupts : This i2c device has an IRQ line connected to the main SoC.
+- interrupt-parent : The parent interrupt controller.
+
+Optional properties:
+- max77802,pmic-buck-default-dvs-idx: We'll always write this DVS index in the
+ PMIC for Bucks with DVS.
+ NOTE: at the moment these bindings don't include enough details for actual
+ GPIO-DVS--this just lets you choose which single slot to use.
+
+- max77802,pmic-buck-dvs-gpios: A GPIO array where each GPIO is connected to a
+ DVS line. We'll try to set these GPIOs to match pmic-buck-default-dvs-idx at
+ probe time if they are defined. If some or all of these GPIOs are not defined
+ it's assumed that the board has any missing GPIOs hardwired to match
+ pmic-buck-default-dvs-idx.
+
+- max77802,pmic-buck-selb-gpios: A GPIO array where each GPIO is connected to a
+ SELBx line. Should be five values: 1, 2, 3, 4, 6. It is strongly suggested to
+ include these GPIOs if there's any chance that changing DVS GPIOs one line at
+ a time might glitch your DVS values.
+
+Optional node:
+- regulators : The regulators of max77802 have to be instantiated
+ under subnode named "regulators" using the following format.
+
+ regulator_name {
+ standard regulator constraints
+ };
+ refer Documentation/devicetree/bindings/regulator/regulator.txt
+
+ The regulator node name should be initialized with a string
+to get matched with their hardware counterparts as follow:
+
+ -LDOn : for LDOs, where n can lie in range 1 to 35.
+ example: LDO1, LDO2, LDO35.
+ -BUCKn : for BUCKs, where n can lie in range 1 to 10.
+ example: BUCK1, BUCK5, BUCK10.
+Example:
+
+ max77802@09 {
+ compatible = "maxim,max77802";
+ interrupt-parent = <&wakeup_eint>;
+ interrupts = <26 0>;
+ reg = <0x09>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ max77802,pmic-buck-default-dvs-idx = <1>;
+ max77802,pmic-buck-dvs-gpios = <&gpy7 6 0>,
+ <&gpj4 2 0>,
+ <&gpj4 3 0>;
+ max77802,pmic-buck-selb-gpios = <&gph0 2 0>,
+ <&gph0 3 0>,
+ <&gph0 4 0>,
+ <&gph0 5 0>,
+ <&gph0 6 0>;
+
+ regulators {
+ ldo11_reg: LDO11 {
+ regulator-compatible = "LDO11";
+ regulator-name = "vdd_ldo11";
+ regulator-min-microvolt = <190>;
+ regulator-max-microvolt = <190>;
+ regulator-always-on;
+ };
+
+ buck1_reg {
+ regulator-compatible = "BUCK1";
+ regulator-name = "vdd_mif";
+ regulator-min-microvolt = <95>;
+ regulator-max-microvolt = <130
[PATCH v3 06/14] clk: max77686: Convert to the generic max clock driver
Clocks drivers for Maxim PMIC are very similar so they can
be converted to use the generic Maxim clock driver.
Also, while being there use module_platform_driver() helper
macro to eliminate more boilerplate code.
Signed-off-by: Javier Martinez Canillas
---
drivers/clk/Kconfig| 1 +
drivers/clk/clk-max77686.c | 176 +++--
2 files changed, 9 insertions(+), 168 deletions(-)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 73f78e8..3fd4270 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -38,6 +38,7 @@ config COMMON_CLK_MAX_GEN
config COMMON_CLK_MAX77686
tristate "Clock driver for Maxim 77686 MFD"
depends on MFD_MAX77686
+ select COMMON_CLK_MAX_GEN
---help---
This driver supports Maxim 77686 crystal oscillator clock.
diff --git a/drivers/clk/clk-max77686.c b/drivers/clk/clk-max77686.c
index 185b611..ed0beb4 100644
--- a/drivers/clk/clk-max77686.c
+++ b/drivers/clk/clk-max77686.c
@@ -31,187 +31,37 @@
#include
#include
-
-struct max77686_clk {
- struct max77686_dev *iodev;
- u32 mask;
- struct clk_hw hw;
- struct clk_lookup *lookup;
-};
-
-static struct max77686_clk *to_max77686_clk(struct clk_hw *hw)
-{
- return container_of(hw, struct max77686_clk, hw);
-}
-
-static int max77686_clk_prepare(struct clk_hw *hw)
-{
- struct max77686_clk *max77686 = to_max77686_clk(hw);
-
- return regmap_update_bits(max77686->iodev->regmap,
- MAX77686_REG_32KHZ, max77686->mask,
- max77686->mask);
-}
-
-static void max77686_clk_unprepare(struct clk_hw *hw)
-{
- struct max77686_clk *max77686 = to_max77686_clk(hw);
-
- regmap_update_bits(max77686->iodev->regmap,
- MAX77686_REG_32KHZ, max77686->mask, ~max77686->mask);
-}
-
-static int max77686_clk_is_prepared(struct clk_hw *hw)
-{
- struct max77686_clk *max77686 = to_max77686_clk(hw);
- int ret;
- u32 val;
-
- ret = regmap_read(max77686->iodev->regmap,
- MAX77686_REG_32KHZ, &val);
-
- if (ret < 0)
- return -EINVAL;
-
- return val & max77686->mask;
-}
-
-static unsigned long max77686_recalc_rate(struct clk_hw *hw,
- unsigned long parent_rate)
-{
- return 32768;
-}
-
-static struct clk_ops max77686_clk_ops = {
- .prepare= max77686_clk_prepare,
- .unprepare = max77686_clk_unprepare,
- .is_prepared= max77686_clk_is_prepared,
- .recalc_rate= max77686_recalc_rate,
-};
+#include "clk-max-gen.h"
static struct clk_init_data max77686_clks_init[MAX77686_CLKS_NUM] = {
[MAX77686_CLK_AP] = {
.name = "32khz_ap",
- .ops = &max77686_clk_ops,
+ .ops = &max_gen_clk_ops,
.flags = CLK_IS_ROOT,
},
[MAX77686_CLK_CP] = {
.name = "32khz_cp",
- .ops = &max77686_clk_ops,
+ .ops = &max_gen_clk_ops,
.flags = CLK_IS_ROOT,
},
[MAX77686_CLK_PMIC] = {
.name = "32khz_pmic",
- .ops = &max77686_clk_ops,
+ .ops = &max_gen_clk_ops,
.flags = CLK_IS_ROOT,
},
};
-static struct clk *max77686_clk_register(struct device *dev,
- struct max77686_clk *max77686)
-{
- struct clk *clk;
- struct clk_hw *hw = &max77686->hw;
-
- clk = clk_register(dev, hw);
- if (IS_ERR(clk))
- return clk;
-
- max77686->lookup = kzalloc(sizeof(struct clk_lookup), GFP_KERNEL);
- if (!max77686->lookup)
- return ERR_PTR(-ENOMEM);
-
- max77686->lookup->con_id = hw->init->name;
- max77686->lookup->clk = clk;
-
- clkdev_add(max77686->lookup);
-
- return clk;
-}
-
static int max77686_clk_probe(struct platform_device *pdev)
{
struct max77686_dev *iodev = dev_get_drvdata(pdev->dev.parent);
- struct max77686_clk *max77686_clks[MAX77686_CLKS_NUM];
- struct clk **clocks;
- int i, ret;
-
- clocks = devm_kzalloc(&pdev->dev, sizeof(struct clk *)
- * MAX77686_CLKS_NUM, GFP_KERNEL);
- if (!clocks)
- return -ENOMEM;
-
- for (i = 0; i < MAX77686_CLKS_NUM; i++) {
- max77686_clks[i] = devm_kzalloc(&pdev->dev,
- sizeof(struct max77686_clk),
GFP_KERNEL);
- if (!max77686_clks[i])
- return -ENOMEM;
- }
-
- for (i = 0; i < MAX77686_CLKS_NUM; i++) {
- max77686_clks[i]->iodev = iodev;
- max77686_clks[i]->mask = 1 << i;
- max77686_clks[i]->hw.init = &max77686_clks_init[i];
-
- clocks[i] = max77686_clk_register(&pdev->dev, max77686_clks[i]);
- if (I
[PATCH v3 07/14] mfd: Add driver for Maxim 77802 Power Management IC
Maxim MAX77802 is a power management chip that contains 10 high
efficiency Buck regulators, 32 Low-dropout (LDO) regulators used
to power up application processors and peripherals, a 2-channel
32kHz clock outputs, a Real-Time-Clock (RTC) and a I2C interface
to program the individual regulators, clocks outputs and the RTC.
This patch adds the core support for MAX77802 PMIC and is based
on a driver added by Simon Glass to the Chrome OS kernel 3.8 tree.
Signed-off-by: Javier Martinez Canillas
---
Changes since v2:
- Split the DT binding docs in a separate patch and improve the documentation.
Suggested by Mark Brown.
- Add all the devices in the MFD driver instead of doing in separate patches.
Suggested by Mark Brown.
Changes since v1:
- Convert max77{686,802} to regmap irq API and get rid of max77{686,802}-irq.c
suggested by Krzysztof Kozlowski.
- Don't protect max77802 mfd_cells using Kconfig options since mfd core omits
devices that don't match. Suggested by Lee Jones.
- Change mfd driver to be tristate instead of boolean. Suggested by Mark Brown.
- Change binding "voltage-regulators" property to "regulators" to be consistent
with other PMIC drivers. Suggested by Mark Brown.
- Use regulators node names instead of the deprecated "regulator-compatible"
property. Suggested by Mark Brown.
- Use the new descriptor-based GPIO interface instead of the deprecated
integer based GPIO one. Suggested by Mark Brown.
- Remove the type parameter from i2c_device_id table since was not used.
- Fix device not found error message and remove unneeded device found message.
drivers/mfd/Kconfig | 14 ++
drivers/mfd/Makefile | 1 +
drivers/mfd/max77802.c | 368 +++
include/linux/mfd/max77802-private.h | 307 +
include/linux/mfd/max77802.h | 124
5 files changed, 814 insertions(+)
create mode 100644 drivers/mfd/max77802.c
create mode 100644 include/linux/mfd/max77802-private.h
create mode 100644 include/linux/mfd/max77802.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 0916447..dcec3b7 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -393,6 +393,20 @@ config MFD_MAX77693
additional drivers must be enabled in order to use the functionality
of the device.
+config MFD_MAX77802
+ tristate "Maxim Integrated MAX77802 PMIC Support"
+ depends on I2C=y
+ select MFD_CORE
+ select REGMAP_I2C
+ select REGMAP_IRQ
+ select IRQ_DOMAIN
+ help
+ Say yes here to support for Maxim Integrated MAX77802.
+ This is a Power Management IC with RTC on chip.
+ This driver provides common support for accessing the device;
+ additional drivers must be enabled in order to use the functionality
+ of the device.
+
config MFD_MAX8907
tristate "Maxim Semiconductor MAX8907 PMIC Support"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 3b3b408..8108ae6 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -117,6 +117,7 @@ obj-$(CONFIG_MFD_DA9063)+= da9063.o
obj-$(CONFIG_MFD_MAX14577) += max14577.o
obj-$(CONFIG_MFD_MAX77686) += max77686.o
obj-$(CONFIG_MFD_MAX77693) += max77693.o max77693-irq.o
+obj-$(CONFIG_MFD_MAX77802) += max77802.o
obj-$(CONFIG_MFD_MAX8907) += max8907.o
max8925-objs := max8925-core.o max8925-i2c.o
obj-$(CONFIG_MFD_MAX8925) += max8925.o
diff --git a/drivers/mfd/max77802.c b/drivers/mfd/max77802.c
new file mode 100644
index 000..7dd1e37
--- /dev/null
+++ b/drivers/mfd/max77802.c
@@ -0,0 +1,368 @@
+/*
+ * max77802.c - mfd core driver for the Maxim 77802
+ *
+ * Copyright (C) 2013-2014 Google, Inc
+ * Simon Glass
+ *
+ * Copyright (C) 2012 Samsung Electronics
+ * Chiwoong Byun
+ * Jonghwa Lee
+ *
+ * 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.
+ *
+ * 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.
+ *
+ * This driver is based on max8997.c
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static const struct mfd_cell max77802_devs[] = {
+ { .name = "max77802-pmic", },
+ { .name = "max77802-clk", },
+ { .name = "max77802-rtc", },
+};
+
+static bool max77802_pmic_is_accessible_reg(struct device *dev,
+ unsigned int reg)
+{
+ return (reg >= MAX77802_REG_DEVICE_ID &&
[PATCH v3 09/14] regmap: Add regmap_reg_copy function
Some device drivers using the register map API need to copy the
value from one register to another. Even though it can be done
with a combination of regmap_read() and regmap_write(), it is
better to have a function to avoid code duplication, sanity check
passed values and do it atomically by holding the regmap lock.
Signed-off-by: Javier Martinez Canillas
---
drivers/base/regmap/regmap.c | 34 ++
include/linux/regmap.h | 9 +
2 files changed, 43 insertions(+)
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 74d8c06..a2e0b04 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -2555,6 +2555,40 @@ int regmap_parse_val(struct regmap *map, const void *buf,
}
EXPORT_SYMBOL_GPL(regmap_parse_val);
+/**
+ * regmap_reg_copy(): Copy a value from a single register to another one
+ *
+ * @map: Register map to operate on
+ * @dest: Register to copy the value to
+ * @src: Register to copy the value from
+ *
+ * A value of zero will be returned on success, a negative errno will
+ * be returned in error cases.
+ */
+int regmap_reg_copy(struct regmap *map, unsigned int dest, unsigned int src)
+{
+ int val;
+ int ret = 0;
+
+ if (dest == src)
+ return ret;
+
+ if (dest % map->reg_stride ||
+ src % map->reg_stride)
+ return -EINVAL;
+
+ map->lock(map->lock_arg);
+
+ ret = _regmap_read(map, src, &val);
+ if (!ret)
+ ret = _regmap_write(map, dest, val);
+
+ map->unlock(map->lock_arg);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(regmap_reg_copy);
+
static int __init regmap_initcall(void)
{
regmap_debugfs_initcall();
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index 7b0e4b4..116c22b 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -445,6 +445,8 @@ int regmap_register_patch(struct regmap *map, const struct
reg_default *regs,
int regmap_parse_val(struct regmap *map, const void *buf,
unsigned int *val);
+int regmap_reg_copy(struct regmap *map, unsigned int dest, unsigned int src);
+
static inline bool regmap_reg_in_range(unsigned int reg,
const struct regmap_range *range)
{
@@ -723,6 +725,13 @@ static inline int regmap_parse_val(struct regmap *map,
const void *buf,
return -EINVAL;
}
+static inline int regmap_reg_copy(struct regmap *map, unsigned int dest,
+ unsigned int src)
+{
+ WARN_ONCE(1, "regmap API is disabled");
+ return -EINVAL;
+}
+
static inline struct regmap *dev_get_regmap(struct device *dev,
const char *name)
{
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 10/14] regulator: Add driver for Maxim 77802 PMIC regulators
The MAX77802 PMIC has 10 high-efficiency Buck and 32 Low-dropout
(LDO) regulators. This patch adds support for all these regulators
found on the MAX77802 PMIC and is based on a driver added by Simon
Glass to the Chrome OS kernel 3.8 tree.
Signed-off-by: Javier Martinez Canillas
---
Changes since v2:
- Use dev_warn() instead pr_warn(). Suggested by Mark Brown.
- Add a generic function to regmap core to copy registers instead of
having a driver-specific function. Suggested by Mark Brown.
- Remove unnecessary probe debug log. Suggested by Mark Brown.
- Set struct regulator_config dev field to MFD instead of the platform dev.
Suggested by Mark Brown.
- Read the regulators operational mode from the hardware registers instead
of setting to normal as default on probe. Suggested by Mark Brown.
- Remove unnecessary cross-subsystem dependencies. Suggested by Lee Jones.
Changes since v1:
- Remove unneeded check if num_regulators != MAX77802_MAX_REGULATORS.
- Fix .set_suspend_mode handler comment and split regulators ops for
regulators that behave differently. Suggested by Mark Brown.
- Use module_platform_driver() instead of having init/exit functions.
Suggested by Mark Brown.
- Use the new descriptor-based GPIO interface instead of the deprecated
integer based GPIO one. Suggested by Mark Brown.
- Look for "regulators" child node instead of "voltage-regulators" to be
consistent with other PMIC drivers. Suggested by Mark Brown.
drivers/regulator/Kconfig| 9 +
drivers/regulator/Makefile | 1 +
drivers/regulator/max77802.c | 691 +++
3 files changed, 701 insertions(+)
create mode 100644 drivers/regulator/max77802.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 789eb46..17873d3 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -377,6 +377,15 @@ config REGULATOR_MAX77693
and one current regulator 'CHARGER'. This is suitable for
Exynos-4x12 chips.
+config REGULATOR_MAX77802
+ tristate "Maxim 77802 regulator"
+ depends on MFD_MAX77802
+ help
+ This driver controls a Maxim 77802 regulator
+ via I2C bus. The provided regulator is suitable for
+ Exynos-5 chips to control various voltages. It includes
+ support for control of voltage and ramp speed.
+
config REGULATOR_MC13XXX_CORE
tristate
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index d461110..2aea4b6 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -51,6 +51,7 @@ obj-$(CONFIG_REGULATOR_MAX8997) += max8997.o
obj-$(CONFIG_REGULATOR_MAX8998) += max8998.o
obj-$(CONFIG_REGULATOR_MAX77686) += max77686.o
obj-$(CONFIG_REGULATOR_MAX77693) += max77693.o
+obj-$(CONFIG_REGULATOR_MAX77802) += max77802.o
obj-$(CONFIG_REGULATOR_MC13783) += mc13783-regulator.o
obj-$(CONFIG_REGULATOR_MC13892) += mc13892-regulator.o
obj-$(CONFIG_REGULATOR_MC13XXX_CORE) += mc13xxx-regulator-core.o
diff --git a/drivers/regulator/max77802.c b/drivers/regulator/max77802.c
new file mode 100644
index 000..79dc4aa
--- /dev/null
+++ b/drivers/regulator/max77802.c
@@ -0,0 +1,691 @@
+/*
+ * max77802.c - Regulator driver for the Maxim 77802
+ *
+ * Copyright (C) 2013-2014 Google, Inc
+ * Simon Glass
+ *
+ * Copyright (C) 2012 Samsung Electronics
+ * Chiwoong Byun
+ * Jonghwa Lee
+ *
+ * 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.
+ *
+ * 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.
+ *
+ * This driver is based on max8997.c
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Default ramp delay in case it is not manually set */
+#define MAX77802_RAMP_DELAY10 /* uV/us */
+
+#define MAX77802_OPMODE_SHIFT_LDO 6
+#define MAX77802_OPMODE_BUCK234_SHIFT 4
+#define MAX77802_OPMODE_MASK 0x3
+
+#define MAX77802_VSEL_MASK 0x3F
+#define MAX77802_DVS_VSEL_MASK 0xFF
+
+#define MAX77802_RAMP_RATE_MASK_2BIT 0xC0
+#define MAX77802_RAMP_RATE_SHIFT_2BIT 6
+#define MAX77802_RAMP_RATE_MASK_4BIT 0xF0
+#define MAX77802_RAMP_RATE_SHIFT_4BIT 4
+
+/* LDO16, LDO22 and LDO31 are not available on MAX77802 */
+#define MAX77802_MAX_REGULATORS(MAX77802_REG_MAX - 3)
+
+/* MAX77802 has two register formats: 2-bit and 4-bit */
+static const unsigned int ramp_table_77802_2bit[] = {
+ 12500,
+ 25000,
+ 5,
+ 10,
+};
+
+static unsigned int ramp_table_77802_4bit[] = {
+
[PATCH v3 11/14] clk: Add driver for Maxim 77802 PMIC clocks
The MAX77802 PMIC has two 32.768kHz Buffered Clock Outputs with
Low Jitter Mode. This patch adds support for these two clocks.
Signed-off-by: Javier Martinez Canillas
---
Changes since v2: None
Changes since v1:
- Use module_platform_driver() instead of having init/exit functions.
Suggested by Mark Brown.
- Use the generic maxim clock driver to reduce code duplication with
clk-max77686.c driver.
drivers/clk/Kconfig| 7 +++
drivers/clk/Makefile | 1 +
drivers/clk/clk-max77802.c | 99 ++
include/dt-bindings/clock/maxim,max77802.h | 22 +++
4 files changed, 129 insertions(+)
create mode 100644 drivers/clk/clk-max77802.c
create mode 100644 include/dt-bindings/clock/maxim,max77802.h
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 3fd4270..221260b 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -42,6 +42,13 @@ config COMMON_CLK_MAX77686
---help---
This driver supports Maxim 77686 crystal oscillator clock.
+config COMMON_CLK_MAX77802
+ tristate "Clock driver for Maxim 77802 MFD"
+ depends on MFD_MAX77802
+ select COMMON_CLK_MAX_GEN
+ ---help---
+ This driver supports Maxim 77802 crystal oscillator clock.
+
config COMMON_CLK_SI5351
tristate "Clock driver for SiLabs 5351A/B/C"
depends on I2C
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 6c1aff6..520ff76 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_ARCH_HIGHBANK) += clk-highbank.o
obj-$(CONFIG_MACH_LOONGSON1) += clk-ls1x.o
obj-$(CONFIG_COMMON_CLK_MAX_GEN) += clk-max-gen.o
obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
+obj-$(CONFIG_COMMON_CLK_MAX77802) += clk-max77802.o
obj-$(CONFIG_ARCH_MOXART) += clk-moxart.o
obj-$(CONFIG_ARCH_NOMADIK) += clk-nomadik.o
obj-$(CONFIG_ARCH_NSPIRE) += clk-nspire.o
diff --git a/drivers/clk/clk-max77802.c b/drivers/clk/clk-max77802.c
new file mode 100644
index 000..4253b44
--- /dev/null
+++ b/drivers/clk/clk-max77802.c
@@ -0,0 +1,99 @@
+/*
+ * clk-max77802.c - Clock driver for Maxim 77802
+ *
+ * Copyright (C) 2014 Google, Inc
+ *
+ * Copyright (C) 2012 Samsung Electornics
+ * Jonghwa Lee
+ *
+ * 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.
+ *
+ * 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.
+ *
+ * This driver is based on clk-max77686.c
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include "clk-max-gen.h"
+
+#define MAX77802_CLOCK_OPMODE_MASK 0x1
+#define MAX77802_CLOCK_LOW_JITTER_SHIFT 0x3
+
+static struct clk_init_data max77802_clks_init[MAX77802_CLKS_NUM] = {
+ [MAX77802_CLK_32K_AP] = {
+ .name = "32khz_ap",
+ .ops = &max_gen_clk_ops,
+ .flags = CLK_IS_ROOT,
+ },
+ [MAX77802_CLK_32K_CP] = {
+ .name = "32khz_cp",
+ .ops = &max_gen_clk_ops,
+ .flags = CLK_IS_ROOT,
+ },
+};
+
+static int max77802_clk_probe(struct platform_device *pdev)
+{
+ struct max77802_dev *iodev = dev_get_drvdata(pdev->dev.parent);
+ int ret;
+
+ ret = max_gen_clk_probe(pdev, iodev->regmap, MAX77802_REG_32KHZ,
+ max77802_clks_init, MAX77802_CLKS_NUM);
+
+ if (ret) {
+ dev_err(&pdev->dev, "generic probe failed %d\n", ret);
+ return ret;
+ }
+
+ /* Enable low-jitter mode on the 32khz clocks. */
+ ret = regmap_update_bits(iodev->regmap, MAX77802_REG_32KHZ,
+1 << MAX77802_CLOCK_LOW_JITTER_SHIFT,
+1 << MAX77802_CLOCK_LOW_JITTER_SHIFT);
+ if (ret < 0)
+ dev_err(&pdev->dev, "failed to enable low-jitter mode\n");
+
+ return ret;
+}
+
+static int max77802_clk_remove(struct platform_device *pdev)
+{
+ return max_gen_clk_remove(pdev, MAX77802_CLKS_NUM);
+}
+
+static const struct platform_device_id max77802_clk_id[] = {
+ { "max77802-clk", 0},
+ { },
+};
+MODULE_DEVICE_TABLE(platform, max77802_clk_id);
+
+static struct platform_driver max77802_clk_driver = {
+ .driver = {
+ .name = "max77802-clk",
+ .owner = THIS_MODULE,
+ },
+ .probe = max77802_clk_probe,
+ .remove = max77802_clk_remove,
+ .id_table = max77802_clk_id,
+};
+
+module_platform_driver(max77802_clk_drive
[PATCH v3 12/14] clk: max77802: Add DT binding documentation
Add Device Tree binding documentation for the clocks
outputs in the Maxim 77802 Power Management IC.
Signed-off-by: Javier Martinez Canillas
---
Changes since v2:
- Split the DT binding documentation in a separate patch.
.../devicetree/bindings/clock/maxim,max77802.txt | 42 ++
1 file changed, 42 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/maxim,max77802.txt
diff --git a/Documentation/devicetree/bindings/clock/maxim,max77802.txt
b/Documentation/devicetree/bindings/clock/maxim,max77802.txt
new file mode 100644
index 000..b2c2129
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/maxim,max77802.txt
@@ -0,0 +1,42 @@
+Binding for Maxim MAX77802 32k clock generator block
+
+This is a part of device tree bindings of MAX77802 multi-function device.
+More information can be found in bindings/mfd/max77802.txt file.
+
+The MAX77802 contains two 32.768khz clock outputs that can be controlled
+(gated/ungated) over I2C.
+
+Following properties should be presend in main device node of the MFD chip.
+
+Required properties:
+
+- #clock-cells: from common clock binding; shall be set to 1.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. Following indices are allowed:
+ - 0: 32khz_ap clock,
+ - 1: 32khz_cp clock.
+
+Clocks are defined as preprocessor macros in dt-bindings/clock/maxim,max77802.h
+header and can be used in device tree sources.
+
+Example: Node of the MFD chip
+
+ max77802: max77802@09 {
+ compatible = "maxim,max77802";
+ interrupt-parent = <&wakeup_eint>;
+ interrupts = <26 0>;
+ reg = <0x09>;
+ #clock-cells = <1>;
+
+ /* ... */
+ };
+
+Example: Clock consumer node
+
+ foo@0 {
+ compatible = "bar,foo";
+ /* ... */
+ clock-names = "32khz_ap";
+ clocks = <&max77802 MAX77802_CLK_32K_AP>;
+ };
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 13/14] rtc: Add driver for Maxim 77802 PMIC Real-Time-Clock
The MAX7802 PMIC has a Real-Time-Clock (RTC) with two alarms.
This patch adds support for the RTC and is based on a driver
added by Simon Glass to the Chrome OS kernel 3.8 tree.
Signed-off-by: Javier Martinez Canillas
---
drivers/rtc/Kconfig| 10 +
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-max77802.c | 637 +
3 files changed, 648 insertions(+)
create mode 100644 drivers/rtc/rtc-max77802.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 0754f5c..e0b6495 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -288,6 +288,16 @@ config RTC_DRV_MAX77686
This driver can also be built as a module. If so, the module
will be called rtc-max77686.
+config RTC_DRV_MAX77802
+ tristate "Maxim MAX77802"
+ depends on MFD_MAX77802
+ help
+ If you say yes here you will get support for the
+ RTC of Maxim MAX77802 PMIC.
+
+ This driver can also be built as a module. If so, the module
+ will be called rtc-max77802.
+
config RTC_DRV_RS5C372
tristate "Ricoh R2025S/D, RS5C372A/B, RV5C386, RV5C387A"
help
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 70347d0..247de78 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -81,6 +81,7 @@ obj-$(CONFIG_RTC_DRV_MAX8998) += rtc-max8998.o
obj-$(CONFIG_RTC_DRV_MAX8997) += rtc-max8997.o
obj-$(CONFIG_RTC_DRV_MAX6902) += rtc-max6902.o
obj-$(CONFIG_RTC_DRV_MAX77686) += rtc-max77686.o
+obj-$(CONFIG_RTC_DRV_MAX77802) += rtc-max77802.o
obj-$(CONFIG_RTC_DRV_MC13XXX) += rtc-mc13xxx.o
obj-$(CONFIG_RTC_DRV_MCP795) += rtc-mcp795.o
obj-$(CONFIG_RTC_DRV_MSM6242) += rtc-msm6242.o
diff --git a/drivers/rtc/rtc-max77802.c b/drivers/rtc/rtc-max77802.c
new file mode 100644
index 000..7e5d031
--- /dev/null
+++ b/drivers/rtc/rtc-max77802.c
@@ -0,0 +1,637 @@
+/*
+ * RTC driver for Maxim MAX77802
+ *
+ * Copyright (C) 2013 Google, Inc
+ *
+ * Copyright (C) 2012 Samsung Electronics Co.Ltd
+ *
+ * based on rtc-max8997.c
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* RTC Control Register */
+#define BCD_EN_SHIFT 0
+#define BCD_EN_MASK(1 << BCD_EN_SHIFT)
+#define MODEL24_SHIFT 1
+#define MODEL24_MASK (1 << MODEL24_SHIFT)
+/* RTC Update Register1 */
+#define RTC_UDR_SHIFT 0
+#define RTC_UDR_MASK (1 << RTC_UDR_SHIFT)
+#define RTC_RBUDR_SHIFT4
+#define RTC_RBUDR_MASK (1 << RTC_RBUDR_SHIFT)
+/* WTSR and SMPL Register */
+#define WTSRT_SHIFT0
+#define SMPLT_SHIFT2
+#define WTSR_EN_SHIFT 6
+#define SMPL_EN_SHIFT 7
+#define WTSRT_MASK (3 << WTSRT_SHIFT)
+#define SMPLT_MASK (3 << SMPLT_SHIFT)
+#define WTSR_EN_MASK (1 << WTSR_EN_SHIFT)
+#define SMPL_EN_MASK (1 << SMPL_EN_SHIFT)
+/* RTC Hour register */
+#define HOUR_PM_SHIFT 6
+#define HOUR_PM_MASK (1 << HOUR_PM_SHIFT)
+/* RTC Alarm Enable */
+#define ALARM_ENABLE_SHIFT 7
+#define ALARM_ENABLE_MASK (1 << ALARM_ENABLE_SHIFT)
+
+/* For the RTCAE1 register, we write this value to enable the alarm */
+#define ALARM_ENABLE_VALUE 0x77
+
+#define MAX77802_RTC_UPDATE_DELAY_US 200
+#undef MAX77802_RTC_WTSR_SMPL
+
+enum {
+ RTC_SEC = 0,
+ RTC_MIN,
+ RTC_HOUR,
+ RTC_WEEKDAY,
+ RTC_MONTH,
+ RTC_YEAR,
+ RTC_DATE,
+ RTC_NR_TIME
+};
+
+struct max77802_rtc_info {
+ struct device *dev;
+ struct max77802_dev *max77802;
+ struct i2c_client *rtc;
+ struct rtc_device *rtc_dev;
+ struct mutexlock;
+
+ struct regmap *regmap;
+
+ int virq;
+ int rtc_24hr_mode;
+};
+
+enum MAX77802_RTC_OP {
+ MAX77802_RTC_WRITE,
+ MAX77802_RTC_READ,
+};
+
+static inline int max77802_rtc_calculate_wday(u8 shifted)
+{
+ int counter = -1;
+
+ while (shifted) {
+ shifted >>= 1;
+ counter++;
+ }
+
+ return counter;
+}
+
+static void max77802_rtc_data_to_tm(u8 *data, struct rtc_time *tm,
+ int rtc_24hr_mode)
+{
+ tm->tm_sec = data[RTC_SEC] & 0xff;
+ tm->tm_min = data[RTC_MIN] & 0xff;
+ if (rtc_24hr_mode)
+ tm->tm_hour = data[RTC_HOUR] & 0x1f;
+ else {
+ tm->tm_hour = data[RTC_HOUR] & 0x0f;
+ if (data[RTC_HOUR
[PATCH v3 14/14] ARM: dts: Add max77802 device node for exynos5420-peach-pit
Peach pit board uses a Maxim 77802 power management IC to
drive regulators and its Real Time Clock. This patch adds
support for this chip.
These are the device nodes and pinctrl configuration that
is present on the Peach pit DeviceTree source file in the
the Chrome OS kernel 3.8 tree.
Signed-off-by: Javier Martinez Canillas
---
Changes since v2: None
Changes since v1:
- Use "regulators" for child node instead of "voltage-regulators" to be
consistent with other PMIC. Suggested by Mark Brown.
- Use regulators node names instead of the deprecated "regulator-compatible"
property. Suggested by Mark Brown.
arch/arm/boot/dts/exynos5420-peach-pit.dts | 320 +
1 file changed, 320 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 1c5b8f9..e6dc972 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -111,6 +111,13 @@
samsung,pin-drv = <0>;
};
+ max77802_irq: max77802-irq {
+ samsung,pins = "gpx3-1";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
hdmi_hpd_irq: hdmi-hpd-irq {
samsung,pins = "gpx3-7";
samsung,pin-function = <0>;
@@ -124,6 +131,29 @@
samsung,pin-pud = <3>;
samsung,pin-drv = <0>;
};
+
+ pmic_dvs_1: pmic-dvs-1 {
+ samsung,pins = "gpy7-6";
+ samsung,pin-function = <1>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+};
+
+&pinctrl_2 {
+ pmic_dvs_2: pmic-dvs-2 {
+ samsung,pins = "gpj4-2";
+ samsung,pin-function = <1>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ pmic_dvs_3: pmic-dvs-3 {
+ samsung,pins = "gpj4-3";
+ samsung,pin-function = <1>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
};
&pinctrl_3 {
@@ -140,6 +170,14 @@
samsung,pin-pud = <0>;
samsung,pin-drv = <0>;
};
+
+ pmic_selb: pmic-selb {
+ samsung,pins = "gph0-2", "gph0-3", "gph0-4", "gph0-5",
+ "gph0-6";
+ samsung,pin-function = <1>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
};
&rtc {
@@ -189,6 +227,288 @@
};
};
+&hsi2c_4 {
+ status = "okay";
+ clock-frequency = <40>;
+
+ max77802-pmic@9 {
+ compatible = "maxim,max77802";
+ interrupt-parent = <&gpx3>;
+ interrupts = <1 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&max77802_irq>, <&pmic_selb>,
+ <&pmic_dvs_1>, <&pmic_dvs_2>, <&pmic_dvs_3>;
+ wakeup-source;
+ reg = <0x9>;
+ #clock-cells = <1>;
+
+ /* Using idx 1 means warm reset will get good voltage */
+ max77802,pmic-buck-default-dvs-idx = <1>;
+ max77802,pmic-buck-dvs-gpios = <&gpy7 6 0>,
+ <&gpj4 2 0>,
+ <&gpj4 3 0>;
+ max77802,pmic-buck-selb-gpios = <&gph0 2 0>,
+ <&gph0 3 0>,
+ <&gph0 4 0>,
+ <&gph0 5 0>,
+ <&gph0 6 0>;
+
+ regulators {
+ ldo1_reg: LDO1 {
+ regulator-name = "vdd_1v0";
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <100>;
+ regulator-always-on;
+ };
+ ldo2_reg: LDO2 {
+ regulator-name = "vdd_1v2_2";
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <120>;
+ };
+ ldo3_reg: LDO3 {
+ regulator-name = "vdd_1v8_3";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+ vqmmc_sdcard: ldo4_reg: LDO4 {
+ regulator-name = "vdd_sd";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <280>;
+ regulator-always-on;
+ };
+
[PATCH v3 00/14] Add Maxim 77802 PMIC support
MAX77802 is a PMIC that contains 10 high efficiency Buck regulators, 32 Low-dropout (LDO) regulators, two 32kHz buffered clock outputs, a Real-Time-Clock (RTC) and a I2C interface to program the individual regulators, clocks and the RTC. This third version of the patch-set addresses several issues pointed out by Mark Brown, Lee Jones and Doug Anderson. The individual changes are added on each patch change log. This series are based on drivers added by Simon Glass to the Chrome OS kernel and adds support for the Maxim 77802 Power Management IC, their regulators, clocks, RTC and I2C interface. The patch-set has been tested on both Daisy/Snow (max77686) and Peach pit (max77802) Chromebooks and it's composed of the following patches: Doug Anderson (1): mfd: max77686: Allow the max77686 rtc to wakeup the system Javier Martinez Canillas (13): mfd: max77686: Convert to use regmap_irq clk: max77686: Add DT include for MAX77686 PMIC clock clk: max77686: Improve Maxim 77686 PMIC clocks binding clk: Add generic driver for Maxim PMIC clocks clk: max77686: Convert to the generic max clock driver mfd: Add driver for Maxim 77802 Power Management IC mfd: max77802: Add DT binding documentation regmap: Add regmap_reg_copy function regulator: Add driver for Maxim 77802 PMIC regulators clk: Add driver for Maxim 77802 PMIC clocks clk: max77802: Add DT binding documentation rtc: Add driver for Maxim 77802 PMIC Real-Time-Clock ARM: dts: Add max77802 device node for exynos5420-peach-pit .../devicetree/bindings/clock/maxim,max77686.txt | 15 +- .../devicetree/bindings/clock/maxim,max77802.txt | 42 ++ Documentation/devicetree/bindings/mfd/max77802.txt | 97 +++ arch/arm/boot/dts/exynos5420-peach-pit.dts | 320 ++ drivers/base/regmap/regmap.c | 34 + drivers/clk/Kconfig| 11 + drivers/clk/Makefile | 2 + drivers/clk/clk-max-gen.c | 197 ++ drivers/clk/clk-max-gen.h | 32 + drivers/clk/clk-max77686.c | 183 +- drivers/clk/clk-max77802.c | 99 +++ drivers/mfd/Kconfig| 15 + drivers/mfd/Makefile | 3 +- drivers/mfd/max77686-irq.c | 319 -- drivers/mfd/max77686.c | 97 ++- drivers/mfd/max77802.c | 368 +++ drivers/regulator/Kconfig | 9 + drivers/regulator/Makefile | 1 + drivers/regulator/max77802.c | 691 + drivers/rtc/Kconfig| 10 + drivers/rtc/Makefile | 1 + drivers/rtc/rtc-max77686.c | 55 +- drivers/rtc/rtc-max77802.c | 637 +++ include/dt-bindings/clock/maxim,max77686.h | 23 + include/dt-bindings/clock/maxim,max77802.h | 22 + include/linux/mfd/max77686-private.h | 28 +- include/linux/mfd/max77686.h | 2 - include/linux/mfd/max77802-private.h | 307 + include/linux/mfd/max77802.h | 124 include/linux/regmap.h | 9 + 30 files changed, 3221 insertions(+), 532 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/maxim,max77802.txt create mode 100644 Documentation/devicetree/bindings/mfd/max77802.txt create mode 100644 drivers/clk/clk-max-gen.c create mode 100644 drivers/clk/clk-max-gen.h create mode 100644 drivers/clk/clk-max77802.c delete mode 100644 drivers/mfd/max77686-irq.c create mode 100644 drivers/mfd/max77802.c create mode 100644 drivers/regulator/max77802.c create mode 100644 drivers/rtc/rtc-max77802.c create mode 100644 include/dt-bindings/clock/maxim,max77686.h create mode 100644 include/dt-bindings/clock/maxim,max77802.h create mode 100644 include/linux/mfd/max77802-private.h create mode 100644 include/linux/mfd/max77802.h -- 2.0.0.rc2 -- 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] clocksource: exynos_mct: Fix ftrace
In (93bfb76 clocksource: exynos_mct: register sched_clock callback) we
supported using the MCT as a scheduler clock. We properly marked
exynos4_read_sched_clock() as notrace. However, we then went and
called another function that _wasn't_ notrace. That means if you do:
cd /sys/kernel/debug/tracing/
echo function_graph > current_tracer
You'll get a crash.
Fix this (but still let other readers of the MCT be trace-enabled) by
adding an extra function. It's important to keep other users of MCT
traceable because the MCT is actually quite slow to access and we want
exynos4_frc_read() to show up in ftrace profiles if it's the
bottleneck.
Signed-off-by: Doug Anderson
---
Changes in v2:
- Split out from other patches so this can go into 3.16.
- Better comment about why exynos4_frc_read() should be traceable.
- No more useless inline.
drivers/clocksource/exynos_mct.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index f71d55f..5ce99c0 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -162,7 +162,7 @@ static void exynos4_mct_frc_start(void)
exynos4_mct_write(reg, EXYNOS4_MCT_G_TCON);
}
-static cycle_t exynos4_frc_read(struct clocksource *cs)
+static cycle_t notrace _exynos4_frc_read(void)
{
unsigned int lo, hi;
u32 hi2 = __raw_readl(reg_base + EXYNOS4_MCT_G_CNT_U);
@@ -176,6 +176,11 @@ static cycle_t exynos4_frc_read(struct clocksource *cs)
return ((cycle_t)hi << 32) | lo;
}
+static cycle_t exynos4_frc_read(struct clocksource *cs)
+{
+ return _exynos4_frc_read();
+}
+
static void exynos4_frc_resume(struct clocksource *cs)
{
exynos4_mct_frc_start();
@@ -192,7 +197,7 @@ struct clocksource mct_frc = {
static u64 notrace exynos4_read_sched_clock(void)
{
- return exynos4_frc_read(&mct_frc);
+ return _exynos4_frc_read();
}
static void __init exynos4_clocksource_init(void)
--
2.0.0.526.g5318336
--
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] clocksource: exynos_mct: Fix ftrace
Daniel, On Tue, Jun 17, 2014 at 5:13 AM, Daniel Lezcano wrote: > On 06/04/2014 07:30 PM, Doug Anderson wrote: >> >> In (93bfb76 clocksource: exynos_mct: register sched_clock callback) we >> supported using the MCT as a scheduler clock. We properly marked >> exynos4_read_sched_clock() as notrace. However, we then went and >> called another function that _wasn't_ notrace. That means if you do: >> >>cd /sys/kernel/debug/tracing/ >>echo function_graph > current_tracer >> >> You'll get a crash. >> >> Fix this (but still let other readers of the MCT be trace-enabled) by >> adding an extra function. It's important to keep other users of MCT >> traceable because the MCT is actually quite slow. > > > Thanks for the explanation in the other email. > > I think the last sentence is a bit confusing because you are implicitly > saying you need these traces to investigate why the timer is slow which is > referring to something not related to this fix. Done >> Signed-off-by: Doug Anderson >> --- >> drivers/clocksource/exynos_mct.c | 9 +++-- >> 1 file changed, 7 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/clocksource/exynos_mct.c >> b/drivers/clocksource/exynos_mct.c >> index 8d64200..ba3a683 100644 >> --- a/drivers/clocksource/exynos_mct.c >> +++ b/drivers/clocksource/exynos_mct.c >> @@ -165,7 +165,7 @@ static void exynos4_mct_frc_start(u32 hi, u32 lo) >> exynos4_mct_write(reg, EXYNOS4_MCT_G_TCON); >> } >> >> -static cycle_t exynos4_frc_read(struct clocksource *cs) >> +static inline cycle_t notrace _exynos4_frc_read(void) > > > Why inline ? Somehow I thought that without the "inline" that somehow exynos4_frc_read() would not be traceable. ...but this makes no sense so I've removed. -- 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] clocksource: exynos-mct: Register the timer for stable udelay
On 19.06.2014 18:31, Doug Anderson wrote:
> Tomasz,
>
> On Thu, Jun 19, 2014 at 9:17 AM, Tomasz Figa wrote:
>> On 19.06.2014 18:01, Doug Anderson wrote:
>>> Hi,
>>>
>>> On Thu, Jun 19, 2014 at 3:21 AM, Tomasz Figa wrote:
> +static struct delay_timer exynos4_delay_timer;
> +
> +static unsigned long exynos4_read_current_timer(void)
>>>
>>> Note: I think this should return a cycles_t, not an unsigned long.
>>> They're the same (right now), but probably shouldn't be (see below).
>>>
>>>
> +{
> +#ifdef ARM
> + return __raw_readl(reg_base + EXYNOS4_MCT_G_CNT_L);
> +#else /* ARM64, etc */
> + return exynos4_frc_read(&mct_frc);
> +#endif
> +}
> +
No need for anything like this. Even if running on ARM64, the delay
timer code should be able to cope with different timer widths. For
delays, 32 bits are enough, so just always read the lower part.
>>>
>>> I agree that the timer code should cope but it doesn't appear to. I see:
>>>
>>> cycles_t start = get_cycles();
>>> while ((get_cycles() - start) < cycles)
>>> cpu_relax();
>>>
>>> Right now cycles_t is defined as "unsigned long". If that's 64-bits
>>> on ARM64 then this function will have problems with wraparound.
>>
>> Well, first of all, I'm not sure why we're discussing ARM64 here, if it
>> doesn't have support for register_current_timer_delay() at all.
>> Moreover, the only user if it is ARM32 and, if I remember correctly, the
>> assumption was that you need a >= 32 bit timer to use it for delays and
>> so with 32 bit unsigned long everything should work. Now if ARM64 also
>> wants to use this infrastructure, instead of hacking drivers now and
>> encouraging ARM64 people to continue using this kind of hackery, I
>> believe we should indicate that ARM64 delay timer code needs to be
>> implemented correctly and cope for different timer widths.
>>
>> Of course the best way would be to redesign this interface right now to
>> consider time width (it is not just about 32 or 64 bits, there are
>> various timers, possibly 48- or 52-bit) and change ARM32 implementation
>> of it as well, if there are any volunteers.
>
> I was arguing that it was a lot of extra complexity to add to the code
> to support different timer sizes for udelay when 32-bits is enough
> (and it's trivial for timer implementations to truncate down to
> 32-bits).
>
>
>> Changing the code to always
>> use 32-bit type regardless of arch is also an option.
>
> Right, that's what I was arguing for.
>
>
>>> My personal vote would be to submit a patch to change "cycles_t" to
>>> always be 32-bits. Given that 32-bits was fine for udelay() for ARM
>>> that seems sane and simple. If someone later comes up with a super
>>> compelling reason why we need 64-bit timers for udelay (really??) then
>>> they can later add all the complexity needed.
>>
>> Yes, this could work. I'm not sure what else cycles_t is used for, though.
>
> True, it is a bit questionable to change this since it's a type that's
> not obviously just for udelay(). Perhaps a better option would be to
> make a new typedef for the result of read_current_timer(). ...or just
> change it to return a u32?
>
Sounds good to me, but let's hear other opinions. I'm adding Will and
Jonathan as they wrote the ARM delay timer code.
>
>>> Amit: can you code up such a patch and add it to the series? I know
>>> it changes code that touches all ARM devices but I still think it's
>>> the right thing to do and actually only really changes behavior on
>>> ARM64.
>>>
>>>
Also use of raw accessors in drivers is discouraged - please use
readl_relaxed().
>>>
>>> It doesn't seem like that should happen in the same patch. Perhaps
>>> Amit can do a cleanup patch first that changes all instances of
>>> __raw_readl / __raw_writel in this file, then submit his patch atop
>>> that.
>>
>> Why not? The patch adding exynos4_read_current_timer() (and so the call
>> to __raw_readl() was Amit's patch. I'm not asking to fix this in the
>> whole driver, just to do things correctly in new code.
>
> IMHO consistency within a file is more important. Having a single
> readl_relaxed() in a file that uses all __raw_readl() doesn't seem
> beneficial to me. ...but I certainly won't NAK the patch if that's
> what others want.
>
It depends whether you prefer consistency over correctness or the other
way around. I should have marked this comment as a nitpick. :)
>
Btw. I don't even see support for this on ARM64 in mainline, where arch
timer is always used for delays and AFAIK this is a platform requirement.
>>>
>>> Yeah, I'd vote for not using MCT on ARM64, but it I suppose it doesn't
>>> hurt to keep it working.
>>
>> Right now there is no need for this, so let's just keep things simple.
>
> It should at least have a comment saying that it's broken in subtle
> ways (only on udelays that happen to span the 32-bit wraparound) on
> anything where cycle_t is not 32-bits. Pe
Re: [PATCH v2] clocksource: exynos-mct: Register the timer for stable udelay
Tomasz,
On Thu, Jun 19, 2014 at 9:17 AM, Tomasz Figa wrote:
> On 19.06.2014 18:01, Doug Anderson wrote:
>> Hi,
>>
>> On Thu, Jun 19, 2014 at 3:21 AM, Tomasz Figa wrote:
+static struct delay_timer exynos4_delay_timer;
+
+static unsigned long exynos4_read_current_timer(void)
>>
>> Note: I think this should return a cycles_t, not an unsigned long.
>> They're the same (right now), but probably shouldn't be (see below).
>>
>>
+{
+#ifdef ARM
+ return __raw_readl(reg_base + EXYNOS4_MCT_G_CNT_L);
+#else /* ARM64, etc */
+ return exynos4_frc_read(&mct_frc);
+#endif
+}
+
>>>
>>> No need for anything like this. Even if running on ARM64, the delay
>>> timer code should be able to cope with different timer widths. For
>>> delays, 32 bits are enough, so just always read the lower part.
>>
>> I agree that the timer code should cope but it doesn't appear to. I see:
>>
>> cycles_t start = get_cycles();
>> while ((get_cycles() - start) < cycles)
>> cpu_relax();
>>
>> Right now cycles_t is defined as "unsigned long". If that's 64-bits
>> on ARM64 then this function will have problems with wraparound.
>
> Well, first of all, I'm not sure why we're discussing ARM64 here, if it
> doesn't have support for register_current_timer_delay() at all.
> Moreover, the only user if it is ARM32 and, if I remember correctly, the
> assumption was that you need a >= 32 bit timer to use it for delays and
> so with 32 bit unsigned long everything should work. Now if ARM64 also
> wants to use this infrastructure, instead of hacking drivers now and
> encouraging ARM64 people to continue using this kind of hackery, I
> believe we should indicate that ARM64 delay timer code needs to be
> implemented correctly and cope for different timer widths.
>
> Of course the best way would be to redesign this interface right now to
> consider time width (it is not just about 32 or 64 bits, there are
> various timers, possibly 48- or 52-bit) and change ARM32 implementation
> of it as well, if there are any volunteers.
I was arguing that it was a lot of extra complexity to add to the code
to support different timer sizes for udelay when 32-bits is enough
(and it's trivial for timer implementations to truncate down to
32-bits).
> Changing the code to always
> use 32-bit type regardless of arch is also an option.
Right, that's what I was arguing for.
>> My personal vote would be to submit a patch to change "cycles_t" to
>> always be 32-bits. Given that 32-bits was fine for udelay() for ARM
>> that seems sane and simple. If someone later comes up with a super
>> compelling reason why we need 64-bit timers for udelay (really??) then
>> they can later add all the complexity needed.
>
> Yes, this could work. I'm not sure what else cycles_t is used for, though.
True, it is a bit questionable to change this since it's a type that's
not obviously just for udelay(). Perhaps a better option would be to
make a new typedef for the result of read_current_timer(). ...or just
change it to return a u32?
>> Amit: can you code up such a patch and add it to the series? I know
>> it changes code that touches all ARM devices but I still think it's
>> the right thing to do and actually only really changes behavior on
>> ARM64.
>>
>>
>>> Also use of raw accessors in drivers is discouraged - please use
>>> readl_relaxed().
>>
>> It doesn't seem like that should happen in the same patch. Perhaps
>> Amit can do a cleanup patch first that changes all instances of
>> __raw_readl / __raw_writel in this file, then submit his patch atop
>> that.
>
> Why not? The patch adding exynos4_read_current_timer() (and so the call
> to __raw_readl() was Amit's patch. I'm not asking to fix this in the
> whole driver, just to do things correctly in new code.
IMHO consistency within a file is more important. Having a single
readl_relaxed() in a file that uses all __raw_readl() doesn't seem
beneficial to me. ...but I certainly won't NAK the patch if that's
what others want.
>>> Btw. I don't even see support for this on ARM64 in mainline, where arch
>>> timer is always used for delays and AFAIK this is a platform requirement.
>>
>> Yeah, I'd vote for not using MCT on ARM64, but it I suppose it doesn't
>> hurt to keep it working.
>
> Right now there is no need for this, so let's just keep things simple.
It should at least have a comment saying that it's broken in subtle
ways (only on udelays that happen to span the 32-bit wraparound) on
anything where cycle_t is not 32-bits. Perhaps at least a:
WARN_ON_ONCE(sizeof(cycles_t) != sizeof(u32));
The above should be optimized by the compiler.
-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: [PATCH v2] clocksource: exynos-mct: Register the timer for stable udelay
On 19.06.2014 18:01, Doug Anderson wrote:
> Hi,
>
> On Thu, Jun 19, 2014 at 3:21 AM, Tomasz Figa wrote:
>>> +static struct delay_timer exynos4_delay_timer;
>>> +
>>> +static unsigned long exynos4_read_current_timer(void)
>
> Note: I think this should return a cycles_t, not an unsigned long.
> They're the same (right now), but probably shouldn't be (see below).
>
>
>>> +{
>>> +#ifdef ARM
>>> + return __raw_readl(reg_base + EXYNOS4_MCT_G_CNT_L);
>>> +#else /* ARM64, etc */
>>> + return exynos4_frc_read(&mct_frc);
>>> +#endif
>>> +}
>>> +
>>
>> No need for anything like this. Even if running on ARM64, the delay
>> timer code should be able to cope with different timer widths. For
>> delays, 32 bits are enough, so just always read the lower part.
>
> I agree that the timer code should cope but it doesn't appear to. I see:
>
> cycles_t start = get_cycles();
> while ((get_cycles() - start) < cycles)
> cpu_relax();
>
> Right now cycles_t is defined as "unsigned long". If that's 64-bits
> on ARM64 then this function will have problems with wraparound.
Well, first of all, I'm not sure why we're discussing ARM64 here, if it
doesn't have support for register_current_timer_delay() at all.
Moreover, the only user if it is ARM32 and, if I remember correctly, the
assumption was that you need a >= 32 bit timer to use it for delays and
so with 32 bit unsigned long everything should work. Now if ARM64 also
wants to use this infrastructure, instead of hacking drivers now and
encouraging ARM64 people to continue using this kind of hackery, I
believe we should indicate that ARM64 delay timer code needs to be
implemented correctly and cope for different timer widths.
Of course the best way would be to redesign this interface right now to
consider time width (it is not just about 32 or 64 bits, there are
various timers, possibly 48- or 52-bit) and change ARM32 implementation
of it as well, if there are any volunteers. Changing the code to always
use 32-bit type regardless of arch is also an option.
>
> My personal vote would be to submit a patch to change "cycles_t" to
> always be 32-bits. Given that 32-bits was fine for udelay() for ARM
> that seems sane and simple. If someone later comes up with a super
> compelling reason why we need 64-bit timers for udelay (really??) then
> they can later add all the complexity needed.
Yes, this could work. I'm not sure what else cycles_t is used for, though.
>
> Amit: can you code up such a patch and add it to the series? I know
> it changes code that touches all ARM devices but I still think it's
> the right thing to do and actually only really changes behavior on
> ARM64.
>
>
>> Also use of raw accessors in drivers is discouraged - please use
>> readl_relaxed().
>
> It doesn't seem like that should happen in the same patch. Perhaps
> Amit can do a cleanup patch first that changes all instances of
> __raw_readl / __raw_writel in this file, then submit his patch atop
> that.
Why not? The patch adding exynos4_read_current_timer() (and so the call
to __raw_readl() was Amit's patch. I'm not asking to fix this in the
whole driver, just to do things correctly in new code.
>
>
>> Btw. I don't even see support for this on ARM64 in mainline, where arch
>> timer is always used for delays and AFAIK this is a platform requirement.
>
> Yeah, I'd vote for not using MCT on ARM64, but it I suppose it doesn't
> hurt to keep it working.
>
Right now there is no need for this, so let's just keep things simple.
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: [PATCH] clocksource: exynos-mct: Register the timer for stable udelay
Daniel, On Thu, Jun 19, 2014 at 9:02 AM, Daniel Lezcano wrote: >> My understanding of the current status is: >> * I posed the 64-bit version that's almost as fast as the 32-bit version. >> * I asked if people want the 32-bit version: no answer >> * I asked if anyone is opposed to the 64-bit version: no answer > > > Yeah, that happens. I thought you were working on the 32 bits. It was on my list of things to do today to touch base and make sure we were on the same page. Apparently we weren't. ;) >> I know that you wanted me to clean up the description of the 64-bit >> version so I was going to do that and repost. If there's someone >> willing to review / ack the 32-bit version I'd be happy to do that >> instead. Possibly I'll do both and a maintainer can choose which to >> apply? > > > Please, resend me the patch 1/3 as it is urgent with the changelog changed. OK, I'll do that right now, but just send it as a single patch (so I can get it out right away). Then I'll post up the 32-bit versions with an implicit dependency on that patch. -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: [PATCH] clocksource: exynos-mct: Register the timer for stable udelay
On 06/19/2014 05:49 PM, Doug Anderson wrote:
Daniel,
On Thu, Jun 19, 2014 at 2:07 AM, Daniel Lezcano
wrote:
On 06/19/2014 01:17 AM, Doug Anderson wrote:
Amit,
Thanks for posting!
On Wed, Jun 18, 2014 at 4:31 AM, Amit Daniel Kachhap
wrote:
This patch register the exynos mct clocksource as the current timer
as it has constant clock rate. This will generate correct udelay for the
exynos platform and avoid using unnecessary calibrated jiffies. This
change
have been tested on exynos5420 based board.
Signed-off-by: Amit Daniel Kachhap
---
Patches from David Riley confirmed that udelay is broken in exynos5420.
Link to those patches are,
1) https://patchwork.kernel.org/patch/4344911/
2) https://patchwork.kernel.org/patch/4344881/
drivers/clocksource/exynos_mct.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/clocksource/exynos_mct.c
b/drivers/clocksource/exynos_mct.c
index 8d64200..57cb3dc 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -198,10 +198,21 @@ static u64 notrace exynos4_read_sched_clock(void)
return exynos4_frc_read(&mct_frc);
}
+static struct delay_timer exynos4_delay_timer;
+
+static unsigned long exynos4_read_current_timer(void)
+{
+ return exynos4_frc_read(&mct_frc);
This is terribly inefficient to read all 64-bits and then cast back to
a 32-bit value. Replace with:
return __raw_readl(reg_base + EXYNOS4_MCT_G_CNT_L);
+}
+
static void __init exynos4_clocksource_init(void)
{
exynos4_mct_frc_start(0, 0);
Please rebase atop (1d80415 clocksource: exynos_mct: Don't reset the
counter during boot and resume), which is in linuxnext among other
places.
+ exynos4_delay_timer.read_current_timer =
&exynos4_read_current_timer;
+ exynos4_delay_timer.freq = clk_rate;
+ register_current_timer_delay(&exynos4_delay_timer);
+
if (clocksource_register_hz(&mct_frc, clk_rate))
panic("%s: can't register clocksource\n", mct_frc.name);
It does seem to work for me though. :)
Doug,
aren't you working on a 32 bits version ? So this patch could be simplified
I could do that if someone told me that they'll land it.
My understanding of the current status is:
* I posed the 64-bit version that's almost as fast as the 32-bit version.
* I asked if people want the 32-bit version: no answer
* I asked if anyone is opposed to the 64-bit version: no answer
Yeah, that happens. I thought you were working on the 32 bits.
I know that you wanted me to clean up the description of the 64-bit
version so I was going to do that and repost. If there's someone
willing to review / ack the 32-bit version I'd be happy to do that
instead. Possibly I'll do both and a maintainer can choose which to
apply?
Please, resend me the patch 1/3 as it is urgent with the changelog changed.
In the case here I was suggesting using the 32-bit version just
because on ARM32 there's totally no reason to read 64-bits. I hadn't
given a thought to ARM64. More on that in response to the other
messages.
Is there a 64bits platform using exynos_mct ?
--
Facebook |
Twitter |
Re: [PATCH v2] clocksource: exynos-mct: Register the timer for stable udelay
Hi,
On Thu, Jun 19, 2014 at 3:21 AM, Tomasz Figa wrote:
>> +static struct delay_timer exynos4_delay_timer;
>> +
>> +static unsigned long exynos4_read_current_timer(void)
Note: I think this should return a cycles_t, not an unsigned long.
They're the same (right now), but probably shouldn't be (see below).
>> +{
>> +#ifdef ARM
>> + return __raw_readl(reg_base + EXYNOS4_MCT_G_CNT_L);
>> +#else /* ARM64, etc */
>> + return exynos4_frc_read(&mct_frc);
>> +#endif
>> +}
>> +
>
> No need for anything like this. Even if running on ARM64, the delay
> timer code should be able to cope with different timer widths. For
> delays, 32 bits are enough, so just always read the lower part.
I agree that the timer code should cope but it doesn't appear to. I see:
cycles_t start = get_cycles();
while ((get_cycles() - start) < cycles)
cpu_relax();
Right now cycles_t is defined as "unsigned long". If that's 64-bits
on ARM64 then this function will have problems with wraparound.
My personal vote would be to submit a patch to change "cycles_t" to
always be 32-bits. Given that 32-bits was fine for udelay() for ARM
that seems sane and simple. If someone later comes up with a super
compelling reason why we need 64-bit timers for udelay (really??) then
they can later add all the complexity needed.
Amit: can you code up such a patch and add it to the series? I know
it changes code that touches all ARM devices but I still think it's
the right thing to do and actually only really changes behavior on
ARM64.
> Also use of raw accessors in drivers is discouraged - please use
> readl_relaxed().
It doesn't seem like that should happen in the same patch. Perhaps
Amit can do a cleanup patch first that changes all instances of
__raw_readl / __raw_writel in this file, then submit his patch atop
that.
> Btw. I don't even see support for this on ARM64 in mainline, where arch
> timer is always used for delays and AFAIK this is a platform requirement.
Yeah, I'd vote for not using MCT on ARM64, but it I suppose it doesn't
hurt to keep it working.
--
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] clocksource: exynos-mct: Register the timer for stable udelay
Daniel,
On Thu, Jun 19, 2014 at 2:07 AM, Daniel Lezcano
wrote:
> On 06/19/2014 01:17 AM, Doug Anderson wrote:
>>
>> Amit,
>>
>> Thanks for posting!
>>
>> On Wed, Jun 18, 2014 at 4:31 AM, Amit Daniel Kachhap
>> wrote:
>>>
>>> This patch register the exynos mct clocksource as the current timer
>>> as it has constant clock rate. This will generate correct udelay for the
>>> exynos platform and avoid using unnecessary calibrated jiffies. This
>>> change
>>> have been tested on exynos5420 based board.
>>>
>>> Signed-off-by: Amit Daniel Kachhap
>>> ---
>>>
>>> Patches from David Riley confirmed that udelay is broken in exynos5420.
>>> Link to those patches are,
>>> 1) https://patchwork.kernel.org/patch/4344911/
>>> 2) https://patchwork.kernel.org/patch/4344881/
>>>
>>> drivers/clocksource/exynos_mct.c | 11 +++
>>> 1 file changed, 11 insertions(+)
>>>
>>> diff --git a/drivers/clocksource/exynos_mct.c
>>> b/drivers/clocksource/exynos_mct.c
>>> index 8d64200..57cb3dc 100644
>>> --- a/drivers/clocksource/exynos_mct.c
>>> +++ b/drivers/clocksource/exynos_mct.c
>>> @@ -198,10 +198,21 @@ static u64 notrace exynos4_read_sched_clock(void)
>>> return exynos4_frc_read(&mct_frc);
>>> }
>>>
>>> +static struct delay_timer exynos4_delay_timer;
>>> +
>>> +static unsigned long exynos4_read_current_timer(void)
>>> +{
>>> + return exynos4_frc_read(&mct_frc);
>>
>>
>> This is terribly inefficient to read all 64-bits and then cast back to
>> a 32-bit value. Replace with:
>>
>> return __raw_readl(reg_base + EXYNOS4_MCT_G_CNT_L);
>>
>>
>>> +}
>>> +
>>> static void __init exynos4_clocksource_init(void)
>>> {
>>> exynos4_mct_frc_start(0, 0);
>>
>>
>> Please rebase atop (1d80415 clocksource: exynos_mct: Don't reset the
>> counter during boot and resume), which is in linuxnext among other
>> places.
>>
>>>
>>> + exynos4_delay_timer.read_current_timer =
>>> &exynos4_read_current_timer;
>>> + exynos4_delay_timer.freq = clk_rate;
>>> + register_current_timer_delay(&exynos4_delay_timer);
>>> +
>>> if (clocksource_register_hz(&mct_frc, clk_rate))
>>> panic("%s: can't register clocksource\n", mct_frc.name);
>>
>>
>> It does seem to work for me though. :)
>
>
> Doug,
>
> aren't you working on a 32 bits version ? So this patch could be simplified
I could do that if someone told me that they'll land it.
My understanding of the current status is:
* I posed the 64-bit version that's almost as fast as the 32-bit version.
* I asked if people want the 32-bit version: no answer
* I asked if anyone is opposed to the 64-bit version: no answer
I know that you wanted me to clean up the description of the 64-bit
version so I was going to do that and repost. If there's someone
willing to review / ack the 32-bit version I'd be happy to do that
instead. Possibly I'll do both and a maintainer can choose which to
apply?
In the case here I was suggesting using the 32-bit version just
because on ARM32 there's totally no reason to read 64-bits. I hadn't
given a thought to ARM64. More on that in response to the other
messages.
-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
[RFC] drm/exynos: abort commit when framebuffer is removed from plane
This situation arises when userspace remove the frambuffer object
and call setmode ioctl.
drm_mode_rmfb --> drm_plane_force_disable --> plane->crtc = NULL;
and
drm_mode_setcrtc --> exynos_plane_commit --> passes plane->crtc to
exynos_drm_crtc_plane_commit which is NULL.
This crashes the system.
Signed-off-by: Rahul Sharma
---
This works fine but I am not confident on the correctness of the
solution.
drivers/gpu/drm/exynos/exynos_drm_crtc.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 95c9435..da4efe4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -165,6 +165,12 @@ static int exynos_drm_crtc_mode_set_commit(struct drm_crtc
*crtc, int x, int y,
return -EPERM;
}
+ /* when framebuffer is removed, commit should not proceed. */
+ if(!plane->fb){
+ DRM_ERROR("framebuffer has been removed from plane.\n");
+ return -EFAULT;
+ }
+
crtc_w = crtc->primary->fb->width - x;
crtc_h = crtc->primary->fb->height - y;
--
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 v2 07/10] regulator: Add driver for Maxim 77802 PMIC regulators
On Wed, 18 Jun 2014 15:10:48 +0100 Lee Jones wrote: > > So I guess you should either a) take the whole patch-set through your mfd > > tree > > or b) merge the mfd patches and create an immutable branch that can be > > pulled by > > Mark, Mike and Alessandro. > > > > I don't know what's the preferred workflow in these cases... > > That's fine. I'm happy to create shared branches when required. mfd tree will be ok. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: dts: exynos4: add port sub-nodes to exynos usb host modules
On 19.06.2014 13:44, Daniel Drake wrote: > On Tue, Jun 17, 2014 at 10:25 AM, Marek Szyprowski > wrote: >> This patch adds port sub-nodes to exynos4 ehci and ohci modules, which >> are required by recently merged new exynos4 usb2 phy support. >> >> Signed-off-by: Marek Szyprowski > > I checked this against the DT binding documentation for the > samsung,exynos4210-ohci and samsung,exynos4210-ehci nodes, and also > the usb2 phy binding docs. Looks fine. > > Also tested on ODROID-U2, seems to be working: Thanks for testing. > > ehci-exynos: EHCI EXYNOS driver > exynos-ehci 1258.ehci: EHCI Host Controller > exynos-ehci 1258.ehci: new USB bus registered, assigned bus number 1 > exynos-ehci 1258.ehci: irq 102, io mem 0x1258 > exynos-ehci 1258.ehci: USB 2.0 started, EHCI 1.00 > ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver > ohci-exynos: OHCI EXYNOS driver > > ...and the onboard USB (EHCI) ethernet adapter works. Nice. > > The only thing I don't quite understand is the relationship between > EHCI and OHCI controllers, one being at 1258 and the other at > 1259000; the SoC docs (which I have not studied in detail) don't make > this very clear to me - no registers listed at base address 1259? > Anyway, Well, that's exactly the same relationship as on PCs, where you have both EHCI and UHCI/OHCI and depending on what kind of device you connect the proper controller will pick it up. AFAIK the base address is good, but I believe it was already tested anyway. 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: [PATCH 2/4] ARM: dts: exynos4412-odroidx: enable common hardware blocks
On 19.06.2014 14:21, Daniel Drake wrote: > On Tue, Jun 17, 2014 at 10:25 AM, Marek Szyprowski > wrote: >> This patch adds support for common hardware modules available on all >> Exynos4412-based Odroid boards, which already have complete support in >> mainline kernel. This includes secure firmware calls, watchdog, g2d and >> fimc (mem2mem) multimedia accelerators. > > For the secure firmware, this is indeed required for U2/U3, otherwise > the system crashes in weird ways during early boot. If this entry also > makes sense for ODROID-X, I'm surprised it was not there already, does > it boot without it? It probably does, but certain things fail, such as secondary CPU bring-up. > > As for the watchdog, g2d and fimc, is there really any Exynos4412 > configuration where such components are not available? > Sorry if that is a silly question - just wondering why we wouldn't > enable these in exynos4412.dtsi. I believe they should all be enabled at highest possible level, as they don't have any board-specific hardware dependencies. Probably even in exynos4.dtsi for some of them (watchdog likely). 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: [PATCH 4/4] ARM: dts: refactor Odroid DTS file and add support for Odroid X2 and U2/U3
On Tue, Jun 17, 2014 at 10:25 AM, Marek Szyprowski wrote: > This patch moves some parts of exynos4412-odroidx.dts to common > exynos4412-odroid-common.dtsi file and adds support for Odroid X2 and > U2/U3 boards. X2 is same as X, but it has faster SoC module (1.7GHz > instead of 1.4GHz), while U2/U3 differs from X2 by different way of > routing signals to host USB hub. It also lacks some hw modules not yet > supported by those dts files (i.e. LCD & touch panel). Thanks for this! It is working on ODROID-U2: at least eMMC/SD, LED, serial. Just 2 minor questions from reviewing: Odroid-X DTS used to have serial ports at 1382 and 1383, this patch removes them, but leaves 2. I can understand the idea of removing entries for ports that are not available on the board, but I've never seen an ODROID with 2 serial ports - should we bring this down to just the 1 enabled serial port that is accessible? Odroid-X DTS used to enable EHCI port 2, but with this refactoring, no longer does. Intentional? Thanks Daniel -- 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: MMC error on Exynos4210 board
On 06/19/2014 07:40 PM, Sachin Kamat wrote: > On Thu, Jun 19, 2014 at 2:40 PM, Tim Kryger wrote: >> On Thu, Jun 19, 2014 at 1:49 AM, Sachin Kamat wrote: >>> +cc Some relevant guys from Samsung >>> >>> On Thu, Jun 19, 2014 at 2:12 PM, Tim Kryger wrote: On Wed, Jun 18, 2014 at 8:54 PM, Sachin Kamat wrote: >> On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat >> wrote: >>> I see the below error on Exynos4210 based Origen board with linux-next >>> (20140618). >>> Reverting the below commit works fine. >>> >>> Commit: 8d02e775a6 "mmc: sdhci: Use mmc core regulator infrastucture" >>> >>> -- [2.068992] sdhci: Secure Digital Host Controller Interface driver >>> [2.075059] sdhci: Copyright(c) Pierre Ossman >>> [2.079762] of_get_named_gpiod_flags: can't parse gpios property of >>> node '/sdhci@1251[0]' >>> [2.088021] s3c-sdhci 1251.sdhci: clock source 2: mmc_busclk.2 >>> (5000 Hz) >>> [2.095322] of_get_named_gpiod_flags: can't parse gpios property of >>> node '/sdhci@1251[0]' >>> [2.103794] of_get_named_gpiod_flags: can't parse gpios property of >>> node '/sdhci@1251[0]' >>> [2.112478] s3c-sdhci 1251.sdhci: No vqmmc regulator found >>> [2.118117] mmc0: Hardware doesn't report any support voltages. >>> [2.124004] s3c-sdhci 1251.sdhci: sdhci_add_host() failed >>> [2.130080] of_get_named_gpiod_flags: can't parse gpios property of >>> node '/sdhci@1253[0]' >>> [2.138352] s3c-sdhci 1253.sdhci: clock source 2: mmc_busclk.2 >>> (1667 Hz) >>> [2.145661] of_get_named_gpiod_flags: can't parse gpios property of >>> node '/sdhci@1253[0]' >>> [2.154139] of_get_named_gpiod_flags: can't parse gpios property of >>> node '/sdhci@1253[0]' >>> [2.162834] s3c-sdhci 1253.sdhci: No vqmmc regulator found >>> [2.168464] mmc0: Hardware doesn't report any support voltages. >>> [2.174349] s3c-sdhci 1253.sdhci: sdhci_add_host() failed >>> [2.336148] Waiting for root device /dev/mmcblk0p1... > FYI, the board has a 2.8V fixed regulator supply connected to the MMC. > You may refer to arch/arm/boot/dts/exynos4210-origen.dts for more details. A 2.8v regulator results in mmc->ocr_avail being set to MMC_VDD_27_28 | MMC_VDD_28_29. The SDHCI capabilities register only indicates support of three voltage levels - 1.8v: SDHCI_CAN_VDD_180 => MMC_VDD_165_195 - 3.0v: SDHCI_CAN_VDD_300 => MMC_VDD_29_30 | MMC_VDD_30_31 - 3.3v: SDHCI_CAN_VDD_330 => MMC_VDD_32_33 | MMC_VDD_33_34 Right. sdhci capabilities only indicated them. But I think SoC can be support the specific VDD range. Even if all capability bits of the host controller were set, there still wouldn't be any overlap. Thus you see a "Hardware doesn't report any support voltages" message. Previously, this issue was being swept under the rug by cec2e21 mmc: sdhci: Use regulator min/max voltage range according to spec. That change hacked up the voltage range checks such that with your 2.8v fixed regulator, the driver would believe the host could support MMC_VDD_29_30 | MMC_VDD_30_31 | MMC_VDD_32_33 | MMC_VDD_33_34. The driver would start down the path of commanding 3.3v-3.4v (the highest voltage range believed to be supported). At the last second, the driver would see the regulator was fixed and blindly skip over the set voltage operation, saving it from failure. Since my patch eliminates the bogus voltage range checks, your board is now getting caught playing too loose with the SDHCI regulator voltages. Furthermore, the fixed regulator special-case logic that helped hide your issue should also be considered for removal given that fixed regulators now behave properly thanks to c00dc35 regulator: core: Allow regulator_set_voltage for fixed regulators. >>> >>> Thanks for the detailed explanation. What do you propose to get this fixed? >> >> I'm not really sure of the best path forward. I suppose you could >> modify your device tree to lie about the voltage of the fixed >> regulator. Changing it to 3.0v should allow it to boot up but that is >> definitely a hack. I don't want to change the 3.0V at dt file...is it hack? i don't think so. Almost exynos4 Series is used the fixed regulator(2.8V). I didn't know exactly why we used the 2.8V. But i guess there is some reason.(H/W design). If we need to change ocr value, then i will add the quirk or controlling function for exynos into sdhci-s3c.c How about? > > Or I could simply remove the vmmc-supply property altogether (as it is > optional) > and get the board to work. Then is it supported the power "always-on"? > >> It would be nice if the driver could be extended >> to handle the peculiarities of
[PATCH v2] arm: exynos: Support cluster power off on exynos5420/5800
Turning off a cluster when all 4 cores of the cluster are powered off
saves power significantly. Powering off the A15 L2 alone gives around
100mW in savings. Add support for powering off the A15/A7 clusters on
exynos5420/5800.
The patch enables specific register bits which ensure that:
- cluster L2 will be turned on before the first man is powered up.
- last man will be turned off before the cluster L2 is turned off.
- core is powered down before powering it up.
Remove the exynos_cluster_power_control function completely as we can
rely on the above mentioned bits rather than polling the cluster power
status register.
Signed-off-by: Abhilash Kesavan
Acked-by: Nicolas Pitre
---
Change in v2:
Added a macro for the COMMON_OPTION register and used it in the MCPM
back-end.
The patch is based on Linux-next 20140619. It has been tested on an
exynos5420-based chromebook using the "/dev/bL_switcher" interface as
well as the script provided by Nicolas Pitre and Dave Martin [1].
Patch depends on:
[v2] ARM: EXYNOS: mcpm: Don't rely on firmware's secondary_cpu_start
[1] http://www.spinics.net/lists/linux-samsung-soc/msg31257.html
arch/arm/mach-exynos/mcpm-exynos.c | 66 +---
arch/arm/mach-exynos/regs-pmu.h|2 ++
2 files changed, 33 insertions(+), 35 deletions(-)
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
b/arch/arm/mach-exynos/mcpm-exynos.c
index ace0ed6..619cbc6 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -26,6 +26,10 @@
#define EXYNOS5420_CPUS_PER_CLUSTER4
#define EXYNOS5420_NR_CLUSTERS 2
+#define EXYNOS5420_ENABLE_AUTOMATIC_CORE_DOWN BIT(9)
+#define EXYNOS5420_USE_ARM_CORE_DOWN_STATE BIT(29)
+#define EXYNOS5420_USE_L2_COMMON_UP_STATE BIT(30)
+
/*
* The common v7_exit_coherency_flush API could not be used because of the
* Erratum 799270 workaround. This macro is the same as the common one (in
@@ -73,36 +77,9 @@
cpu_use_count[EXYNOS5420_CPUS_PER_CLUSTER][EXYNOS5420_NR_CLUSTERS];
#define exynos_cluster_unused(cluster) !exynos_cluster_usecnt(cluster)
-static int exynos_cluster_power_control(unsigned int cluster, int enable)
-{
- unsigned int tries = 100;
- unsigned int val;
-
- if (enable) {
- exynos_cluster_power_up(cluster);
- val = S5P_CORE_LOCAL_PWR_EN;
- } else {
- exynos_cluster_power_down(cluster);
- val = 0;
- }
-
- /* Wait until cluster power control is applied */
- while (tries--) {
- if (exynos_cluster_power_state(cluster) == val)
- return 0;
-
- cpu_relax();
- }
- pr_debug("timed out waiting for cluster %u to power %s\n", cluster,
- enable ? "on" : "off");
-
- return -ETIMEDOUT;
-}
-
static int exynos_power_up(unsigned int cpu, unsigned int cluster)
{
unsigned int cpunr = cpu + (cluster * EXYNOS5420_CPUS_PER_CLUSTER);
- int err = 0;
pr_debug("%s: cpu %u cluster %u\n", __func__, cpu, cluster);
if (cpu >= EXYNOS5420_CPUS_PER_CLUSTER ||
@@ -126,12 +103,9 @@ static int exynos_power_up(unsigned int cpu, unsigned int
cluster)
* cores.
*/
if (was_cluster_down)
- err = exynos_cluster_power_control(cluster, 1);
+ exynos_cluster_power_up(cluster);
- if (!err)
- exynos_cpu_power_up(cpunr);
- else
- exynos_cluster_power_control(cluster, 0);
+ exynos_cpu_power_up(cpunr);
} else if (cpu_use_count[cpu][cluster] != 2) {
/*
* The only possible values are:
@@ -147,7 +121,7 @@ static int exynos_power_up(unsigned int cpu, unsigned int
cluster)
arch_spin_unlock(&exynos_mcpm_lock);
local_irq_enable();
- return err;
+ return 0;
}
/*
@@ -178,9 +152,10 @@ static void exynos_power_down(void)
if (cpu_use_count[cpu][cluster] == 0) {
exynos_cpu_power_down(cpunr);
- if (exynos_cluster_unused(cluster))
- /* TODO: Turn off the cluster here to save power. */
+ if (exynos_cluster_unused(cluster)) {
+ exynos_cluster_power_down(cluster);
last_man = true;
+ }
} else if (cpu_use_count[cpu][cluster] == 1) {
/*
* A power_up request went ahead of us.
@@ -299,6 +274,7 @@ static int __init exynos_mcpm_init(void)
{
struct device_node *node;
void __iomem *ns_sram_base_addr;
+ unsigned int value, i;
int ret;
node = of_find_matching_node(NULL, exynos_dt_mcpm_match);
@@ -342,6 +318,26 @@ static int __init exynos_mcpm_init(void)
pr_info("Exynos MC
Re: [PATCH 3/4] ARM: dts: exynos4412-odroidx: add support for USB (phy, host, device)
On Tue, Jun 17, 2014 at 10:25 AM, Marek Szyprowski wrote: > From: Kamil Debski > > This patch adds basic support for USB modules (host and device) on > OdroidX board. > > Signed-off-by: Kamil Debski > Signed-off-by: Marek Szyprowski Checked that this conforms to the documented DT bindings. Reviewed-by: Daniel Drake -- 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: Support cluster power off on exynos5420/5800
Hi Nicolas,
On Wed, Jun 18, 2014 at 9:10 PM, Nicolas Pitre wrote:
> On Wed, 18 Jun 2014, Abhilash Kesavan wrote:
>
>> Turning off a cluster when all 4 cores of the cluster are powered off
>> saves power significantly. Powering off the A15 L2 alone gives around
>> 100mW in savings. Add support for powering off the A15/A7 clusters on
>> exynos5420/5800.
>>
>> The patch enables specific register bits which ensure that:
>>- cluster L2 will be turned on before the first man is powered up.
>>- last man will be turned off before the cluster L2 is turned off.
>>- core is powered down before powering it up.
>>
>> Remove the exynos_cluster_power_control function completely as we can
>> rely on the above mentioned bits rather than polling the cluster power
>> status register.
>>
>> Signed-off-by: Abhilash Kesavan
>
> Minor nit below:
>
>> @@ -342,6 +318,26 @@ static int __init exynos_mcpm_init(void)
>> pr_info("Exynos MCPM support installed\n");
>>
>> /*
>> + * On Exynos5420/5800 for the A15 and A7 clusters:
>> + *
>> + * EXYNOS5420_ENABLE_AUTOMATIC_CORE_DOWN ensures that all the cores
>> + * in a cluster are turned off before turning off the cluster L2.
>> + *
>> + * EXYNOS5420_USE_ARM_CORE_DOWN_STATE ensures that a cores is powered
>> + * off before waking it up.
>> + *
>> + * EXYNOS5420_USE_L2_COMMON_UP_STATE ensures that cluster L2 will be
>> + * turned on before the first man is powered up.
>> + */
>> + for (i = 0; i < EXYNOS5420_NR_CLUSTERS; i++) {
>> + value = __raw_readl(EXYNOS_COMMON_CONFIGURATION(i) + 0x8);
>> + value |= EXYNOS5420_ENABLE_AUTOMATIC_CORE_DOWN |
>> + EXYNOS5420_USE_ARM_CORE_DOWN_STATE|
>> + EXYNOS5420_USE_L2_COMMON_UP_STATE;
>> + __raw_writel(value, EXYNOS_COMMON_CONFIGURATION(i) + 0x8);
>
> Surely you can add another define in mach-exynos/regs-pmu.h to better
> identify this register instead of EXYNOS_COMMON_CONFIGURATION()+8 ?
>
> After that, you may add:
>
> Acked-by: Nicolas Pitre
Thanks. Will fix and post v2 with your ack.
Regards,
Abhilash
>
>
> Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: dts: exynos4412-odroidx: enable common hardware blocks
On Tue, Jun 17, 2014 at 10:25 AM, Marek Szyprowski wrote: > This patch adds support for common hardware modules available on all > Exynos4412-based Odroid boards, which already have complete support in > mainline kernel. This includes secure firmware calls, watchdog, g2d and > fimc (mem2mem) multimedia accelerators. For the secure firmware, this is indeed required for U2/U3, otherwise the system crashes in weird ways during early boot. If this entry also makes sense for ODROID-X, I'm surprised it was not there already, does it boot without it? As for the watchdog, g2d and fimc, is there really any Exynos4412 configuration where such components are not available? Sorry if that is a silly question - just wondering why we wouldn't enable these in exynos4412.dtsi. Thanks Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: dts: exynos4: add port sub-nodes to exynos usb host modules
On Tue, Jun 17, 2014 at 10:25 AM, Marek Szyprowski wrote: > This patch adds port sub-nodes to exynos4 ehci and ohci modules, which > are required by recently merged new exynos4 usb2 phy support. > > Signed-off-by: Marek Szyprowski I checked this against the DT binding documentation for the samsung,exynos4210-ohci and samsung,exynos4210-ehci nodes, and also the usb2 phy binding docs. Looks fine. Also tested on ODROID-U2, seems to be working: ehci-exynos: EHCI EXYNOS driver exynos-ehci 1258.ehci: EHCI Host Controller exynos-ehci 1258.ehci: new USB bus registered, assigned bus number 1 exynos-ehci 1258.ehci: irq 102, io mem 0x1258 exynos-ehci 1258.ehci: USB 2.0 started, EHCI 1.00 ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver ohci-exynos: OHCI EXYNOS driver ...and the onboard USB (EHCI) ethernet adapter works. Nice. The only thing I don't quite understand is the relationship between EHCI and OHCI controllers, one being at 1258 and the other at 1259000; the SoC docs (which I have not studied in detail) don't make this very clear to me - no registers listed at base address 1259? Anyway, Reviewed-by: Daniel Drake -- 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] clocksource: exynos-mct: Register the timer for stable udelay
On Thu, Jun 19, 2014 at 4:00 PM, Daniel Lezcano
wrote:
> On 06/19/2014 12:21 PM, amit daniel kachhap wrote:
>>
>> On Thu, Jun 19, 2014 at 2:41 PM, Daniel Lezcano
>> wrote:
>>>
>>> On 06/19/2014 10:39 AM, Amit Daniel Kachhap wrote:
This patch register the exynos mct clocksource as the current timer
as it has constant clock rate. This will generate correct udelay for the
exynos platform and avoid using unnecessary calibrated jiffies. This
change
has been tested on exynos5420 based board and udelay is very close to
expected.
Signed-off-by: Amit Daniel Kachhap
---
Changes in V2:
* Added #defines for ARM and ARM64 as pointed by Doug Anderson.
Patches from David Riley confirmed that udelay is broken in exynos5420.
Link to those patches are,
1) https://patchwork.kernel.org/patch/4344911/
2) https://patchwork.kernel.org/patch/4344881/
drivers/clocksource/exynos_mct.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/clocksource/exynos_mct.c
b/drivers/clocksource/exynos_mct.c
index f71d55f..02927e2 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -195,10 +195,25 @@ static u64 notrace exynos4_read_sched_clock(void)
return exynos4_frc_read(&mct_frc);
}
+static struct delay_timer exynos4_delay_timer;
+
+static unsigned long exynos4_read_current_timer(void)
+{
+#ifdef ARM
+ return __raw_readl(reg_base + EXYNOS4_MCT_G_CNT_L);
+#else /* ARM64, etc */
+ return exynos4_frc_read(&mct_frc);
+#endif
+}
+
>>>
>>>
>>>
>>> There isn't another solution than that ? macros definitions in C file are
>>> avoided as much as possible.
>>
>> I also didn't want to use macros but used as a last option. you want
>> me to put more comments here?
>> Or something like below is also possible for checking the size of
>> (unsigned long) in runtime.
>>
>> unsigned long x;
>> unsigned int size = (char *)(&x + 1) - (char *)(&x);
>> if (size == 4)
>> return __raw_readl(reg_base + EXYNOS4_MCT_G_CNT_L);
>> else
>> return exynos4_frc_read(&mct_frc);
>>
>> But this involves extra computation which should not be used for time
>> critical functions.
>> Any suggestion?
>
>
> AFAIU, Doug may change the exynos4_frc_read to be 32 bits. So may not need
> those macros as 'exynos4_frc_read' could be used instead.
right, its better to wait till those patches are out.
>
> Doug may confirm this.
>
>
static void __init exynos4_clocksource_init(void)
{
exynos4_mct_frc_start();
+ exynos4_delay_timer.read_current_timer =
&exynos4_read_current_timer;
>>>
>>>
>>>
>>> &exynos4_read_current_timer ?
>>
>> Any issue in the naming?
>
>
> No problem with the naming. As Tomasz pointed also, you are passing '&' for
> the function pointer.
yes my mistake.
>
>
+ exynos4_delay_timer.freq = clk_rate;
+ register_current_timer_delay(&exynos4_delay_timer);
+
if (clocksource_register_hz(&mct_frc, clk_rate))
panic("%s: can't register clocksource\n",
mct_frc.name);
>>>
>>>
>>> --
>>> Facebook |
>>> Twitter |
>>> Facebook |
> Twitter |
>
Re: MMC error on Exynos4210 board
On Thu, Jun 19, 2014 at 2:40 PM, Tim Kryger wrote: > On Thu, Jun 19, 2014 at 1:49 AM, Sachin Kamat wrote: >> +cc Some relevant guys from Samsung >> >> On Thu, Jun 19, 2014 at 2:12 PM, Tim Kryger wrote: >>> On Wed, Jun 18, 2014 at 8:54 PM, Sachin Kamat wrote: >>> > On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat wrote: >>> >> I see the below error on Exynos4210 based Origen board with linux-next >> (20140618). >> Reverting the below commit works fine. >> >> Commit: 8d02e775a6 "mmc: sdhci: Use mmc core regulator infrastucture" >>> >> >> -- [2.068992] sdhci: Secure Digital Host Controller Interface driver >> [2.075059] sdhci: Copyright(c) Pierre Ossman >> [2.079762] of_get_named_gpiod_flags: can't parse gpios property of >> node '/sdhci@1251[0]' >> [2.088021] s3c-sdhci 1251.sdhci: clock source 2: mmc_busclk.2 >> (5000 Hz) >> [2.095322] of_get_named_gpiod_flags: can't parse gpios property of >> node '/sdhci@1251[0]' >> [2.103794] of_get_named_gpiod_flags: can't parse gpios property of >> node '/sdhci@1251[0]' >> [2.112478] s3c-sdhci 1251.sdhci: No vqmmc regulator found >> [2.118117] mmc0: Hardware doesn't report any support voltages. >> [2.124004] s3c-sdhci 1251.sdhci: sdhci_add_host() failed >> [2.130080] of_get_named_gpiod_flags: can't parse gpios property of >> node '/sdhci@1253[0]' >> [2.138352] s3c-sdhci 1253.sdhci: clock source 2: mmc_busclk.2 >> (1667 Hz) >> [2.145661] of_get_named_gpiod_flags: can't parse gpios property of >> node '/sdhci@1253[0]' >> [2.154139] of_get_named_gpiod_flags: can't parse gpios property of >> node '/sdhci@1253[0]' >> [2.162834] s3c-sdhci 1253.sdhci: No vqmmc regulator found >> [2.168464] mmc0: Hardware doesn't report any support voltages. >> [2.174349] s3c-sdhci 1253.sdhci: sdhci_add_host() failed >>> >> [2.336148] Waiting for root device /dev/mmcblk0p1... >>> FYI, the board has a 2.8V fixed regulator supply connected to the MMC. You may refer to arch/arm/boot/dts/exynos4210-origen.dts for more details. >>> >>> A 2.8v regulator results in mmc->ocr_avail being set to MMC_VDD_27_28 >>> | MMC_VDD_28_29. >>> >>> The SDHCI capabilities register only indicates support of three voltage >>> levels >>> - 1.8v: SDHCI_CAN_VDD_180 => MMC_VDD_165_195 >>> - 3.0v: SDHCI_CAN_VDD_300 => MMC_VDD_29_30 | MMC_VDD_30_31 >>> - 3.3v: SDHCI_CAN_VDD_330 => MMC_VDD_32_33 | MMC_VDD_33_34 >>> >>> Even if all capability bits of the host controller were set, there >>> still wouldn't be any overlap. Thus you see a "Hardware doesn't >>> report any support voltages" message. >>> >>> Previously, this issue was being swept under the rug by cec2e21 mmc: >>> sdhci: Use regulator min/max voltage range according to spec. That >>> change hacked up the voltage range checks such that with your 2.8v >>> fixed regulator, the driver would believe the host could support >>> MMC_VDD_29_30 | MMC_VDD_30_31 | MMC_VDD_32_33 | MMC_VDD_33_34. The >>> driver would start down the path of commanding 3.3v-3.4v (the highest >>> voltage range believed to be supported). At the last second, the >>> driver would see the regulator was fixed and blindly skip over the set >>> voltage operation, saving it from failure. >>> >>> Since my patch eliminates the bogus voltage range checks, your board >>> is now getting caught playing too loose with the SDHCI regulator >>> voltages. >>> >>> Furthermore, the fixed regulator special-case logic that helped hide >>> your issue should also be considered for removal given that fixed >>> regulators now behave properly thanks to c00dc35 regulator: core: >>> Allow regulator_set_voltage for fixed regulators. >> >> Thanks for the detailed explanation. What do you propose to get this fixed? > > I'm not really sure of the best path forward. I suppose you could > modify your device tree to lie about the voltage of the fixed > regulator. Changing it to 3.0v should allow it to boot up but that is > definitely a hack. Or I could simply remove the vmmc-supply property altogether (as it is optional) and get the board to work. > It would be nice if the driver could be extended > to handle the peculiarities of your board in a deliberate manner but > limiting the common sdhci driver to supporting only the three voltages > from the spec also seems sensible. Until such time that the driver gets fixed to handle 2.8V fixed supply your current patch leaves several of Exynos boards broken for now. -- Regards, Sachin. -- 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] clocksource: exynos-mct: Register the timer for stable udelay
On 06/19/2014 12:21 PM, amit daniel kachhap wrote:
On Thu, Jun 19, 2014 at 2:41 PM, Daniel Lezcano
wrote:
On 06/19/2014 10:39 AM, Amit Daniel Kachhap wrote:
This patch register the exynos mct clocksource as the current timer
as it has constant clock rate. This will generate correct udelay for the
exynos platform and avoid using unnecessary calibrated jiffies. This
change
has been tested on exynos5420 based board and udelay is very close to
expected.
Signed-off-by: Amit Daniel Kachhap
---
Changes in V2:
* Added #defines for ARM and ARM64 as pointed by Doug Anderson.
Patches from David Riley confirmed that udelay is broken in exynos5420.
Link to those patches are,
1) https://patchwork.kernel.org/patch/4344911/
2) https://patchwork.kernel.org/patch/4344881/
drivers/clocksource/exynos_mct.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/clocksource/exynos_mct.c
b/drivers/clocksource/exynos_mct.c
index f71d55f..02927e2 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -195,10 +195,25 @@ static u64 notrace exynos4_read_sched_clock(void)
return exynos4_frc_read(&mct_frc);
}
+static struct delay_timer exynos4_delay_timer;
+
+static unsigned long exynos4_read_current_timer(void)
+{
+#ifdef ARM
+ return __raw_readl(reg_base + EXYNOS4_MCT_G_CNT_L);
+#else /* ARM64, etc */
+ return exynos4_frc_read(&mct_frc);
+#endif
+}
+
There isn't another solution than that ? macros definitions in C file are
avoided as much as possible.
I also didn't want to use macros but used as a last option. you want
me to put more comments here?
Or something like below is also possible for checking the size of
(unsigned long) in runtime.
unsigned long x;
unsigned int size = (char *)(&x + 1) - (char *)(&x);
if (size == 4)
return __raw_readl(reg_base + EXYNOS4_MCT_G_CNT_L);
else
return exynos4_frc_read(&mct_frc);
But this involves extra computation which should not be used for time
critical functions.
Any suggestion?
AFAIU, Doug may change the exynos4_frc_read to be 32 bits. So may not
need those macros as 'exynos4_frc_read' could be used instead.
Doug may confirm this.
static void __init exynos4_clocksource_init(void)
{
exynos4_mct_frc_start();
+ exynos4_delay_timer.read_current_timer =
&exynos4_read_current_timer;
&exynos4_read_current_timer ?
Any issue in the naming?
No problem with the naming. As Tomasz pointed also, you are passing '&'
for the function pointer.
+ exynos4_delay_timer.freq = clk_rate;
+ register_current_timer_delay(&exynos4_delay_timer);
+
if (clocksource_register_hz(&mct_frc, clk_rate))
panic("%s: can't register clocksource\n", mct_frc.name);
--
Facebook |
Twitter |
Facebook |
Twitter |
Re: [PATCH v2] clocksource: exynos-mct: Register the timer for stable udelay
On Thursday 19 June 2014 15:51:58 amit daniel kachhap wrote: > I also didn't want to use macros but used as a last option. you want > me to put more comments here? > Or something like below is also possible for checking the size of > (unsigned long) in runtime. > > unsigned long x; > unsigned int size = (char *)(&x + 1) - (char *)(&x); reimplementing "sizeof (long)"? > if (size == 4) >return __raw_readl(reg_base + EXYNOS4_MCT_G_CNT_L); readl_relaxed(), certainly > else >return exynos4_frc_read(&mct_frc); > > But this involves extra computation which should not be used for time > critical functions. sizeof is a constant expression, the compiler will optimize this. Arnd -- 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] clocksource: exynos-mct: Register the timer for stable udelay
Hi Amit,
Please see my comments inline.
On 19.06.2014 10:39, Amit Daniel Kachhap wrote:
> This patch register the exynos mct clocksource as the current timer
> as it has constant clock rate. This will generate correct udelay for the
> exynos platform and avoid using unnecessary calibrated jiffies. This change
> has been tested on exynos5420 based board and udelay is very close to
> expected.
>
> Signed-off-by: Amit Daniel Kachhap
> ---
> Changes in V2:
> * Added #defines for ARM and ARM64 as pointed by Doug Anderson.
>
> Patches from David Riley confirmed that udelay is broken in exynos5420.
> Link to those patches are,
> 1) https://patchwork.kernel.org/patch/4344911/
> 2) https://patchwork.kernel.org/patch/4344881/
>
> drivers/clocksource/exynos_mct.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/clocksource/exynos_mct.c
> b/drivers/clocksource/exynos_mct.c
> index f71d55f..02927e2 100644
> --- a/drivers/clocksource/exynos_mct.c
> +++ b/drivers/clocksource/exynos_mct.c
> @@ -195,10 +195,25 @@ static u64 notrace exynos4_read_sched_clock(void)
> return exynos4_frc_read(&mct_frc);
> }
>
> +static struct delay_timer exynos4_delay_timer;
> +
> +static unsigned long exynos4_read_current_timer(void)
> +{
> +#ifdef ARM
> + return __raw_readl(reg_base + EXYNOS4_MCT_G_CNT_L);
> +#else /* ARM64, etc */
> + return exynos4_frc_read(&mct_frc);
> +#endif
> +}
> +
No need for anything like this. Even if running on ARM64, the delay
timer code should be able to cope with different timer widths. For
delays, 32 bits are enough, so just always read the lower part.
Also use of raw accessors in drivers is discouraged - please use
readl_relaxed().
Btw. I don't even see support for this on ARM64 in mainline, where arch
timer is always used for delays and AFAIK this is a platform requirement.
> static void __init exynos4_clocksource_init(void)
> {
> exynos4_mct_frc_start();
>
> + exynos4_delay_timer.read_current_timer = &exynos4_read_current_timer;
nit: No need for & for function pointers.
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: [PATCH v2] clocksource: exynos-mct: Register the timer for stable udelay
On Thu, Jun 19, 2014 at 2:41 PM, Daniel Lezcano
wrote:
> On 06/19/2014 10:39 AM, Amit Daniel Kachhap wrote:
>>
>> This patch register the exynos mct clocksource as the current timer
>> as it has constant clock rate. This will generate correct udelay for the
>> exynos platform and avoid using unnecessary calibrated jiffies. This
>> change
>> has been tested on exynos5420 based board and udelay is very close to
>> expected.
>>
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>> Changes in V2:
>> * Added #defines for ARM and ARM64 as pointed by Doug Anderson.
>>
>> Patches from David Riley confirmed that udelay is broken in exynos5420.
>> Link to those patches are,
>> 1) https://patchwork.kernel.org/patch/4344911/
>> 2) https://patchwork.kernel.org/patch/4344881/
>>
>> drivers/clocksource/exynos_mct.c | 15 +++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/drivers/clocksource/exynos_mct.c
>> b/drivers/clocksource/exynos_mct.c
>> index f71d55f..02927e2 100644
>> --- a/drivers/clocksource/exynos_mct.c
>> +++ b/drivers/clocksource/exynos_mct.c
>> @@ -195,10 +195,25 @@ static u64 notrace exynos4_read_sched_clock(void)
>> return exynos4_frc_read(&mct_frc);
>> }
>>
>> +static struct delay_timer exynos4_delay_timer;
>> +
>> +static unsigned long exynos4_read_current_timer(void)
>> +{
>> +#ifdef ARM
>> + return __raw_readl(reg_base + EXYNOS4_MCT_G_CNT_L);
>> +#else /* ARM64, etc */
>> + return exynos4_frc_read(&mct_frc);
>> +#endif
>> +}
>> +
>
>
> There isn't another solution than that ? macros definitions in C file are
> avoided as much as possible.
I also didn't want to use macros but used as a last option. you want
me to put more comments here?
Or something like below is also possible for checking the size of
(unsigned long) in runtime.
unsigned long x;
unsigned int size = (char *)(&x + 1) - (char *)(&x);
if (size == 4)
return __raw_readl(reg_base + EXYNOS4_MCT_G_CNT_L);
else
return exynos4_frc_read(&mct_frc);
But this involves extra computation which should not be used for time
critical functions.
Any suggestion?
>
>
>> static void __init exynos4_clocksource_init(void)
>> {
>> exynos4_mct_frc_start();
>>
>> + exynos4_delay_timer.read_current_timer =
>> &exynos4_read_current_timer;
>
>
> &exynos4_read_current_timer ?
Any issue in the naming?
>
>
>> + exynos4_delay_timer.freq = clk_rate;
>> + register_current_timer_delay(&exynos4_delay_timer);
>> +
>> if (clocksource_register_hz(&mct_frc, clk_rate))
>> panic("%s: can't register clocksource\n", mct_frc.name);
>>
>>
>
>
> --
> Facebook |
> Twitter |
>
Re: [PATCH v2] clocksource: exynos-mct: Register the timer for stable udelay
On 06/19/2014 10:39 AM, Amit Daniel Kachhap wrote:
This patch register the exynos mct clocksource as the current timer
as it has constant clock rate. This will generate correct udelay for the
exynos platform and avoid using unnecessary calibrated jiffies. This change
has been tested on exynos5420 based board and udelay is very close to
expected.
Signed-off-by: Amit Daniel Kachhap
---
Changes in V2:
* Added #defines for ARM and ARM64 as pointed by Doug Anderson.
Patches from David Riley confirmed that udelay is broken in exynos5420.
Link to those patches are,
1) https://patchwork.kernel.org/patch/4344911/
2) https://patchwork.kernel.org/patch/4344881/
drivers/clocksource/exynos_mct.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index f71d55f..02927e2 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -195,10 +195,25 @@ static u64 notrace exynos4_read_sched_clock(void)
return exynos4_frc_read(&mct_frc);
}
+static struct delay_timer exynos4_delay_timer;
+
+static unsigned long exynos4_read_current_timer(void)
+{
+#ifdef ARM
+ return __raw_readl(reg_base + EXYNOS4_MCT_G_CNT_L);
+#else /* ARM64, etc */
+ return exynos4_frc_read(&mct_frc);
+#endif
+}
+
There isn't another solution than that ? macros definitions in C file
are avoided as much as possible.
static void __init exynos4_clocksource_init(void)
{
exynos4_mct_frc_start();
+ exynos4_delay_timer.read_current_timer = &exynos4_read_current_timer;
&exynos4_read_current_timer ?
+ exynos4_delay_timer.freq = clk_rate;
+ register_current_timer_delay(&exynos4_delay_timer);
+
if (clocksource_register_hz(&mct_frc, clk_rate))
panic("%s: can't register clocksource\n", mct_frc.name);
--
Facebook |
Twitter |
Re: MMC error on Exynos4210 board
On Thu, Jun 19, 2014 at 1:49 AM, Sachin Kamat wrote: > +cc Some relevant guys from Samsung > > On Thu, Jun 19, 2014 at 2:12 PM, Tim Kryger wrote: >> On Wed, Jun 18, 2014 at 8:54 PM, Sachin Kamat wrote: >> On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat wrote: >> > I see the below error on Exynos4210 based Origen board with linux-next > (20140618). > Reverting the below commit works fine. > > Commit: 8d02e775a6 "mmc: sdhci: Use mmc core regulator infrastucture" >> > > -- [2.068992] sdhci: Secure Digital Host Controller Interface driver > [2.075059] sdhci: Copyright(c) Pierre Ossman > [2.079762] of_get_named_gpiod_flags: can't parse gpios property of > node '/sdhci@1251[0]' > [2.088021] s3c-sdhci 1251.sdhci: clock source 2: mmc_busclk.2 > (5000 Hz) > [2.095322] of_get_named_gpiod_flags: can't parse gpios property of > node '/sdhci@1251[0]' > [2.103794] of_get_named_gpiod_flags: can't parse gpios property of > node '/sdhci@1251[0]' > [2.112478] s3c-sdhci 1251.sdhci: No vqmmc regulator found > [2.118117] mmc0: Hardware doesn't report any support voltages. > [2.124004] s3c-sdhci 1251.sdhci: sdhci_add_host() failed > [2.130080] of_get_named_gpiod_flags: can't parse gpios property of > node '/sdhci@1253[0]' > [2.138352] s3c-sdhci 1253.sdhci: clock source 2: mmc_busclk.2 > (1667 Hz) > [2.145661] of_get_named_gpiod_flags: can't parse gpios property of > node '/sdhci@1253[0]' > [2.154139] of_get_named_gpiod_flags: can't parse gpios property of > node '/sdhci@1253[0]' > [2.162834] s3c-sdhci 1253.sdhci: No vqmmc regulator found > [2.168464] mmc0: Hardware doesn't report any support voltages. > [2.174349] s3c-sdhci 1253.sdhci: sdhci_add_host() failed >> > [2.336148] Waiting for root device /dev/mmcblk0p1... >> >>> FYI, the board has a 2.8V fixed regulator supply connected to the MMC. >>> You may refer to arch/arm/boot/dts/exynos4210-origen.dts for more details. >> >> A 2.8v regulator results in mmc->ocr_avail being set to MMC_VDD_27_28 >> | MMC_VDD_28_29. >> >> The SDHCI capabilities register only indicates support of three voltage >> levels >> - 1.8v: SDHCI_CAN_VDD_180 => MMC_VDD_165_195 >> - 3.0v: SDHCI_CAN_VDD_300 => MMC_VDD_29_30 | MMC_VDD_30_31 >> - 3.3v: SDHCI_CAN_VDD_330 => MMC_VDD_32_33 | MMC_VDD_33_34 >> >> Even if all capability bits of the host controller were set, there >> still wouldn't be any overlap. Thus you see a "Hardware doesn't >> report any support voltages" message. >> >> Previously, this issue was being swept under the rug by cec2e21 mmc: >> sdhci: Use regulator min/max voltage range according to spec. That >> change hacked up the voltage range checks such that with your 2.8v >> fixed regulator, the driver would believe the host could support >> MMC_VDD_29_30 | MMC_VDD_30_31 | MMC_VDD_32_33 | MMC_VDD_33_34. The >> driver would start down the path of commanding 3.3v-3.4v (the highest >> voltage range believed to be supported). At the last second, the >> driver would see the regulator was fixed and blindly skip over the set >> voltage operation, saving it from failure. >> >> Since my patch eliminates the bogus voltage range checks, your board >> is now getting caught playing too loose with the SDHCI regulator >> voltages. >> >> Furthermore, the fixed regulator special-case logic that helped hide >> your issue should also be considered for removal given that fixed >> regulators now behave properly thanks to c00dc35 regulator: core: >> Allow regulator_set_voltage for fixed regulators. > > Thanks for the detailed explanation. What do you propose to get this fixed? I'm not really sure of the best path forward. I suppose you could modify your device tree to lie about the voltage of the fixed regulator. Changing it to 3.0v should allow it to boot up but that is definitely a hack. It would be nice if the driver could be extended to handle the peculiarities of your board in a deliberate manner but limiting the common sdhci driver to supporting only the three voltages from the spec also seems sensible. -Tim -- 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] clocksource: exynos-mct: Register the timer for stable udelay
On 06/19/2014 01:17 AM, Doug Anderson wrote:
Amit,
Thanks for posting!
On Wed, Jun 18, 2014 at 4:31 AM, Amit Daniel Kachhap
wrote:
This patch register the exynos mct clocksource as the current timer
as it has constant clock rate. This will generate correct udelay for the
exynos platform and avoid using unnecessary calibrated jiffies. This change
have been tested on exynos5420 based board.
Signed-off-by: Amit Daniel Kachhap
---
Patches from David Riley confirmed that udelay is broken in exynos5420.
Link to those patches are,
1) https://patchwork.kernel.org/patch/4344911/
2) https://patchwork.kernel.org/patch/4344881/
drivers/clocksource/exynos_mct.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 8d64200..57cb3dc 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -198,10 +198,21 @@ static u64 notrace exynos4_read_sched_clock(void)
return exynos4_frc_read(&mct_frc);
}
+static struct delay_timer exynos4_delay_timer;
+
+static unsigned long exynos4_read_current_timer(void)
+{
+ return exynos4_frc_read(&mct_frc);
This is terribly inefficient to read all 64-bits and then cast back to
a 32-bit value. Replace with:
return __raw_readl(reg_base + EXYNOS4_MCT_G_CNT_L);
+}
+
static void __init exynos4_clocksource_init(void)
{
exynos4_mct_frc_start(0, 0);
Please rebase atop (1d80415 clocksource: exynos_mct: Don't reset the
counter during boot and resume), which is in linuxnext among other
places.
+ exynos4_delay_timer.read_current_timer = &exynos4_read_current_timer;
+ exynos4_delay_timer.freq = clk_rate;
+ register_current_timer_delay(&exynos4_delay_timer);
+
if (clocksource_register_hz(&mct_frc, clk_rate))
panic("%s: can't register clocksource\n", mct_frc.name);
It does seem to work for me though. :)
Doug,
aren't you working on a 32 bits version ? So this patch could be
simplified ?
Thanks
-- Daniel
--
Facebook |
Twitter |
Re: MMC error on Exynos4210 board
+cc Some relevant guys from Samsung On Thu, Jun 19, 2014 at 2:12 PM, Tim Kryger wrote: > On Wed, Jun 18, 2014 at 8:54 PM, Sachin Kamat wrote: > >>> On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat wrote: > I see the below error on Exynos4210 based Origen board with linux-next (20140618). Reverting the below commit works fine. Commit: 8d02e775a6 "mmc: sdhci: Use mmc core regulator infrastucture" > -- [2.068992] sdhci: Secure Digital Host Controller Interface driver [2.075059] sdhci: Copyright(c) Pierre Ossman [2.079762] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1251[0]' [2.088021] s3c-sdhci 1251.sdhci: clock source 2: mmc_busclk.2 (5000 Hz) [2.095322] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1251[0]' [2.103794] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1251[0]' [2.112478] s3c-sdhci 1251.sdhci: No vqmmc regulator found [2.118117] mmc0: Hardware doesn't report any support voltages. [2.124004] s3c-sdhci 1251.sdhci: sdhci_add_host() failed [2.130080] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1253[0]' [2.138352] s3c-sdhci 1253.sdhci: clock source 2: mmc_busclk.2 (1667 Hz) [2.145661] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1253[0]' [2.154139] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1253[0]' [2.162834] s3c-sdhci 1253.sdhci: No vqmmc regulator found [2.168464] mmc0: Hardware doesn't report any support voltages. [2.174349] s3c-sdhci 1253.sdhci: sdhci_add_host() failed > [2.336148] Waiting for root device /dev/mmcblk0p1... > >> FYI, the board has a 2.8V fixed regulator supply connected to the MMC. >> You may refer to arch/arm/boot/dts/exynos4210-origen.dts for more details. > > A 2.8v regulator results in mmc->ocr_avail being set to MMC_VDD_27_28 > | MMC_VDD_28_29. > > The SDHCI capabilities register only indicates support of three voltage levels > - 1.8v: SDHCI_CAN_VDD_180 => MMC_VDD_165_195 > - 3.0v: SDHCI_CAN_VDD_300 => MMC_VDD_29_30 | MMC_VDD_30_31 > - 3.3v: SDHCI_CAN_VDD_330 => MMC_VDD_32_33 | MMC_VDD_33_34 > > Even if all capability bits of the host controller were set, there > still wouldn't be any overlap. Thus you see a "Hardware doesn't > report any support voltages" message. > > Previously, this issue was being swept under the rug by cec2e21 mmc: > sdhci: Use regulator min/max voltage range according to spec. That > change hacked up the voltage range checks such that with your 2.8v > fixed regulator, the driver would believe the host could support > MMC_VDD_29_30 | MMC_VDD_30_31 | MMC_VDD_32_33 | MMC_VDD_33_34. The > driver would start down the path of commanding 3.3v-3.4v (the highest > voltage range believed to be supported). At the last second, the > driver would see the regulator was fixed and blindly skip over the set > voltage operation, saving it from failure. > > Since my patch eliminates the bogus voltage range checks, your board > is now getting caught playing too loose with the SDHCI regulator > voltages. > > Furthermore, the fixed regulator special-case logic that helped hide > your issue should also be considered for removal given that fixed > regulators now behave properly thanks to c00dc35 regulator: core: > Allow regulator_set_voltage for fixed regulators. Thanks for the detailed explanation. What do you propose to get this fixed? -- Regards, Sachin. -- 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: MMC error on Exynos4210 board
On Wed, Jun 18, 2014 at 8:54 PM, Sachin Kamat wrote: >> On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat wrote: >>> I see the below error on Exynos4210 based Origen board with linux-next >>> (20140618). >>> Reverting the below commit works fine. >>> >>> Commit: 8d02e775a6 "mmc: sdhci: Use mmc core regulator infrastucture" >>> >>> -- [2.068992] sdhci: Secure Digital Host Controller Interface driver >>> [2.075059] sdhci: Copyright(c) Pierre Ossman >>> [2.079762] of_get_named_gpiod_flags: can't parse gpios property of >>> node '/sdhci@1251[0]' >>> [2.088021] s3c-sdhci 1251.sdhci: clock source 2: mmc_busclk.2 >>> (5000 Hz) >>> [2.095322] of_get_named_gpiod_flags: can't parse gpios property of >>> node '/sdhci@1251[0]' >>> [2.103794] of_get_named_gpiod_flags: can't parse gpios property of >>> node '/sdhci@1251[0]' >>> [2.112478] s3c-sdhci 1251.sdhci: No vqmmc regulator found >>> [2.118117] mmc0: Hardware doesn't report any support voltages. >>> [2.124004] s3c-sdhci 1251.sdhci: sdhci_add_host() failed >>> [2.130080] of_get_named_gpiod_flags: can't parse gpios property of >>> node '/sdhci@1253[0]' >>> [2.138352] s3c-sdhci 1253.sdhci: clock source 2: mmc_busclk.2 >>> (1667 Hz) >>> [2.145661] of_get_named_gpiod_flags: can't parse gpios property of >>> node '/sdhci@1253[0]' >>> [2.154139] of_get_named_gpiod_flags: can't parse gpios property of >>> node '/sdhci@1253[0]' >>> [2.162834] s3c-sdhci 1253.sdhci: No vqmmc regulator found >>> [2.168464] mmc0: Hardware doesn't report any support voltages. >>> [2.174349] s3c-sdhci 1253.sdhci: sdhci_add_host() failed >>> [2.336148] Waiting for root device /dev/mmcblk0p1... > FYI, the board has a 2.8V fixed regulator supply connected to the MMC. > You may refer to arch/arm/boot/dts/exynos4210-origen.dts for more details. A 2.8v regulator results in mmc->ocr_avail being set to MMC_VDD_27_28 | MMC_VDD_28_29. The SDHCI capabilities register only indicates support of three voltage levels - 1.8v: SDHCI_CAN_VDD_180 => MMC_VDD_165_195 - 3.0v: SDHCI_CAN_VDD_300 => MMC_VDD_29_30 | MMC_VDD_30_31 - 3.3v: SDHCI_CAN_VDD_330 => MMC_VDD_32_33 | MMC_VDD_33_34 Even if all capability bits of the host controller were set, there still wouldn't be any overlap. Thus you see a "Hardware doesn't report any support voltages" message. Previously, this issue was being swept under the rug by cec2e21 mmc: sdhci: Use regulator min/max voltage range according to spec. That change hacked up the voltage range checks such that with your 2.8v fixed regulator, the driver would believe the host could support MMC_VDD_29_30 | MMC_VDD_30_31 | MMC_VDD_32_33 | MMC_VDD_33_34. The driver would start down the path of commanding 3.3v-3.4v (the highest voltage range believed to be supported). At the last second, the driver would see the regulator was fixed and blindly skip over the set voltage operation, saving it from failure. Since my patch eliminates the bogus voltage range checks, your board is now getting caught playing too loose with the SDHCI regulator voltages. Furthermore, the fixed regulator special-case logic that helped hide your issue should also be considered for removal given that fixed regulators now behave properly thanks to c00dc35 regulator: core: Allow regulator_set_voltage for fixed regulators. -Tim -- 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] clocksource: exynos-mct: Register the timer for stable udelay
This patch register the exynos mct clocksource as the current timer
as it has constant clock rate. This will generate correct udelay for the
exynos platform and avoid using unnecessary calibrated jiffies. This change
has been tested on exynos5420 based board and udelay is very close to
expected.
Signed-off-by: Amit Daniel Kachhap
---
Changes in V2:
* Added #defines for ARM and ARM64 as pointed by Doug Anderson.
Patches from David Riley confirmed that udelay is broken in exynos5420.
Link to those patches are,
1) https://patchwork.kernel.org/patch/4344911/
2) https://patchwork.kernel.org/patch/4344881/
drivers/clocksource/exynos_mct.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index f71d55f..02927e2 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -195,10 +195,25 @@ static u64 notrace exynos4_read_sched_clock(void)
return exynos4_frc_read(&mct_frc);
}
+static struct delay_timer exynos4_delay_timer;
+
+static unsigned long exynos4_read_current_timer(void)
+{
+#ifdef ARM
+ return __raw_readl(reg_base + EXYNOS4_MCT_G_CNT_L);
+#else /* ARM64, etc */
+ return exynos4_frc_read(&mct_frc);
+#endif
+}
+
static void __init exynos4_clocksource_init(void)
{
exynos4_mct_frc_start();
+ exynos4_delay_timer.read_current_timer = &exynos4_read_current_timer;
+ exynos4_delay_timer.freq = clk_rate;
+ register_current_timer_delay(&exynos4_delay_timer);
+
if (clocksource_register_hz(&mct_frc, clk_rate))
panic("%s: can't register clocksource\n", mct_frc.name);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clocksource: exynos-mct: Register the timer for stable udelay
On Thu, Jun 19, 2014 at 4:47 AM, Doug Anderson wrote:
> Amit,
>
> Thanks for posting!
>
> On Wed, Jun 18, 2014 at 4:31 AM, Amit Daniel Kachhap
> wrote:
>> This patch register the exynos mct clocksource as the current timer
>> as it has constant clock rate. This will generate correct udelay for the
>> exynos platform and avoid using unnecessary calibrated jiffies. This change
>> have been tested on exynos5420 based board.
>>
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>>
>> Patches from David Riley confirmed that udelay is broken in exynos5420.
>> Link to those patches are,
>> 1) https://patchwork.kernel.org/patch/4344911/
>> 2) https://patchwork.kernel.org/patch/4344881/
>>
>> drivers/clocksource/exynos_mct.c | 11 +++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/clocksource/exynos_mct.c
>> b/drivers/clocksource/exynos_mct.c
>> index 8d64200..57cb3dc 100644
>> --- a/drivers/clocksource/exynos_mct.c
>> +++ b/drivers/clocksource/exynos_mct.c
>> @@ -198,10 +198,21 @@ static u64 notrace exynos4_read_sched_clock(void)
>> return exynos4_frc_read(&mct_frc);
>> }
>>
>> +static struct delay_timer exynos4_delay_timer;
>> +
>> +static unsigned long exynos4_read_current_timer(void)
>> +{
>> + return exynos4_frc_read(&mct_frc);
>
> This is terribly inefficient to read all 64-bits and then cast back to
> a 32-bit value. Replace with:
Yes agree.
This unsigned long strangely behaves as 32 bits for arm32 and 64 bits for arm64.
So I think it better is to do something like this,
+static unsigned long exynos4_read_current_timer(void)
+{
+#ifdef ARM
+ return __raw_readl(reg_base + EXYNOS4_MCT_G_CNT_L);
+#else /* ARM64, etc */
+ return exynos4_frc_read(&mct_frc);
+#endif
+}
+
I will post V2 version like above and see what the maintainer says.
>
> return __raw_readl(reg_base + EXYNOS4_MCT_G_CNT_L);
>
>
>> +}
>> +
>> static void __init exynos4_clocksource_init(void)
>> {
>> exynos4_mct_frc_start(0, 0);
>
> Please rebase atop (1d80415 clocksource: exynos_mct: Don't reset the
> counter during boot and resume), which is in linuxnext among other
> places.
OK will re base my patch on top of this.
>
>>
>> + exynos4_delay_timer.read_current_timer = &exynos4_read_current_timer;
>> + exynos4_delay_timer.freq = clk_rate;
>> + register_current_timer_delay(&exynos4_delay_timer);
>> +
>> if (clocksource_register_hz(&mct_frc, clk_rate))
>> panic("%s: can't register clocksource\n", mct_frc.name);
>
> It does seem to work for me though. :)
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
