RE: [PATCH v6 2/6] ARM: EXYNOS: Move cpufreq and cpuidle device registration to init_machine
Hi Kukjin,
>
> On 07/07/14 12:50, Pankaj Dubey wrote:
> > As exynos_cpuidle_init and exynos_cpufreq_init function have just one
> > lines of code for registering platform devices. We can move these
> > lines to exynos_dt_machine_init and delete exynos_cpuidle_init and
> > exynos_cpufreq_init function. This will help in reducing lines of code
> > in exynos.c, making it more cleaner.
> >
> > Suggested-by: Tomasz Figa
> > Signed-off-by: Pankaj Dubey
> > Reviewed-by: Tomasz Figa
> > ---
> > arch/arm/mach-exynos/exynos.c | 20
> > 1 file changed, 4 insertions(+), 16 deletions(-)
> >
> > diff --git a/arch/arm/mach-exynos/exynos.c
> > b/arch/arm/mach-exynos/exynos.c index ff60b4c..47170eb 100644
> > --- a/arch/arm/mach-exynos/exynos.c
> > +++ b/arch/arm/mach-exynos/exynos.c
> > @@ -171,19 +171,6 @@ static struct platform_device exynos_cpuidle = {
> > .id= -1,
> > };
> >
> > -void __init exynos_cpuidle_init(void) -{
> > - if (soc_is_exynos5440())
> > - return;
> > -
> > - platform_device_register(&exynos_cpuidle);
> > -}
> > -
> > -void __init exynos_cpufreq_init(void) -{
> > - platform_device_register_simple("exynos-cpufreq", -1, NULL, 0);
> > -}
> > -
> > void __iomem *sysram_base_addr;
> > void __iomem *sysram_ns_base_addr;
> >
> > @@ -300,10 +287,11 @@ static void __init exynos_dt_machine_init(void)
> > if (!IS_ENABLED(CONFIG_SMP))
> > exynos_sysram_init();
> >
> > - if (!of_machine_is_compatible("samsung,exynos5420"))
> > - exynos_cpuidle_init();
> > + if (!of_machine_is_compatible("samsung,exynos5420") ||
> > + !of_machine_is_compatible("samsung,exynos5440"))
> > + platform_device_register(&exynos_cpuidle);
> >
> > - exynos_cpufreq_init();
> > + platform_device_register_simple("exynos-cpufreq", -1, NULL, 0);
> >
> > of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> > }
>
> This cannot be applied in my tree now
>
May I know what the issue is? As I am able to rebase this patch on today's
kgene/for-next
and could not see any merge conflict.
If you think I need to respin this patch please let me know.
Thanks,
Pankaj Dubey
> - Kukjin
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Add mask-tpm-reset to the device tree
On Thu, Jun 26, 2014 at 11:15 AM, Vikas Sajjan wrote:
> From: Doug Anderson
>
> The mask-tpm-reset GPIO is used by the kernel to prevent the TPM from
> being reset across sleep/wake. If we don't set it to anything then
> the TPM will be reset. U-Boot will detect this as invalid
> and will reset the system on resume time. This GPIO can always be low
> and not hurt anything. It will get pulled back high again during a
> normal warm reset when it will default back to an input.
>
> To properly preserve the TPM state across suspend/resume and to make
> the chrome U-Boot happy, properly set the GPIO to mask the
> reset to the TPM.
>
> Signed-off-by: Doug Anderson
> Signed-off-by: Vikas Sajjan
(...)
> + /* We need GPX0_6 to be low at sleep time; just keep it low always */
> + mask_tpm_reset_regulator: mask-tpm-reset-regulator {
> + compatible = "regulator-fixed";
No matter how the discussion ends up, regulator-fixed is wrong.
Either folding it into the TPM driver or using a separate reset driver
is fine with me.
So what about the generic delayed reset GPIO thing?
http://marc.info/?l=linux-kernel&m=140309916607115&w=2
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] reset: Add a defer reset object to send board specific reset
On Wed, Jun 18, 2014 at 3:37 PM, Houcheng Lin wrote: > The Problem > --- > The reset signal on a hardware board is send either: > - during machine initialization > - during bus master's initialization I just thought about this a bit, since there isn't already a generic GPIO reset driver, just call this drivers/reset/reset-gpio.c and make the ability to deferral just a configuration detail of the GPIO reset driver. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] reset: Add a defer reset object to send board specific reset
On Tue, Jul 08, 2014 at 09:52:03AM +0200, Linus Walleij wrote: > On Wed, Jun 18, 2014 at 3:37 PM, Houcheng Lin wrote: > > > The Problem > > --- > > The reset signal on a hardware board is send either: > > - during machine initialization > > - during bus master's initialization > > I just thought about this a bit, since there isn't already a generic GPIO > reset driver, just call this drivers/reset/reset-gpio.c and make the > ability to deferral just a configuration detail of the GPIO reset driver. Philipp has been working on one for quite some time. See http://www.spinics.net/lists/arm-kernel/msg321927.html However, it seems to progress slowly, and we don't seem to be able to reach a consensus here. If you ask me, having to set a few extra properties like this just advocates for a regular reset driver and DT node for the reset GPIO, but I'm pretty sure Philipp will feel otherwise :) Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH 0/3] Deterministic UART numbering on Samsung SoCs
Hi,
How can we move forward here?
On Thu, Jun 26, 2014 at 1:02 PM, Tomasz Figa wrote:
> - basically Samsung UART already has its own namespace (ttySAC) and the
> order inside it is well-defined - instance ID shall be the hardware
> instance number as specified by documentation. The ports vary in certain
> aspects and the ID is important knowledge of the driver. The problem
> here was broken implementation of assigning IDs based on probe order,
> which worked only because on all Exynos platforms all ports have been
> always registered (which we want to change now and keep unused ones
> "disabled" in DT),
Yes, the kernel help text documents this quite well:
config SERIAL_SAMSUNG
tristate "Samsung SoC serial support"
depends on PLAT_SAMSUNG
select SERIAL_CORE
help
Support for the on-chip UARTs on the Samsung S3C24XX series CPUs,
providing /dev/ttySAC0, 1 and 2 (note, some machines may not
provide all of these ports, depending on how the serial port
pins are configured.
> - we already have a lot of userspace depending on the aforementioned
> ttySAC namespace and proper ordering of instances there. While I believe
> the proper solution as of today would be to go back to standard ttyS
> namespace and make userspace use a smarter way of identifying the
> instances (e.g. by path or id, as you suggested), I don't think this
> will make anyone's life easier with current assumptions,
I like the sound of going to the standard ttyS notation and only
providing ports for ones that exist, but is this userspace-visible
naming change OK? You could argue that userspace that relies on fixed
device paths is a bit broken, but that argument would be a bit cloudy
given the kernel documentation for the ttySAC devices above.
> - correct me if I'm wrong, but I don't think the
> /dev/serial/by-{path,id} would be handled in kernel's console= parameter.
That's right, that problem is left to the user, but at least we'd be
consistent with other SoCs (and open to generic solutions to that
inconvenience).
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 0/3] Deterministic UART numbering on Samsung SoCs
On 08.07.2014 10:32, Daniel Drake wrote:
> Hi,
>
> How can we move forward here?
Greg, Jiri, what do you think?
>
> On Thu, Jun 26, 2014 at 1:02 PM, Tomasz Figa wrote:
>> - basically Samsung UART already has its own namespace (ttySAC) and the
>> order inside it is well-defined - instance ID shall be the hardware
>> instance number as specified by documentation. The ports vary in certain
>> aspects and the ID is important knowledge of the driver. The problem
>> here was broken implementation of assigning IDs based on probe order,
>> which worked only because on all Exynos platforms all ports have been
>> always registered (which we want to change now and keep unused ones
>> "disabled" in DT),
>
> Yes, the kernel help text documents this quite well:
>
> config SERIAL_SAMSUNG
> tristate "Samsung SoC serial support"
> depends on PLAT_SAMSUNG
> select SERIAL_CORE
> help
> Support for the on-chip UARTs on the Samsung S3C24XX series CPUs,
> providing /dev/ttySAC0, 1 and 2 (note, some machines may not
> provide all of these ports, depending on how the serial port
> pins are configured.
>
>> - we already have a lot of userspace depending on the aforementioned
>> ttySAC namespace and proper ordering of instances there. While I believe
>> the proper solution as of today would be to go back to standard ttyS
>> namespace and make userspace use a smarter way of identifying the
>> instances (e.g. by path or id, as you suggested), I don't think this
>> will make anyone's life easier with current assumptions,
>
> I like the sound of going to the standard ttyS notation and only
> providing ports for ones that exist, but is this userspace-visible
> naming change OK? You could argue that userspace that relies on fixed
> device paths is a bit broken, but that argument would be a bit cloudy
> given the kernel documentation for the ttySAC devices above.
I'd say such argument would be completely invalid as this is most likely
almost all of the userspace for Samsung SoCs and, in addition to this,
quite a lot of firmware which pass console=ttySACx through command line.
>
>> - correct me if I'm wrong, but I don't think the
>> /dev/serial/by-{path,id} would be handled in kernel's console= parameter.
>
> That's right, that problem is left to the user, but at least we'd be
> consistent with other SoCs (and open to generic solutions to that
> inconvenience).
And so the point of this series is to make this no longer be left to the
user, making hardware UART 2 always UART 2 (which is supposed to be the
current behavior, but not always due to broken implementation) which is
completely orthogonal to raised issues.
Regardless of whether we stick to ttySAC or move back to ttyS, we still
need a deterministic way to assign the ID (even for internal driver
purposes) and that's why this series adds parsing of aliases. No user
visible behavior should be changed by this series.
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 v5 3/3] clk: samsung: exynos5420: Setup clocks before system suspend
Vikas, On 08.07.2014 06:34, Vikas Sajjan wrote: > Hi Kukjin, > > On Mon, Jun 30, 2014 at 11:28 PM, Tomasz Figa wrote: >> Hi Vikas, Abhilash, >> >> On 26.06.2014 13:12, Vikas Sajjan wrote: >>> Prior to suspending the system, we need to ensure that certain >>> clock source and gate registers are unmasked. >>> >>> while at it, add these clks to save/restore list also. >>> >>> Signed-off-by: Vikas Sajjan >>> Signed-off-by: Abhilash Kesavan >>> --- >>> drivers/clk/samsung/clk-exynos5420.c | 29 + >>> 1 file changed, 29 insertions(+) >> >> Looks good. Will apply. >> > > Can you apply this patch. As I said, I will take this through the samsung-clk tree. The patch should appear there soon. 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 v5 3/3] clk: samsung: exynos5420: Setup clocks before system suspend
On Tue, Jul 8, 2014 at 2:13 PM, Tomasz Figa wrote: > Vikas, > > On 08.07.2014 06:34, Vikas Sajjan wrote: >> Hi Kukjin, >> >> On Mon, Jun 30, 2014 at 11:28 PM, Tomasz Figa wrote: >>> Hi Vikas, Abhilash, >>> >>> On 26.06.2014 13:12, Vikas Sajjan wrote: Prior to suspending the system, we need to ensure that certain clock source and gate registers are unmasked. while at it, add these clks to save/restore list also. Signed-off-by: Vikas Sajjan Signed-off-by: Abhilash Kesavan --- drivers/clk/samsung/clk-exynos5420.c | 29 + 1 file changed, 29 insertions(+) >>> >>> Looks good. Will apply. >>> >> >> Can you apply this patch. > > As I said, I will take this through the samsung-clk tree. The patch > should appear there soon. OK, Thanks. > > 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 -- 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/6] pinctrl: samsung: Decouple direction setting from pinctrl
On Wed, Jul 2, 2014 at 5:40 PM, Tomasz Figa wrote: > This patch makes the pinctrl-samsung driver configure GPIO direction on > its own, without using the pinctrl_gpio_direction_*() "helpers". The > rationale behind this change is as follows: > - pinctrl-samsung does not need translation from GPIO namespace to >pinctrl namespace to handle GPIO operations - GPIO chip and offset >therein are enough to calculate necessary offsets and bit masks in >constant time, > - the pinctrl_gpio_direction_*() functions do not do anything useful >other than translating the pin into pinctrl namespace and calling the >.gpio_set_direction() from pinmux_ops of the controller, > - the undesirable side effect of using those helpers is losing the >ability to change GPIO direction in atomic context, because they >explicitly use a mutex for synchronization, > > Results of this patch are: > - fixed warnings about scheduling while atomic in code that needs to >set GPIO direction in atomic context (e.g. interrupt handler), > - reduced overhead of bitbanging drivers that use gpio_direction_*(), >e.g. i2c-gpio. > > Signed-off-by: Tomasz Figa Well the cross-call function is actually mostly for the case when the pinctrl and GPIO drivers are in different files, or you combine two IP blocks arbitrarily. It's a bit messy anyway. Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] pinctrl: samsung: Handle GPIO request and free using pinctrl helpers
On Wed, Jul 2, 2014 at 5:41 PM, Tomasz Figa wrote: > This patch adds .request() and .free() operations to gpio_chip of > pinctrl-samsung driver, which call pinctrl request and free helpers to > request and free pinctrl pin along with GPIO pin. > > Signed-off-by: Tomasz Figa Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] pinctrl: exynos: Consolidate irq_chips of GPIO and WKUP EINTs
On Wed, Jul 2, 2014 at 5:41 PM, Tomasz Figa wrote: > Handling of irq_chip operations for GPIO and WKUP external interrupts > is mostly the same, with the difference being offset of registers. > However currently the driver has all the code duplicated for both EINT > types, which is undesirable, because changes in irq_chip operations have > to be done to both instances of the same code. > > This patch fixes this by creating exynos_irq_chip struct that has normal > irq_chip struct embedded and contain differences between particular EINT > types, which are three register offsets. One instance of code is removed > and the new structure is used instead to fetch necessary data instead of > samsung_pin_ctrl struct used previously. > > While at it, the patch removes Exynos-specific fields from > aforementioned structure to improve layering of the driver. > > Signed-off-by: Tomasz Figa Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] pinctrl: exynos: Lock GPIOs as interrupts when used as EINTs
On Wed, Jul 2, 2014 at 5:41 PM, Tomasz Figa wrote: > Currently after configuring a GPIO pin as an interrupt related pinmux > registers are changed, but there is no protection from calling > gpio_direction_*() in a badly written driver, which would cause the same > pinmux register to be reconfigured for regular input/output and this > disabling interrupt capability of the pin. > > This patch addresses this issue by moving pinmux reconfiguration to > .irq_startup() callback of irq_chip and calling gpio_lock_as_irq() > helper to prevent reconfiguration of pin direction. > > Signed-off-by: Tomasz Figa (...) > + .irq_startup = exynos_irq_startup, > + .irq_shutdown = exynos_irq_shutdown, I think you should be using the .irq_request_resources and .irq_release_resources callbacks instead. The reason is that startup and shutdown cannot really fail (ret code is unsigned...), so using the other callbacks is safer. Can you have a quick look at this before I apply any more of the Samsung patches? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 2/2] ASoC: samsung: Add machine driver for Odroid X2/U3
Hi Sylwester, On Fri, Jul 4, 2014 at 2:13 PM, Sylwester Nawrocki wrote: > This patch adds the sound subsystem driver for Odroid-X2 and > Odroid-U3 boards. The codec works in I2S master mode; there > are two separate audio routing paths defined, as there are > differences in the signal routing between the X2 and U3 boards, > i.e. U3 uses single jack for headphones and microphone. > > Signed-off-by: Chen Zhen > Signed-off-by: Sylwester Nawrocki Testing on ODROID-U2, v3 is not quite working for me, but v2 of the patch was fine. I boot up, run: # speaker-test -c 2 -t wav As soon as I hear the word "front" I press ctrl+c and then run the command again. Now the command hangs with no audible output. Any ideas? Let me know if you have trouble reproducing. 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: [RFC PATCH v3] reset: Add a defer reset object to send board specific reset
On Tue, Jul 8, 2014 at 10:05 AM, Maxime Ripard wrote: > On Tue, Jul 08, 2014 at 09:52:03AM +0200, Linus Walleij wrote: >> On Wed, Jun 18, 2014 at 3:37 PM, Houcheng Lin wrote: >> >> > The Problem >> > --- >> > The reset signal on a hardware board is send either: >> > - during machine initialization >> > - during bus master's initialization >> >> I just thought about this a bit, since there isn't already a generic GPIO >> reset driver, just call this drivers/reset/reset-gpio.c and make the >> ability to deferral just a configuration detail of the GPIO reset driver. > > Philipp has been working on one for quite some time. See > http://www.spinics.net/lists/arm-kernel/msg321927.html > > However, it seems to progress slowly, and we don't seem to be able to > reach a consensus here. > > If you ask me, having to set a few extra properties like this just > advocates for a regular reset driver and DT node for the reset GPIO, > but I'm pretty sure Philipp will feel otherwise :) Hm haha yeah let's fight it out :-) This is not my subsystem so I'm getting some popcorn. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] mmc: dw_mmc: Support voltage changes
On Tue, July 08, 2014,Yuvaraj Kumar wrote:
> On Mon, Jul 7, 2014 at 10:53 AM, Seungwon Jeon wrote:
> > On Fri, July 04, 2014, Seungwon Jeon wrote:
> >> On Tue, July 01, 2014. Yuvaraj Kumar wrote:
> >> > On Fri, Jun 27, 2014 at 4:48 PM, Seungwon Jeon
> >> > wrote:
> >> > > Hi Yuvaraj,
> >> > >
> >> > > On Fri, June 27, 2014, Yuvaraj Kumar wrote:
> >> > >> On Thu, Jun 26, 2014 at 10:20 PM, Doug Anderson
> >> > >> wrote:
> >> > >> > Seungwon,
> >> > >> >
> >> > >> > On Thu, Jun 26, 2014 at 3:41 AM, Seungwon Jeon
> >> > >> > wrote:
> >> > >> >> On Thu, June 26, 2014, Doug Anderson wrote:
> >> > >> >>> Seungwon,
> >> > >> >>>
> >> > >> >>> On Wed, Jun 25, 2014 at 6:08 AM, Seungwon Jeon
> >> > >> >>> wrote:
> >> > >> >>> > On Mon, June 23, 2014, Yuvaraj Kumar C D wrote:
> >> > >> >>> >> Subject: [PATCH 3/3] mmc: dw_mmc: Support voltage changes
> >> > >> >>> >>
> >> > >> >>> >> From: Doug Anderson
> >> > >> >>> >>
> >> > >> >>> >> For UHS cards we need the ability to switch voltages from 3.3V
> >> > >> >>> >> to
> >> > >> >>> >> 1.8V. Add support to the dw_mmc driver to handle this. Note
> >> > >> >>> >> that
> >> > >> >>> >> dw_mmc needs a little bit of extra code since the interface
> >> > >> >>> >> needs a
> >> > >> >>> >> special bit programmed to the CMD register while CMD11 is
> >> > >> >>> >> progressing.
> >> > >> >>> >> This means adding a few extra states to the state machine to
> >> > >> >>> >> track.
> >> > >> >>> >
> >> > >> >>> > Overall new additional states makes it complicated.
> >> > >> >>> > Can we do that in other way?
> >> > >> >>>
> >> > >> >>> That was the best I was able to figure out when I thought this
> >> > >> >>> through. If you have ideas for doing it another way I'd imagine
> >> > >> >>> that
> >> > >> >>> Yuvaraj would be happy to take your feedback.
> >> > >> >> Let's clean up SDMMC_CMD_VOLT_SWITCH.
> >> > >> >> In turn, we may remove state-handling simply.
> >> > >> >>
> >> > >> >>>
> >> > >> >>>
> >> > >> >>> >> Signed-off-by: Doug Anderson
> >> > >> >>> >> Signed-off-by: Yuvaraj Kumar C D
> >> > >> >>> >>
> >> > >> >>> >> ---
> >> > >> >>> >> drivers/mmc/host/dw_mmc.c | 145
> >> > >> >>> >> +---
> >> > >> >>> >> drivers/mmc/host/dw_mmc.h |5 +-
> >> > >> >>> >> include/linux/mmc/dw_mmc.h |2 +
> >> > >> >>> >> 3 files changed, 142 insertions(+), 10 deletions(-)
> >> > >> >>> >>
> >> > >> >>> >> diff --git a/drivers/mmc/host/dw_mmc.c
> >> > >> >>> >> b/drivers/mmc/host/dw_mmc.c
> >> > >> >>> >> index e034bce..38eb548 100644
> >> > >> >>> >> --- a/drivers/mmc/host/dw_mmc.c
> >> > >> >>> >> +++ b/drivers/mmc/host/dw_mmc.c
> >> > >> >>> >> @@ -29,6 +29,7 @@
> >> > >> >>> >> #include
> >> > >> >>> >> #include
> >> > >> >>> >> #include
> >> > >> >>> >> +#include
> >> > >> >>> >> #include
> >> > >> >>> >> #include
> >> > >> >>> >> #include
> >> > >> >>> >> @@ -235,10 +236,13 @@ err:
> >> > >> >>> >> }
> >> > >> >>> >> #endif /* defined(CONFIG_DEBUG_FS) */
> >> > >> >>> >>
> >> > >> >>> >> +static void mci_send_cmd(struct dw_mci_slot *slot, u32 cmd,
> >> > >> >>> >> u32 arg);
> >> > >> >>> >> +
> >> > >> >>> >> static u32 dw_mci_prepare_command(struct mmc_host *mmc,
> >> > >> >>> >> struct mmc_command *cmd)
> >> > >> >>> >> {
> >> > >> >>> >> struct mmc_data *data;
> >> > >> >>> >> struct dw_mci_slot *slot = mmc_priv(mmc);
> >> > >> >>> >> + struct dw_mci *host = slot->host;
> >> > >> >>> >> const struct dw_mci_drv_data *drv_data =
> >> > >> >>> >> slot->host->drv_data;
> >> > >> >>> >> u32 cmdr;
> >> > >> >>> >> cmd->error = -EINPROGRESS;
> >> > >> >>> >> @@ -254,6 +258,32 @@ static u32 dw_mci_prepare_command(struct
> >> > >> >>> >> mmc_host *mmc, struct
> >> > mmc_command
> >> > >> >>> *cmd)
> >> > >> >>> >> else if (cmd->opcode != MMC_SEND_STATUS && cmd->data)
> >> > >> >>> >> cmdr |= SDMMC_CMD_PRV_DAT_WAIT;
> >> > >> >>> >>
> >> > >> >>> >> + if (cmd->opcode == SD_SWITCH_VOLTAGE) {
> >> > >> >>> >> + u32 clk_en_a;
> >> > >> >>> >> +
> >> > >> >>> >> + /* Special bit makes CMD11 not die */
> >> > >> >>> >> + cmdr |= SDMMC_CMD_VOLT_SWITCH;
> >> > >> >>> >> +
> >> > >> >>> >> + /* Change state to continue to handle CMD11
> >> > >> >>> >> weirdness */
> >> > >> >>> >> + WARN_ON(slot->host->state != STATE_SENDING_CMD);
> >> > >> >>> >> + slot->host->state = STATE_SENDING_CMD11;
> >> > >> >>> >> +
> >> > >> >>> >> + /*
> >> > >> >>> >> + * We need to disable clock stop while doing
> >> > >> >>> >> voltage switch
> >> > >> >>> >> + * according to 7.4.1.2 Voltage Switch Normal
> >> > >> >>> >> Scenario.
> >> > >> >>> >> + *
> >> > >> >>> >> + * It's assumed that by the next time the CLKENA
> >> > >> >>> >> is updated
> >> > >> >>> >> + * (when we set the clock next) that the voltage
> >
Re: [RFC] drm/exynos: abort commit when framebuffer is removed from plane
Hi Inki,
What do you think about the following fix? I need your inputs for this.
Regards,
Rahul Sharma
On 19 June 2014 20:43, Rahul Sharma wrote:
> 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 4/6] pinctrl: exynos: Lock GPIOs as interrupts when used as EINTs
Hi Linus, On 08.07.2014 11:03, Linus Walleij wrote: > On Wed, Jul 2, 2014 at 5:41 PM, Tomasz Figa wrote: > >> Currently after configuring a GPIO pin as an interrupt related pinmux >> registers are changed, but there is no protection from calling >> gpio_direction_*() in a badly written driver, which would cause the same >> pinmux register to be reconfigured for regular input/output and this >> disabling interrupt capability of the pin. >> >> This patch addresses this issue by moving pinmux reconfiguration to >> .irq_startup() callback of irq_chip and calling gpio_lock_as_irq() >> helper to prevent reconfiguration of pin direction. >> >> Signed-off-by: Tomasz Figa > (...) >> + .irq_startup = exynos_irq_startup, >> + .irq_shutdown = exynos_irq_shutdown, > > I think you should be using the > .irq_request_resources and .irq_release_resources callbacks instead. > > The reason is that startup and shutdown cannot really fail (ret code > is unsigned...), so using the other callbacks is safer. Hmm, I used the at91 pinctrl driver as an example, but I agree that request/release_resources would be better. I guess it should be changed there as well. [Ccing Jean-Jacques and Jean-Christophe] > > Can you have a quick look at this before I apply any more of the > Samsung patches? The two remaining patches are pretty much independent from this one and rest of this series so please take a look at them while I prepare new version of this patch. 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 v7] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
On Fri, Jul 04, 2014 at 10:21:56PM +0100, Abhilash Kesavan wrote:
> On Sat, Jul 5, 2014 at 2:30 AM, Nicolas Pitre
> wrote:
> > On Sat, 5 Jul 2014, Abhilash Kesavan wrote:
> >
> >> Use the MCPM layer to handle core suspend/resume on Exynos5420.
> >> Also, restore the entry address setup code post-resume.
> >>
> >> Signed-off-by: Abhilash Kesavan
> >
> > Acked-by: Nicolas Pitre
> This is one of the last missing bits for exynos MCPM. Thanks for your
> patient reviews of all the exynos mcpm back-end patches.
Sorry for the delay in getting back to you.
You still need to handle the residency parameter in the MCPM suspend call
properly to differentiate between core gating and cluster gating.
CPUidle might want to request a state that allows for core gating
residency but not cluster gating one, in that case the last man
standing must not shutdown the cluster.
This must be handled in the power down function, and it can be done
in a separate patch since it is an optimization. Current MCPM interface has
all it is needed to handle this properly, and I am keen on patching the
CPUidle bL driver to pass the actual residency instead of hardcoding it
to 0 (ie on TC2 it was not needed, no core gating).
Lorenzo
>
> Regards,
> Abhilash
> >
> >
> >> ---
> >> Changes in v2:
> >> - Made use of the MCPM suspend/powered_up call-backs
> >> Changes in v3:
> >> - Used the residency value to indicate the entered state
> >> Changes in v4:
> >> - Checked if MCPM has been enabled to prevent build error
> >> Changes in v5:
> >> - Removed the MCPM flags and just used a local flag to
> >> indicate that we are suspending.
> >> Changes in v6:
> >> - Read the SYS_PWR_REG value to decide if we are suspending
> >> the system.
> >> - Restore the SYS_PWR_REG value post-resume.
> >> - Modified the comments to reflect the first change.
> >> Changes in v7:
> >> - Add the suspend check in exynos_cpu_power_down() rather
> >> than the MCPM back-end.
> >> - Clean-up unnecessary changes related to earlier versions.
> >>
> >> This has been tested both on an SMDK5420 and Peach Pit Chromebook on
> >> next-20140704. Nicolas' boot cluster CCI enablement patches are in
> >> linux-next now.
> >>
> >> Here are the dependencies (some of these patches did not apply cleanly):
> >> 1) Cleanup patches for mach-exynos
> >> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33772
> >>
> >> 2) PMU cleanup and refactoring for using DT
> >> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg671625.html
> >>
> >> 3) Exynos5420 PMU/S2R Series
> >> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898
> >>
> >> 4) Exynos5420 CPUIdle Series which populates MCPM suspend/powered_up
> >> call-backs.
> >> www.gossamer-threads.com/lists/linux/kernel/1945347
> >> https://patchwork.kernel.org/patch/4357461/
> >>
> >> 5) Exynos5420 MCPM cluster power down support
> >> http://www.spinics.net/lists/arm-kernel/msg339988.html
> >>
> >> 6) TPM reset mask patch
> >> http://www.spinics.net/lists/arm-kernel/msg341884.html
> >>
> >> arch/arm/mach-exynos/mcpm-exynos.c | 32 +++---
> >> arch/arm/mach-exynos/pm.c | 54
> >> --
> >> 2 files changed, 74 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
> >> b/arch/arm/mach-exynos/mcpm-exynos.c
> >> index 2dd51cc..74ad772 100644
> >> --- a/arch/arm/mach-exynos/mcpm-exynos.c
> >> +++ b/arch/arm/mach-exynos/mcpm-exynos.c
> >> @@ -15,6 +15,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >>
> >> #include
> >> #include
> >> @@ -30,6 +31,8 @@
> >> #define EXYNOS5420_USE_ARM_CORE_DOWN_STATE BIT(29)
> >> #define EXYNOS5420_USE_L2_COMMON_UP_STATEBIT(30)
> >>
> >> +static void __iomem *ns_sram_base_addr;
> >> +
> >> /*
> >> * 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
> >> @@ -319,10 +322,26 @@ static const struct of_device_id
> >> exynos_dt_mcpm_match[] = {
> >> {},
> >> };
> >>
> >> +static void exynos_mcpm_setup_entry_point(void)
> >> +{
> >> + /*
> >> + * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
> >> + * as part of secondary_cpu_start(). Let's redirect it to the
> >> + * mcpm_entry_point(). This is done during both secondary boot-up as
> >> + * well as system resume.
> >> + */
> >> + __raw_writel(0xe59f, ns_sram_base_addr); /* ldr r0, [pc, #0]
> >> */
> >> + __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
> >> + __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
> >> +}
> >> +
> >> +static struct syscore_ops exynos_mcpm_syscore_ops = {
> >> + .resume = exynos_mcpm_setup_entry_point,
> >> +};
> >> +
> >> static int __init exynos_mcpm_init(void)
> >> {
> >> struct device_node *no
Re: [PATCH 1/3] ARM: exynos: remove unused
Hi Uwe, On 02.07.2014 11:57, Uwe Kleine-König wrote: > ARCH_EXYNOS doesn't select NEED_MACH_MEMORY_H, so doesn't > include and so this file is not used and can go away. > > Signed-off-by: Uwe Kleine-König > --- > Cc: Kukjin Kim > Cc: linux-samsung-soc@vger.kernel.org > --- > arch/arm/mach-exynos/include/mach/memory.h | 27 --- > 1 file changed, 27 deletions(-) > delete mode 100644 arch/arm/mach-exynos/include/mach/memory.h Thanks for the patch. Reviewed-by: Tomasz Figa [boot tested on Exynos4412-based Trats2 board] Tested-by: Tomasz Figa 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] ARM: Samsung: ADC: Move to clk_prepare_enable/clk_disable_unprepare
Hi Vasily, On 30.06.2014 21:08, Vasily Khoruzhick wrote: > Use clk_prepare_enable/clk_disable_unprepare to make the driver > work properly with common clock framework. > > Signed-off-by: Vasily Khoruzhick > --- > arch/arm/plat-samsung/adc.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) Reviewed-by: Tomasz Figa -- 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] Input: s3c2410_ts: Move to clk_prepare_enable/clk_disable_unprepare
Hi Vasily, On 30.06.2014 21:09, Vasily Khoruzhick wrote: > Use clk_prepare_enable/clk_disable_unprepare to make the driver > work properly with common clock framework. > > Signed-off-by: Vasily Khoruzhick > --- > drivers/input/touchscreen/s3c2410_ts.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > Reviewed-by: Tomasz Figa -- 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
[PATCH] ARM: EXYNOS: use u8 for val[] in struct exynos_pmu_conf
Values stored in val[] are never bigger than a byte.
textdata bss dec hex filename
5264 4 452721498 arch/arm/mach-exynos/pmu.o.before
2992 4 43000 bb8 arch/arm/mach-exynos/pmu.o.after
Signed-off-by: Bartlomiej Zolnierkiewicz
Acked-by: Kyungmin Park
---
arch/arm/mach-exynos/common.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index b850db4..55ff019 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -101,7 +101,7 @@ enum sys_powerdown {
struct exynos_pmu_conf {
void __iomem *reg;
- unsigned int val[NUM_SYS_POWERDOWN];
+ u8 val[NUM_SYS_POWERDOWN];
};
extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
--
1.8.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] regulator: s2mpxxx: Move regulator min/step voltages in common place
This is a cleanup patch and moves min/step voltages in a common samsung
header file so that they can be used by other s2mpxxx PMIC drivers. Only
few required macros are added currently and others can be added if needed.
Signed-off-by: Amit Daniel Kachhap
---
drivers/regulator/s2mpa01.c | 32
drivers/regulator/s2mps11.c | 50 ++---
include/linux/mfd/samsung/core.h| 21
include/linux/mfd/samsung/s2mpa01.h | 12 -
include/linux/mfd/samsung/s2mps11.h | 9 ---
include/linux/mfd/samsung/s2mps14.h | 10
6 files changed, 62 insertions(+), 72 deletions(-)
diff --git a/drivers/regulator/s2mpa01.c b/drivers/regulator/s2mpa01.c
index ee83b48..962c5f1 100644
--- a/drivers/regulator/s2mpa01.c
+++ b/drivers/regulator/s2mpa01.c
@@ -241,8 +241,8 @@ static struct regulator_ops s2mpa01_buck_ops = {
.ops= &s2mpa01_ldo_ops, \
.type = REGULATOR_VOLTAGE,\
.owner = THIS_MODULE, \
- .min_uV = S2MPA01_LDO_MIN, \
- .uV_step= S2MPA01_LDO_STEP1,\
+ .min_uV = MIN_800_MV, \
+ .uV_step= STEP_50_MV, \
.n_voltages = S2MPA01_LDO_N_VOLTAGES, \
.vsel_reg = S2MPA01_REG_L1CTRL + num - 1, \
.vsel_mask = S2MPA01_LDO_VSEL_MASK,\
@@ -255,8 +255,8 @@ static struct regulator_ops s2mpa01_buck_ops = {
.ops= &s2mpa01_ldo_ops, \
.type = REGULATOR_VOLTAGE,\
.owner = THIS_MODULE, \
- .min_uV = S2MPA01_LDO_MIN, \
- .uV_step= S2MPA01_LDO_STEP2,\
+ .min_uV = MIN_800_MV, \
+ .uV_step= STEP_25_MV, \
.n_voltages = S2MPA01_LDO_N_VOLTAGES, \
.vsel_reg = S2MPA01_REG_L1CTRL + num - 1, \
.vsel_mask = S2MPA01_LDO_VSEL_MASK,\
@@ -270,8 +270,8 @@ static struct regulator_ops s2mpa01_buck_ops = {
.ops= &s2mpa01_buck_ops,\
.type = REGULATOR_VOLTAGE,\
.owner = THIS_MODULE, \
- .min_uV = S2MPA01_BUCK_MIN1,\
- .uV_step= S2MPA01_BUCK_STEP1, \
+ .min_uV = MIN_600_MV, \
+ .uV_step= STEP_6_25_MV, \
.n_voltages = S2MPA01_BUCK_N_VOLTAGES, \
.ramp_delay = S2MPA01_RAMP_DELAY, \
.vsel_reg = S2MPA01_REG_B1CTRL2 + (num - 1) * 2, \
@@ -286,8 +286,8 @@ static struct regulator_ops s2mpa01_buck_ops = {
.ops= &s2mpa01_buck_ops,\
.type = REGULATOR_VOLTAGE,\
.owner = THIS_MODULE, \
- .min_uV = S2MPA01_BUCK_MIN2,\
- .uV_step= S2MPA01_BUCK_STEP1, \
+ .min_uV = MIN_800_MV, \
+ .uV_step= STEP_6_25_MV, \
.n_voltages = S2MPA01_BUCK_N_VOLTAGES, \
.ramp_delay = S2MPA01_RAMP_DELAY, \
.vsel_reg = S2MPA01_REG_B5CTRL2, \
@@ -302,8 +302,8 @@ static struct regulator_ops s2mpa01_buck_ops = {
.ops= &s2mpa01_buck_ops,\
.type = REGULATOR_VOLTAGE,\
.owner = THIS_MODULE, \
- .min_uV = S2MPA01_BUCK_MIN1,\
- .uV_step= S2MPA01_BUCK_STEP1, \
+ .min_uV = MIN_600_MV, \
+ .uV_step= STEP_6_25_MV, \
.n_voltages = S2MPA01_BUCK_N_VOLTAGES, \
.ramp_delay = S2MPA01_RAMP_DELAY, \
.vsel_reg = S2MPA01_REG_B6CTRL2 + (num - 6) * 2, \
@@ -318,8 +318,8 @@ static struct regulator_ops s2mpa01_buck_ops = {
.ops= &s2mpa01_buck_ops,\
.type = REGULATOR_VOLTAGE,\
.owner = THIS_MODULE, \
- .min_uV = S2MPA01_BUCK_MIN2,\
- .uV_step= S2MPA01_BUCK_STEP2, \
+ .min_uV = MIN_800_MV, \
+ .uV_step= STEP_12_5_MV, \
.n_voltages = S2MPA01_BUCK_N_VOLTAGES, \
.ramp_delay = S2MPA01_RAMP_DELAY, \
.
[PATCH 2/3] regulator: s2mpa01: Optimize the regulator description macro
This patch makes the regulator description macro take minimum and
steps voltage as parameter. In this way many repeated macros can be
removed. Now these macros are repeated only if the the LDO/BUCK ctrl
registers have non-linear positions. The good thing is these ctrl registers
are mostly linear so they are not passed as parameters.
This patch reduces the code size and also allow easy addition of more
s2mpxxx PMIC drivers which differs a lot in minimum/step voltages.
Signed-off-by: Amit Daniel Kachhap
---
drivers/regulator/s2mpa01.c | 136
1 file changed, 37 insertions(+), 99 deletions(-)
diff --git a/drivers/regulator/s2mpa01.c b/drivers/regulator/s2mpa01.c
index 962c5f1..8073466 100644
--- a/drivers/regulator/s2mpa01.c
+++ b/drivers/regulator/s2mpa01.c
@@ -235,28 +235,14 @@ static struct regulator_ops s2mpa01_buck_ops = {
.set_ramp_delay = s2mpa01_set_ramp_delay,
};
-#define regulator_desc_ldo1(num) { \
+#define regulator_desc_ldo(num, min, step) { \
.name = "LDO"#num,\
.id = S2MPA01_LDO##num, \
.ops= &s2mpa01_ldo_ops, \
.type = REGULATOR_VOLTAGE,\
.owner = THIS_MODULE, \
- .min_uV = MIN_800_MV, \
- .uV_step= STEP_50_MV, \
- .n_voltages = S2MPA01_LDO_N_VOLTAGES, \
- .vsel_reg = S2MPA01_REG_L1CTRL + num - 1, \
- .vsel_mask = S2MPA01_LDO_VSEL_MASK,\
- .enable_reg = S2MPA01_REG_L1CTRL + num - 1, \
- .enable_mask= S2MPA01_ENABLE_MASK \
-}
-#define regulator_desc_ldo2(num) { \
- .name = "LDO"#num,\
- .id = S2MPA01_LDO##num, \
- .ops= &s2mpa01_ldo_ops, \
- .type = REGULATOR_VOLTAGE,\
- .owner = THIS_MODULE, \
- .min_uV = MIN_800_MV, \
- .uV_step= STEP_25_MV, \
+ .min_uV = min, \
+ .uV_step= step, \
.n_voltages = S2MPA01_LDO_N_VOLTAGES, \
.vsel_reg = S2MPA01_REG_L1CTRL + num - 1, \
.vsel_mask = S2MPA01_LDO_VSEL_MASK,\
@@ -296,14 +282,14 @@ static struct regulator_ops s2mpa01_buck_ops = {
.enable_mask= S2MPA01_ENABLE_MASK \
}
-#define regulator_desc_buck6_7(num){ \
+#define regulator_desc_buck6_10(num, min, step){ \
.name = "BUCK"#num, \
.id = S2MPA01_BUCK##num,\
.ops= &s2mpa01_buck_ops,\
.type = REGULATOR_VOLTAGE,\
.owner = THIS_MODULE, \
- .min_uV = MIN_600_MV, \
- .uV_step= STEP_6_25_MV, \
+ .min_uV = min, \
+ .uV_step= step, \
.n_voltages = S2MPA01_BUCK_N_VOLTAGES, \
.ramp_delay = S2MPA01_RAMP_DELAY, \
.vsel_reg = S2MPA01_REG_B6CTRL2 + (num - 6) * 2, \
@@ -312,91 +298,43 @@ static struct regulator_ops s2mpa01_buck_ops = {
.enable_mask= S2MPA01_ENABLE_MASK \
}
-#define regulator_desc_buck8 { \
- .name = "BUCK8", \
- .id = S2MPA01_BUCK8,\
- .ops= &s2mpa01_buck_ops,\
- .type = REGULATOR_VOLTAGE,\
- .owner = THIS_MODULE, \
- .min_uV = MIN_800_MV, \
- .uV_step= STEP_12_5_MV, \
- .n_voltages = S2MPA01_BUCK_N_VOLTAGES, \
- .ramp_delay = S2MPA01_RAMP_DELAY, \
- .vsel_reg = S2MPA01_REG_B8CTRL2, \
- .vsel_mask = S2MPA01_BUCK_VSEL_MASK, \
- .enable_reg = S2MPA01_REG_B8CTRL1, \
- .enable_mask= S2MPA01_ENABLE_MASK \
-}
-
-#define regulator_desc_buck9 { \
- .name = "BUCK9", \
- .id = S2MPA01_BUCK9,\
- .ops= &s2mpa01_buck_ops,\
- .type = REGULATOR_VOLTAGE,\
-
[PATCH 3/3] regulator: s2mps11: Optimize the regulator description macro
This patch makes the regulator description macro take minimum and
steps voltage as parameter. In this way many repeated macros can be
removed. Now these macros are repeated only if the the LDO/BUCK ctrl
registers have non-linear positions. The good thing is these ctrl registers
are mostly linear so they are not passed as parameters.
This patch reduces the code size and also allow easy addition of more
s2mpxxx PMIC drivers which differs a lot in minimum/step voltages.
Signed-off-by: Amit Daniel Kachhap
---
drivers/regulator/s2mps11.c | 261 +++-
1 file changed, 86 insertions(+), 175 deletions(-)
diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index 2098c3e..ea94f47 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -250,28 +250,14 @@ static struct regulator_ops s2mps11_buck_ops = {
.set_ramp_delay = s2mps11_set_ramp_delay,
};
-#define regulator_desc_s2mps11_ldo1(num) { \
+#define regulator_desc_s2mps11_ldo(num, min, step) { \
.name = "LDO"#num,\
.id = S2MPS11_LDO##num, \
.ops= &s2mps11_ldo_ops, \
.type = REGULATOR_VOLTAGE,\
.owner = THIS_MODULE, \
- .min_uV = MIN_800_MV, \
- .uV_step= STEP_50_MV, \
- .n_voltages = S2MPS11_LDO_N_VOLTAGES, \
- .vsel_reg = S2MPS11_REG_L1CTRL + num - 1, \
- .vsel_mask = S2MPS11_LDO_VSEL_MASK,\
- .enable_reg = S2MPS11_REG_L1CTRL + num - 1, \
- .enable_mask= S2MPS11_ENABLE_MASK \
-}
-#define regulator_desc_s2mps11_ldo2(num) { \
- .name = "LDO"#num,\
- .id = S2MPS11_LDO##num, \
- .ops= &s2mps11_ldo_ops, \
- .type = REGULATOR_VOLTAGE,\
- .owner = THIS_MODULE, \
- .min_uV = MIN_800_MV, \
- .uV_step= STEP_25_MV, \
+ .min_uV = min, \
+ .uV_step= step, \
.n_voltages = S2MPS11_LDO_N_VOLTAGES, \
.vsel_reg = S2MPS11_REG_L1CTRL + num - 1, \
.vsel_mask = S2MPS11_LDO_VSEL_MASK,\
@@ -311,14 +297,14 @@ static struct regulator_ops s2mps11_buck_ops = {
.enable_mask= S2MPS11_ENABLE_MASK \
}
-#define regulator_desc_s2mps11_buck6_8(num) { \
+#define regulator_desc_s2mps11_buck6_10(num, min, step) { \
.name = "BUCK"#num, \
.id = S2MPS11_BUCK##num,\
.ops= &s2mps11_buck_ops,\
.type = REGULATOR_VOLTAGE,\
.owner = THIS_MODULE, \
- .min_uV = MIN_600_MV, \
- .uV_step= STEP_6_25_MV, \
+ .min_uV = min, \
+ .uV_step= step, \
.n_voltages = S2MPS11_BUCK_N_VOLTAGES, \
.ramp_delay = S2MPS11_RAMP_DELAY, \
.vsel_reg = S2MPS11_REG_B6CTRL2 + (num - 6) * 2, \
@@ -327,87 +313,55 @@ static struct regulator_ops s2mps11_buck_ops = {
.enable_mask= S2MPS11_ENABLE_MASK \
}
-#define regulator_desc_s2mps11_buck9 { \
- .name = "BUCK9", \
- .id = S2MPS11_BUCK9,\
- .ops= &s2mps11_buck_ops,\
- .type = REGULATOR_VOLTAGE,\
- .owner = THIS_MODULE, \
- .min_uV = MIN_3000_MV, \
- .uV_step= STEP_25_MV, \
- .n_voltages = S2MPS11_BUCK_N_VOLTAGES, \
- .ramp_delay = S2MPS11_RAMP_DELAY, \
- .vsel_reg = S2MPS11_REG_B9CTRL2, \
- .vsel_mask = S2MPS11_BUCK_VSEL_MASK, \
- .enable_reg = S2MPS11_REG_B9CTRL1, \
- .enable_mask= S2MPS11_ENABLE_MASK \
-}
-
-#define regulator_desc_s2mps11_buck10 {\
- .name = "BUCK10", \
- .id = S2MPS11_BUCK10, \
- .ops= &s2mps11_buck_ops,\
- .type = REGULATOR_VOLTAGE,\
-
Re: [PATCH RESEND] clk: samsung: Make of_device_id array const
Hi Krzysztof, On 26.06.2014 14:00, Krzysztof Kozlowski wrote: > Array of struct of_device_id may be be const as expected by > of_match_table field and of_find_matching_node_and_match() function. > > Signed-off-by: Krzysztof Kozlowski > --- > drivers/clk/samsung/clk-exynos4.c| 2 +- > drivers/clk/samsung/clk-exynos5250.c | 2 +- > drivers/clk/samsung/clk-exynos5420.c | 2 +- > drivers/clk/samsung/clk-exynos5440.c | 2 +- > drivers/clk/samsung/clk.c| 2 +- > drivers/clk/samsung/clk.h| 2 +- > 6 files changed, 6 insertions(+), 6 deletions(-) > Thanks for the patch. Will apply. 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
[PATCH] thermal: exynos: fix ordering in exynos_tmu_remove()
It might not be a problem currently but unregister/uninitialize things
in the reverse order that they are registered/initialized.
Signed-off-by: Bartlomiej Zolnierkiewicz
Acked-by: Kyungmin Park
---
drivers/thermal/samsung/exynos_tmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index d7ca9f4..6243ba0 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -759,10 +759,10 @@ static int exynos_tmu_remove(struct platform_device *pdev)
{
struct exynos_tmu_data *data = platform_get_drvdata(pdev);
- exynos_tmu_control(pdev, false);
-
exynos_unregister_thermal(data->reg_conf);
+ exynos_tmu_control(pdev, false);
+
clk_unprepare(data->clk);
if (!IS_ERR(data->clk_sec))
clk_unprepare(data->clk_sec);
--
1.8.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/6] ARM: EXYNOS: Fix core ID used by platsmp and hotplug code
Tomasz Figa wrote:
>
> When CPU topology is specified in device tree, cpu_logical_map() does
> not return core ID anymore, but rather full MPIDR value. This breaks
> existing calculation of PMU register offsets on Exynos SoCs.
>
> This patch fixes the problem by adjusting the code to use only core ID
> bits of the value returned by cpu_logical_map() to allow CPU topology to
> be specified in device tree on Exynos SoCs.
>
> Signed-off-by: Tomasz Figa
Looks good to me, but I think we don't need this fix in 3.16 because the CPU
topology is not specified in DT yet...if I'm wrong, please correct me.
Will apply for 3.17.
Thanks,
Kukjin
> ---
> arch/arm/mach-exynos/hotplug.c | 10 ++
> arch/arm/mach-exynos/platsmp.c | 34 +++---
> 2 files changed, 25 insertions(+), 19 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
> index 69fa483..5644dac 100644
> --- a/arch/arm/mach-exynos/hotplug.c
> +++ b/arch/arm/mach-exynos/hotplug.c
> @@ -40,11 +40,13 @@ static inline void cpu_leave_lowpower(void)
>
> static inline void platform_do_lowpower(unsigned int cpu, int *spurious)
> {
> + u32 mpidr = cpu_logical_map(cpu);
> + u32 core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> +
> for (;;) {
>
> - /* make cpu1 to be turned off at next WFI command */
> - if (cpu == 1)
> - exynos_cpu_power_down(cpu);
> + /* Turn the CPU off on next WFI instruction. */
> + exynos_cpu_power_down(core_id);
>
> /*
>* here's the WFI
> @@ -54,7 +56,7 @@ static inline void platform_do_lowpower(unsigned int cpu,
> int *spurious)
> :
> : "memory", "cc");
>
> - if (pen_release == cpu_logical_map(cpu)) {
> + if (pen_release == core_id) {
> /*
>* OK, proper wakeup, we're done
>*/
> diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
> index 1c8d31e..50b9aad 100644
> --- a/arch/arm/mach-exynos/platsmp.c
> +++ b/arch/arm/mach-exynos/platsmp.c
> @@ -90,7 +90,8 @@ static void exynos_secondary_init(unsigned int cpu)
> static int exynos_boot_secondary(unsigned int cpu, struct task_struct *idle)
> {
> unsigned long timeout;
> - unsigned long phys_cpu = cpu_logical_map(cpu);
> + u32 mpidr = cpu_logical_map(cpu);
> + u32 core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> int ret = -ENOSYS;
>
> /*
> @@ -104,17 +105,18 @@ static int exynos_boot_secondary(unsigned int cpu,
> struct task_struct *idle)
>* the holding pen - release it, then wait for it to flag
>* that it has been released by resetting pen_release.
>*
> - * Note that "pen_release" is the hardware CPU ID, whereas
> + * Note that "pen_release" is the hardware CPU core ID, whereas
>* "cpu" is Linux's internal ID.
>*/
> - write_pen_release(phys_cpu);
> + write_pen_release(core_id);
>
> - if (!exynos_cpu_power_state(cpu)) {
> - exynos_cpu_power_up(cpu);
> + if (!exynos_cpu_power_state(core_id)) {
> + exynos_cpu_power_up(core_id);
> timeout = 10;
>
> /* wait max 10 ms until cpu1 is on */
> - while (exynos_cpu_power_state(cpu) != S5P_CORE_LOCAL_PWR_EN) {
> + while (exynos_cpu_power_state(core_id)
> +!= S5P_CORE_LOCAL_PWR_EN) {
> if (timeout-- == 0)
> break;
>
> @@ -145,20 +147,20 @@ static int exynos_boot_secondary(unsigned int cpu,
> struct task_struct *idle)
>* Try to set boot address using firmware first
>* and fall back to boot register if it fails.
>*/
> - ret = call_firmware_op(set_cpu_boot_addr, phys_cpu, boot_addr);
> + ret = call_firmware_op(set_cpu_boot_addr, core_id, boot_addr);
> if (ret && ret != -ENOSYS)
> goto fail;
> if (ret == -ENOSYS) {
> - void __iomem *boot_reg = cpu_boot_reg(phys_cpu);
> + void __iomem *boot_reg = cpu_boot_reg(core_id);
>
> if (IS_ERR(boot_reg)) {
> ret = PTR_ERR(boot_reg);
> goto fail;
> }
> - __raw_writel(boot_addr, cpu_boot_reg(phys_cpu));
> + __raw_writel(boot_addr, cpu_boot_reg(core_id));
> }
>
> - call_firmware_op(cpu_boot, phys_cpu);
> + call_firmware_op(cpu_boot, core_id);
>
> arch_send_wakeup_ipi_mask(cpumask_of(cpu));
>
> @@ -227,22 +229,24 @@ static void __init exynos_smp_prepare_cpus(unsigned int
> max_cpus)
>* boot register if it fails.
>*/
> for (i = 1; i < max_cpus; ++i) {
> - uns
Re: [PATCH v7] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
Hi Lorenzo,
On Tue, Jul 8, 2014 at 4:23 PM, Lorenzo Pieralisi
wrote:
> On Fri, Jul 04, 2014 at 10:21:56PM +0100, Abhilash Kesavan wrote:
>> On Sat, Jul 5, 2014 at 2:30 AM, Nicolas Pitre
>> wrote:
>> > On Sat, 5 Jul 2014, Abhilash Kesavan wrote:
>> >
>> >> Use the MCPM layer to handle core suspend/resume on Exynos5420.
>> >> Also, restore the entry address setup code post-resume.
>> >>
>> >> Signed-off-by: Abhilash Kesavan
>> >
>> > Acked-by: Nicolas Pitre
>> This is one of the last missing bits for exynos MCPM. Thanks for your
>> patient reviews of all the exynos mcpm back-end patches.
>
> Sorry for the delay in getting back to you.
Thanks for your comments.
>
> You still need to handle the residency parameter in the MCPM suspend call
> properly to differentiate between core gating and cluster gating.
I am not too familiar with the cpuidle driver, but I see only cluster
power off state listed in the bL cpuidle driver.
>
> CPUidle might want to request a state that allows for core gating
> residency but not cluster gating one, in that case the last man
> standing must not shutdown the cluster.
For this, I would have to add another state to the bL cpuidle driver
or migrate to using your under-review generic idle state patchset.
Then based on the residency value skip/do cluster power down. Is this
correct ?
>
> This must be handled in the power down function, and it can be done
> in a separate patch since it is an optimization. Current MCPM interface has
> all it is needed to handle this properly, and I am keen on patching the
> CPUidle bL driver to pass the actual residency instead of hardcoding it
> to 0 (ie on TC2 it was not needed, no core gating).
I will look at doing this once the s2r patch gets merged.
Thanks,
Abhilash
>
> Lorenzo
>
>>
>> Regards,
>> Abhilash
>> >
>> >
>> >> ---
>> >> Changes in v2:
>> >> - Made use of the MCPM suspend/powered_up call-backs
>> >> Changes in v3:
>> >> - Used the residency value to indicate the entered state
>> >> Changes in v4:
>> >> - Checked if MCPM has been enabled to prevent build error
>> >> Changes in v5:
>> >> - Removed the MCPM flags and just used a local flag to
>> >> indicate that we are suspending.
>> >> Changes in v6:
>> >> - Read the SYS_PWR_REG value to decide if we are suspending
>> >> the system.
>> >> - Restore the SYS_PWR_REG value post-resume.
>> >> - Modified the comments to reflect the first change.
>> >> Changes in v7:
>> >> - Add the suspend check in exynos_cpu_power_down() rather
>> >> than the MCPM back-end.
>> >> - Clean-up unnecessary changes related to earlier versions.
>> >>
>> >> This has been tested both on an SMDK5420 and Peach Pit Chromebook on
>> >> next-20140704. Nicolas' boot cluster CCI enablement patches are in
>> >> linux-next now.
>> >>
>> >> Here are the dependencies (some of these patches did not apply cleanly):
>> >> 1) Cleanup patches for mach-exynos
>> >> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33772
>> >>
>> >> 2) PMU cleanup and refactoring for using DT
>> >> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg671625.html
>> >>
>> >> 3) Exynos5420 PMU/S2R Series
>> >> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898
>> >>
>> >> 4) Exynos5420 CPUIdle Series which populates MCPM suspend/powered_up
>> >> call-backs.
>> >> www.gossamer-threads.com/lists/linux/kernel/1945347
>> >> https://patchwork.kernel.org/patch/4357461/
>> >>
>> >> 5) Exynos5420 MCPM cluster power down support
>> >> http://www.spinics.net/lists/arm-kernel/msg339988.html
>> >>
>> >> 6) TPM reset mask patch
>> >> http://www.spinics.net/lists/arm-kernel/msg341884.html
>> >>
>> >> arch/arm/mach-exynos/mcpm-exynos.c | 32 +++---
>> >> arch/arm/mach-exynos/pm.c | 54
>> >> --
>> >> 2 files changed, 74 insertions(+), 12 deletions(-)
>> >>
>> >> diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
>> >> b/arch/arm/mach-exynos/mcpm-exynos.c
>> >> index 2dd51cc..74ad772 100644
>> >> --- a/arch/arm/mach-exynos/mcpm-exynos.c
>> >> +++ b/arch/arm/mach-exynos/mcpm-exynos.c
>> >> @@ -15,6 +15,7 @@
>> >> #include
>> >> #include
>> >> #include
>> >> +#include
>> >>
>> >> #include
>> >> #include
>> >> @@ -30,6 +31,8 @@
>> >> #define EXYNOS5420_USE_ARM_CORE_DOWN_STATE BIT(29)
>> >> #define EXYNOS5420_USE_L2_COMMON_UP_STATEBIT(30)
>> >>
>> >> +static void __iomem *ns_sram_base_addr;
>> >> +
>> >> /*
>> >> * 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
>> >> @@ -319,10 +322,26 @@ static const struct of_device_id
>> >> exynos_dt_mcpm_match[] = {
>> >> {},
>> >> };
>> >>
>> >> +static void exynos_mcpm_setup_entry_point(void)
>> >> +{
>> >> + /*
>> >> + * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
>> >> + * as part of se
RE: [PATCH 4/6] ARM: SAMSUNG: Restore Samsung PM Debug functionality
Tomasz Figa wrote: > > Due to recently merged patches and previous merge conflicts, the Samsung > PM Debug functionality no longer can be enabled. This patch fixes > incorrect dependency of SAMSUNG_PM_DEBUG on an integer symbol and adds > missing header inclusion. > Yes, you're right and it should be fixed...but I have comments... > Signed-off-by: Tomasz Figa > --- > arch/arm/plat-samsung/Kconfig| 8 +++- > arch/arm/plat-samsung/pm-debug.c | 1 + > 2 files changed, 8 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig > index 301b892..483c959 100644 > --- a/arch/arm/plat-samsung/Kconfig > +++ b/arch/arm/plat-samsung/Kconfig > @@ -412,9 +412,14 @@ config S5P_DEV_MFC > > comment "Power management" > > +config HAVE_SAMSUNG_PM_DEBUG > + bool > + help > + Allow compilation of Samsung PM debugging code. > + > config SAMSUNG_PM_DEBUG > bool "S3C2410 PM Suspend debug" > - depends on PM && DEBUG_KERNEL && DEBUG_S3C_UART > + depends on PM && DEBUG_KERNEL && HAVE_SAMSUNG_PM_DEBUG > help > Say Y here if you want verbose debugging from the PM Suspend and > Resume code. See > @@ -484,6 +489,7 @@ config S5P_SLEEP > > config DEBUG_S3C_UART > depends on PLAT_SAMSUNG > + select HAVE_SAMSUNG_PM_DEBUG Hmm... The DEBUG_S3C_UART will be '0' when we select DEBUG_S3C_UART0, then the HAVE_SAMSUNG_PM_DEBUG will not be selected so SAMSUNG_PM_DEBUG is also... > int > default "0" if DEBUG_S3C_UART0 > default "1" if DEBUG_S3C_UART1 > diff --git a/arch/arm/plat-samsung/pm-debug.c > b/arch/arm/plat-samsung/pm-debug.c > index 8f19f66..3960960 100644 > --- a/arch/arm/plat-samsung/pm-debug.c > +++ b/arch/arm/plat-samsung/pm-debug.c > @@ -14,6 +14,7 @@ > */ > > #include > +#include Yeah, this is required then we don't need inclusion here. > #include > > #include > -- > 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] ARM: SAMSUNG: Restore Samsung PM Debug functionality
On 08.07.2014 15:48, Kukjin Kim wrote: > Tomasz Figa wrote: >> >> Due to recently merged patches and previous merge conflicts, the Samsung >> PM Debug functionality no longer can be enabled. This patch fixes >> incorrect dependency of SAMSUNG_PM_DEBUG on an integer symbol and adds >> missing header inclusion. >> > Yes, you're right and it should be fixed...but I have comments... > >> Signed-off-by: Tomasz Figa >> --- >> arch/arm/plat-samsung/Kconfig| 8 +++- >> arch/arm/plat-samsung/pm-debug.c | 1 + >> 2 files changed, 8 insertions(+), 1 deletion(-) >> >> diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig >> index 301b892..483c959 100644 >> --- a/arch/arm/plat-samsung/Kconfig >> +++ b/arch/arm/plat-samsung/Kconfig >> @@ -412,9 +412,14 @@ config S5P_DEV_MFC >> >> comment "Power management" >> >> +config HAVE_SAMSUNG_PM_DEBUG >> +bool >> +help >> + Allow compilation of Samsung PM debugging code. >> + >> config SAMSUNG_PM_DEBUG >> bool "S3C2410 PM Suspend debug" >> -depends on PM && DEBUG_KERNEL && DEBUG_S3C_UART >> +depends on PM && DEBUG_KERNEL && HAVE_SAMSUNG_PM_DEBUG >> help >>Say Y here if you want verbose debugging from the PM Suspend and >>Resume code. See >> @@ -484,6 +489,7 @@ config S5P_SLEEP >> >> config DEBUG_S3C_UART >> depends on PLAT_SAMSUNG >> +select HAVE_SAMSUNG_PM_DEBUG > > Hmm... > > The DEBUG_S3C_UART will be '0' when we select DEBUG_S3C_UART0, then the > HAVE_SAMSUNG_PM_DEBUG will not be selected so SAMSUNG_PM_DEBUG is also... Yes, that's right. I posted v2 after a while in another reply to this thread. 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] thermal: Add missing cpumask_clear
On Fri, Jul 04, 2014 at 11:22:40AM +0100, Jonghwan Choi wrote: > Cpumasks should be cleared before using. > > Signed-off-by: Jonghwan Choi > --- > drivers/thermal/db8500_cpufreq_cooling.c|1 + > drivers/thermal/imx_thermal.c |1 + > drivers/thermal/samsung/exynos_thermal_common.c |1 + > 3 files changed, 3 insertions(+) Reviewed-by: Javi Merino You should send this patch to linux-pm, I think it should go via the thermal tree. Cheers, Javi -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] cpuidle fixes and cleanup
On 02.07.2014 05:11, Chander Kashyap wrote: > On Tue, Jul 1, 2014 at 8:22 PM, Russell King - ARM Linux > wrote: >> On Tue, Jul 01, 2014 at 08:02:36PM +0530, Chander Kashyap wrote: >>> This patch series fixes the cpuidle for different states. Also removes arm >>> diagnostic and power register save/restore code as it is made generic. >>> >>> Based on: >>> ARM: save/restore diagnostic register on Cortex-A9 suspend/resume >>> http://www.spinics.net/lists/arm-kernel/msg340506.html [Ccing people who participated in discussion in that thread] >> >> As there is an outstanding issue with this patch, we can't proceed with >> this set of changes until we know what's going on there. > > Sure, I will wait for the conclusion. So I believe the conclusion was that this can't be handled in generic way, because on systems running in non-secure mode writing to those registers faults. However I believe this could be moved into generic helpers. 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
mixer_check_mode drops Exynos5 display modes
Hi Sean, While looking at the following commit I noticed something: commit f041b257a8997c8472a1013e9f252c3e2a1d879e Author: Sean Paul Date: Thu Jan 30 16:19:15 2014 -0500 drm/exynos: Remove exynos_drm_hdmi shim This commit changes how mixer_check_mode() is used. It used to just exclude certain modes on old mixer versions, but now it seems to be called unconditionally, for all mixer versions. I guess the effect here is that some modes on exynos5 setups are dropped whereas they weren't before. Is that 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: [PATCH 5/6] ARM: EXYNOS: Fix suspend/resume sequencies
Tomasz Figa wrote:
>
> Due to recent consolidation of Exynos suspend and cpuidle code, some
> parts of suspend and resume sequences are executed two times, once from
> exynos_pm_syscore_ops and then from exynos_cpu_pm_notifier() and thus it
> breaks suspend, at least on Exynos4-based boards.
>
+ Jonghwan Choi
Yes, right. We moved the functionality into cpu_pm notifier in the commit ID
0ebc13e2 ("ARM: EXYNOS: Move the power sequence call in the cpu_pm notifier"),
so this should be fixed as you pointed out. But I talked to my colleague
Jonghwan about this and we need more time to have a look in detail for every
exynos SoCs. Will be back soon.
Thanks,
Kukjin
> This patch fixes the issue by removing exynos_pm_syscore_ops completely
> and making the code rely only on CPU PM notifier.
>
> Tested on Exynos4210-based Trats board.
>
> Signed-off-by: Tomasz Figa
> ---
> arch/arm/mach-exynos/pm.c | 20
> 1 file changed, 4 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
> index 87c0d34..98d4926 100644
> --- a/arch/arm/mach-exynos/pm.c
> +++ b/arch/arm/mach-exynos/pm.c
> @@ -364,11 +364,6 @@ early_wakeup:
> return;
> }
>
> -static struct syscore_ops exynos_pm_syscore_ops = {
> - .suspend= exynos_pm_suspend,
> - .resume = exynos_pm_resume,
> -};
> -
> /*
> * Suspend Ops
> */
> @@ -438,19 +433,13 @@ static int exynos_cpu_pm_notifier(struct notifier_block
> *self,
>
> switch (cmd) {
> case CPU_PM_ENTER:
> - if (cpu == 0) {
> - exynos_pm_central_suspend();
> - exynos_cpu_save_register();
> - }
> + if (cpu == 0)
> + exynos_pm_suspend();
> break;
>
> case CPU_PM_EXIT:
> - if (cpu == 0) {
> - if (!soc_is_exynos5250())
> - scu_enable(S5P_VA_SCU);
> - exynos_cpu_restore_register();
> - exynos_pm_central_resume();
> - }
> + if (cpu == 0)
> + exynos_pm_resume();
> break;
> }
>
> @@ -475,6 +464,5 @@ void __init exynos_pm_init(void)
> tmp |= ((0xFF << 8) | (0x1F << 1));
> __raw_writel(tmp, S5P_WAKEUP_MASK);
>
> - register_syscore_ops(&exynos_pm_syscore_ops);
> suspend_set_ops(&exynos_suspend_ops);
> }
> --
> 1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] Add support for Exynos clock output configuration
On 03.07.2014 02:14, Mike Turquette wrote: > Quoting Kukjin Kim (2014-06-25 03:36:51) >> Tomasz Figa wrote: >>> >> Hi Tomasz, >> >>> On all Exynos SoCs there is a dedicated CLKOUT pin that allows many of >>> internal SoC clocks to be output from the SoC. The hardware structure >> >> Yeah, because the CLKOUT pin is used for measure of the clock for debug on >> all >> of exynos SoCs commonly. >> >>> of CLKOUT related clocks looks as follows: >>> >>> CMU |---> clock0 -> | PMU | >>> | | | >>> several |---> clock1 -> | mux | >>> muxes | | + |---> CLKOUT >>> dividers | ... | gate| >>> and gates | | | >>> |---> clockN -> | | >>> >>> Since the block responsible for handling the pin is PMU, not CMU, >>> a separate driver, that binds to PMU node is required and acquires >>> all input clocks by standard DT clock look-up. This way we don't need >>> any cross-IP block drivers and cross-driver register sharing or >>> nodes for fake devices. >>> >> BTW, upcoming exynos5 SoCs have two muxs for CLKOUT and each mux is >> controlled >> by CMU and PMU, so >> >> The mux1 for CLKOUT in CMU is used to decide which clock in each sub-domain >> will be out and the mux2 in PMU is used to decide which sub-domain will be >> out >> via CLKOUT. So I want you to consider of all of exynos SoCs including >> upcoming >> SoCs. > > clkout for debug is very useful indeed. For SoCs with high speed clocks > that I have worked with, I have often observed that the clkout logic > introduces buffers or dividers. This is needed so that you can get a > (relatively) clean clock signal on your oscilloscope. Otherwise that > 2GHz ARM clk is just going to be noise ;-) > > These divider values can modeled in the clk framework. Do you know if > you have such stuff on your chip? I believe this is what I have already implemented in my series. The final CLKOUT mux and gates are implemented by separate driver, because they reside in another IP block, while per-domain CLKOUT dividers along with muxes and gates are registered by normal SoC clock driver, because they are part of the clock controller. See patch 2/4 adding the whole hierarchy for Exynos4 SoCs. I don't have boards to test CLKOUT on Exynos5 SoCs, so they are up to interested people. 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] ARM: dts: Add I2S dt node for Exynos3250
Hi Chanwoo,
On 04.07.2014 11:18, Chanwoo Choi wrote:
> Dear Kukjin and Tomasz,
>
> On 07/04/2014 05:05 PM, Tomasz Figa wrote:
>> Hi Chanwoo,
>>
>> On 03.07.2014 09:52, Chanwoo Choi wrote:
>>> From: Tomasz Figa
>>>
>>> This patch add I2S (Inter-IC Sound) dt node which supports 1-port stereo
>>> (1 channels) IIS-bus for audio interface with DMA-based operation.
>>>
>>> Signed-off-by: Tomasz Figa
>>> Signed-off-by: Inha Song
>>> Tested-by: Inha Song
>>> Signed-off-by: Chanwoo Choi
>>> Acked-by: Kyungmin Park
>>> ---
>>> arch/arm/boot/dts/exynos3250.dtsi | 13 +
>>> 1 file changed, 13 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos3250.dtsi
>>> b/arch/arm/boot/dts/exynos3250.dtsi
>>> index 1f8384f..e9017ef 100644
>>> --- a/arch/arm/boot/dts/exynos3250.dtsi
>>> +++ b/arch/arm/boot/dts/exynos3250.dtsi
>>> @@ -644,6 +644,19 @@
>>> status = "disabled";
>>> };
>>>
>>> + i2s: i2s@1397 {
>>
>> Shouldn't the label be rather called "i2s2" as the pinctrl entry below
>> suggests?
>>
>>> + compatible = "samsung,s3c6410-i2s";
>>> + reg = <0x1397 0x100>;
>>> + interrupts = <0 126 0>;
>>> + clocks = <&cmu CLK_I2S>, <&cmu CLK_SCLK_I2S>;
>>> + clock-names = "iis", "i2s_opclk0";
>>> + dmas = <&pdma0 14>, <&pdma0 13>;
>>> + dma-names = "tx", "rx";
>>> + pinctrl-0 = <&i2s2_bus>;
>>> + pinctrl-name = "default";
>>
>> "pinctrl-name" is not a valid property. I suppose it should be
>> "pinctrl-names".
>
> I modify this patch as following. If you confirm following patch, I'll
> re-send patchset(v2).
>
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi
> b/arch/arm/boot/dts/exynos3250.dtsi
> index 3e678fa..77a06df 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -425,6 +425,19 @@
> status = "disabled";
> };
>
> + i2s2: i2s@1397 {
> + compatible = "samsung,s3c6410-i2s";
> + reg = <0x1397 0x100>;
> + interrupts = <0 126 0>;
> + clocks = <&cmu CLK_I2S>, <&cmu CLK_SCLK_I2S>;
> + clock-names = "iis", "i2s_opclk0";
> + dmas = <&pdma0 14>, <&pdma0 13>;
> + dma-names = "tx", "rx";
> + pinctrl-0 = <&i2s2_bus>;
> + pinctrl-names = "default";
> + status = "disabled";
> + };
> +
> pwm: pwm@139D {
> compatible = "samsung,exynos4210-pwm";
> reg = <0x139D 0x1000>;
>
Looks good.
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 6/6] ARM: EXYNOS: Register cpuidle device only on Exynos4210 and 5250
Tomasz Figa wrote:
>
> Currently, the Exynos cpuidle driver works correctly only on Exynos4210
> and 5250. Trying to use it with just one CPU online on any other Exynos
> SoC will lead to system failure, due to unsupported AFTR mode on other
> SoCs. This patch fixes the problem by registering the driver only on
> supported SoCs and letting others simply use default WFI mode until
> support for them is added.
>
Hmm...I thought other SoCs have no problem on cpuidle except exynos5420 and
exynos5440something like this would be helpful to avoid system failure.
But unfortunately this conflicts with Pankaj's cleanup cpufreq_init() and
cpuidle_init() patch you've reviewed and I've applied in my local...
I'm going to check which exynos is ok on cpuidle and then sort them out.
Thanks,
Kukjin
> Signed-off-by: Tomasz Figa
> ---
> arch/arm/mach-exynos/exynos.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
> index f38cf7c..176bbf5 100644
> --- a/arch/arm/mach-exynos/exynos.c
> +++ b/arch/arm/mach-exynos/exynos.c
> @@ -173,10 +173,8 @@ static struct platform_device exynos_cpuidle = {
>
> void __init exynos_cpuidle_init(void)
> {
> - if (soc_is_exynos5440())
> - return;
> -
> - platform_device_register(&exynos_cpuidle);
> + if (soc_is_exynos4210() || soc_is_exynos5250())
> + platform_device_register(&exynos_cpuidle);
> }
>
> void __init exynos_cpufreq_init(void)
> --
> 1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/5] ARM: EXYNOS: Add platform driver support for Exynos PMU
On 05.07.2014 09:09, Pankaj Dubey wrote: > On Monday, June 30, 2014 Tomasz Figa wrote: >> On 25.06.2014 16:03, Pankaj Dubey wrote: >>> + >>> + if (pmu_context->pmu_data && pmu_context->pmu_data->pmu_init) >> >> In what conditions pmu_data will be NULL? >> > > What if we want driver to be probed but no data has been given? > If driver gets probed it still can act as syscon provider, and other IPs can > access > PMU registers, but PMU functionality itself will not be available, for same > reason > I have put a check for pmu_data in powerdown_conf also. > Is there any point in probing this driver just to register the syscon? AFAIK if this driver errors out, the syscon platform driver will take over and do what we want. That's why we have the second "syscon" compatible string. 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 0/2] cpuidle fixes and cleanup
On Tue, Jul 08, 2014 at 03:56:48PM +0200, Tomasz Figa wrote: > On 02.07.2014 05:11, Chander Kashyap wrote: > > On Tue, Jul 1, 2014 at 8:22 PM, Russell King - ARM Linux > > wrote: > >> On Tue, Jul 01, 2014 at 08:02:36PM +0530, Chander Kashyap wrote: > >>> This patch series fixes the cpuidle for different states. Also removes arm > >>> diagnostic and power register save/restore code as it is made generic. > >>> > >>> Based on: > >>> ARM: save/restore diagnostic register on Cortex-A9 suspend/resume > >>> http://www.spinics.net/lists/arm-kernel/msg340506.html > > [Ccing people who participated in discussion in that thread] > > >> > >> As there is an outstanding issue with this patch, we can't proceed with > >> this set of changes until we know what's going on there. > > > > Sure, I will wait for the conclusion. > > So I believe the conclusion was that this can't be handled in generic > way, because on systems running in non-secure mode writing to those > registers faults. That is, unfortunately, correct. There is a way around this, but people aren't going to like it. That is - we move it to the suspend and resume paths anyway. In the resume path, we read the register, compare it with the value which we would update it to, and if it's identical, we avoid the write. This gets secure-mode platforms working. For non-secure mode platforms, we have to require them to insert some assembly code into the early resume path which calls their secure monitor to restore these registers before continuing on to cpu_resume, thereby ensuring that the CPU specific code sees that the value in the register is identical with the saved value, and omitting the write. This isn't really a new principle - we already have this requirement for non-secure mode platforms when they're booting a kernel with various errata enabled. I can't see any other alternative which satisfies everyone (by everyone, I'm including the requirements from the hardware folk who expect these registers to be static once the MMU is enabled.) -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from 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] ARM: Samsung: ADC: Move to clk_prepare_enable/clk_disable_unprepare
Tomasz Figa wrote: > > Hi Vasily, > > On 30.06.2014 21:08, Vasily Khoruzhick wrote: > > Use clk_prepare_enable/clk_disable_unprepare to make the driver > > work properly with common clock framework. > > > > Signed-off-by: Vasily Khoruzhick > > --- > > arch/arm/plat-samsung/adc.c | 8 > > 1 file changed, 4 insertions(+), 4 deletions(-) > > Reviewed-by: Tomasz Figa > Looks good to me, will apply. Thanks, Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 18/19] ARM: SAMSUNG: Remove remaining legacy code
On 04.07.2014 22:23, Arnd Bergmann wrote: > On Friday 04 July 2014 19:48:18 Tomasz Figa wrote: >> After refactoring suspend/resume, which was last part with dependencies >> on legacy code, all Kconfig symbols related to Samsung ATAGS support can >> be deselected and more unused code removed. This includes most of s5p-* >> code as well, as s5pv210 was their last user. >> >> Signed-off-by: Tomasz Figa > > I actually found a few more, see patch below. Feel free to merge it > into yours. Will add your patch to this series, if sending v2. Otherwise I guess it could be applied on top of it. > > As discussed on IRC, I have also done an experimental patch to move > the few contents of mach-s5pv210 into mach-exynos, which turned out > very simple and should be uncontroversial but needs more testing. > > Finally, there is some more cleanup potential in moving things out > of plat-samsung into the individual platforms (s3c24xx, s3c64xx, > exynos including s5pv210), as a lot of files are now only used > on one of them. > > I tried moving everything that the combined mach-exynos needs out > of plat-samsung, but that resulted in about 500-600 lines of duplication > between s3c and exynos for pm-common.c, pm-common.h, pmdebug.c > and pm-check.c, so those four files should probably remain shared > for now. OK. 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: [RFC PATCH 1/3] watchdog: s3c2410: add restart notifier
Hi Heiko,
On 06.07.2014 20:42, Heiko Stübner wrote:
> On a lot of Samsung systems the watchdog is responsible for restarting the
> system and until now this code was contained in plat-samsung/watchdog-reset.c
> .
>
> With the introduction of the restart notifiers, this code can now move into
> driver itself, removing the need for arch-specific code.
>
> Tested on a S3C2442 based GTA02
> Signed-off-by: Heiko Stuebner
> ---
> drivers/watchdog/s3c2410_wdt.c | 33 +
> 1 file changed, 33 insertions(+)
>
> diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
> index 7c6ccd0..3f89912 100644
> --- a/drivers/watchdog/s3c2410_wdt.c
> +++ b/drivers/watchdog/s3c2410_wdt.c
> @@ -41,6 +41,7 @@
> #include
> #include
> #include
> +#include
>
> #define S3C2410_WTCON0x00
> #define S3C2410_WTDAT0x04
> @@ -438,6 +439,31 @@ static inline void s3c2410wdt_cpufreq_deregister(struct
> s3c2410_wdt *wdt)
> }
> #endif
>
> +static struct s3c2410_wdt *s3c2410wdt_restart_ctx;
This isn't the most elegant way to store context data. Maybe you could
embed the notifier_block struct into s3c2410_wdt struct and then use
container of to retrieve it from s3c2410wdt_restart_notify()?
> +static int s3c2410wdt_restart_notify(struct notifier_block *this,
> + unsigned long mode, void *cmd)
> +{
> + void __iomem *wdt_base = s3c2410wdt_restart_ctx->reg_base;
> +
> + /* disable watchdog, to be safe */
> + writel(0, wdt_base + S3C2410_WTCON);
> +
> + /* put initial values into count and data */
> + writel(0x80, wdt_base + S3C2410_WTCNT);
> + writel(0x80, wdt_base + S3C2410_WTDAT);
> +
> + /* set the watchdog to go and reset... */
> + writel(S3C2410_WTCON_ENABLE | S3C2410_WTCON_DIV16 |
> + S3C2410_WTCON_RSTEN | S3C2410_WTCON_PRESCALE(0x20),
> + wdt_base + S3C2410_WTCON);
I wonder whether you shouldn't wait a bit here for the reset to be
actually triggered.
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: [RFC PATCH 2/3] clk: samsung: register restart notifiers for s3c2412 and s3c2443
Hi Heiko, On 06.07.2014 20:43, Heiko Stübner wrote: > S3C2412, S3C2443 and their derivatives contain a special software-reset > register in their system-controller. > > Therefore register a restart-notifier for those. I wonder if we really need to differentiate between these SoCs instead of just using the watchdog reset for all of them. If there is no reason to prefer software reset, then some code could be removed and things would be more unified. 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 v6 1/4] ARM: EXYNOS: Add support for mapping PMU base address via DT
On 07.07.2014 07:19, Pankaj Dubey wrote: > Add support for mapping Samsung Power Management Unit (PMU) > base address from device tree. > > Signed-off-by: Pankaj Dubey > --- > arch/arm/mach-exynos/common.h |1 + > arch/arm/mach-exynos/exynos.c | 37 + > 2 files changed, 38 insertions(+) > Thanks for keeping up with addressing the comments. Reviewed-by: Tomasz Figa -- 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 v6 2/4] ARM: EXYNOS: Refactored code for using PMU address via DT
Hi Pankaj,
Except one minor comment inline, looks good.
On 07.07.2014 07:19, Pankaj Dubey wrote:
[snip]
> diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
> b/arch/arm/mach-exynos/mcpm-exynos.c
> index 9315ba9..8f6a111 100644
> --- a/arch/arm/mach-exynos/mcpm-exynos.c
> +++ b/arch/arm/mach-exynos/mcpm-exynos.c
> @@ -55,7 +55,7 @@
> "dsb\n\t" \
> "ldmfd sp!, {fp, ip}" \
> : \
> - : "Ir" (S5P_INFORM0) \
> + : "Ir" (pmu_base_addr + S5P_INFORM0) \
> : "r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7", \
> "r9", "r10", "lr", "memory")
>
> @@ -337,7 +337,8 @@ static int __init exynos_mcpm_init(void)
>* To increase the stability of KFC reset we need to program
>* the PMU SPARE3 register
>*/
> - __raw_writel(EXYNOS5420_SWRESET_KFC_SEL, S5P_PMU_SPARE3);
> + __raw_writel(EXYNOS5420_SWRESET_KFC_SEL,
> + pmu_base_addr + S5P_PMU_SPARE3);
Here's yet another place where pmu_raw_writel() helper could be used.
Maybe move them to a header, even common.h and then use whenever PMU is
accessed in arch code.
With this minor thing fixed, feel free to add
Reviewed-by: Tomasz Figa
--
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 v6 3/4] ARM: EXYNOS: Add platform driver support for Exynos PMU
Hi Pankaj,
Just one comment I already had to previous version.
On 07.07.2014 07:19, Pankaj Dubey wrote:
[snip]
> -static void exynos5_init_pmu(void)
> +static void exynos5_powerdown_conf(enum sys_powerdown mode)
> {
> unsigned int i;
> unsigned int tmp;
> @@ -382,51 +398,143 @@ void exynos_sys_powerdown_conf(enum sys_powerdown mode)
> {
> unsigned int i;
>
> - if (soc_is_exynos5250())
> - exynos5_init_pmu();
> + const struct exynos_pmu_data *pmu_data = pmu_context->pmu_data;
> +
> + if (!pmu_data)
> + return;
As I mentioned in my reply to previous version, I don't think there is
any point in probing this driver when there is no pmu_data. AFAIK the
generic syscon driver can take over in such case.
After fixing this, feel free to add
Reviewed-by: Tomasz Figa
--
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] drivers: phy: exynos-usb2: add support for Exynos 3250
On 07.07.2014 11:39, Marek Szyprowski wrote: > This patch adds support for Exynos3250 SoC to Exynos2USB PHY driver. > Although Exynos3250 has only one device phy interface, the register > layout and all operations that are required to get it enabled are almost > same as on Exynos4x12. The only different is one more register > (REFCLKSEL) which need to be set and lack of MODE SWITCH register. > > Signed-off-by: Marek Szyprowski > --- > > Changelog: > v2: > - added new binding documentation > - removed superfluous defines > - removed mode switch for 3250, because it is not really needed > > --- > Documentation/devicetree/bindings/phy/samsung-phy.txt | 2 ++ > drivers/phy/Kconfig | 12 ++-- > drivers/phy/phy-exynos4x12-usb2.c | 17 +++-- > drivers/phy/phy-samsung-usb2.c| 6 ++ > drivers/phy/phy-samsung-usb2.h| 2 ++ > 5 files changed, 31 insertions(+), 8 deletions(-) > Reviewed-by: Tomasz Figa -- 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 v6 4/4] ARM: EXYNOS: Move PMU specific definitions from common.h
On 07.07.2014 07:19, Pankaj Dubey wrote: > This patch moves PMU specific definitions into a new file > as exynos-pmu.h. > This will help in reducing dependency of common.h in pmu.c. > > Signed-off-by: Pankaj Dubey > --- > arch/arm/mach-exynos/common.h | 17 - > arch/arm/mach-exynos/exynos-pmu.h | 24 > arch/arm/mach-exynos/pm.c |1 + > arch/arm/mach-exynos/pmu.c| 10 +- > 4 files changed, 34 insertions(+), 18 deletions(-) > create mode 100644 arch/arm/mach-exynos/exynos-pmu.h > Reviewed-by: Tomasz Figa -- 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 v7] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
On Tue, Jul 08, 2014 at 02:39:37PM +0100, Abhilash Kesavan wrote: > Hi Lorenzo, > > On Tue, Jul 8, 2014 at 4:23 PM, Lorenzo Pieralisi > wrote: > > On Fri, Jul 04, 2014 at 10:21:56PM +0100, Abhilash Kesavan wrote: > >> On Sat, Jul 5, 2014 at 2:30 AM, Nicolas Pitre > >> wrote: > >> > On Sat, 5 Jul 2014, Abhilash Kesavan wrote: > >> > > >> >> Use the MCPM layer to handle core suspend/resume on Exynos5420. > >> >> Also, restore the entry address setup code post-resume. > >> >> > >> >> Signed-off-by: Abhilash Kesavan > >> > > >> > Acked-by: Nicolas Pitre > >> This is one of the last missing bits for exynos MCPM. Thanks for your > >> patient reviews of all the exynos mcpm back-end patches. > > > > Sorry for the delay in getting back to you. > Thanks for your comments. > > > > You still need to handle the residency parameter in the MCPM suspend call > > properly to differentiate between core gating and cluster gating. > I am not too familiar with the cpuidle driver, but I see only cluster > power off state listed in the bL cpuidle driver. > > > > CPUidle might want to request a state that allows for core gating > > residency but not cluster gating one, in that case the last man > > standing must not shutdown the cluster. > For this, I would have to add another state to the bL cpuidle driver > or migrate to using your under-review generic idle state patchset. > Then based on the residency value skip/do cluster power down. Is this > correct ? > > > > This must be handled in the power down function, and it can be done > > in a separate patch since it is an optimization. Current MCPM interface has > > all it is needed to handle this properly, and I am keen on patching the > > CPUidle bL driver to pass the actual residency instead of hardcoding it > > to 0 (ie on TC2 it was not needed, no core gating). > I will look at doing this once the s2r patch gets merged. Ok, let's get it done once the CPUidle bL driver DT version gets merged, I will add a patch that passes the proper residency and you can patch the MCPM back-end then, until then CPUidle will be suboptimal but I guess we can live with that for now. Thanks, Lorenzo -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: exynos: remove unused
On Wed, Jul 2, 2014 at 3:27 PM, Uwe Kleine-König wrote: > ARCH_EXYNOS doesn't select NEED_MACH_MEMORY_H, so doesn't > include and so this file is not used and can go away. > > Signed-off-by: Uwe Kleine-König > --- Reviewed-by: Sachin Kamat Tested on Arndale octa board (Exynos 5420). Tested-by: Sachin Kamat -- 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] ARM: dts: Add mask-tpm-reset to the device tree
Hi,
On Tue, Jul 8, 2014 at 12:46 AM, Linus Walleij wrote:
> On Thu, Jun 26, 2014 at 11:15 AM, Vikas Sajjan
> wrote:
>
>> From: Doug Anderson
>>
>> The mask-tpm-reset GPIO is used by the kernel to prevent the TPM from
>> being reset across sleep/wake. If we don't set it to anything then
>> the TPM will be reset. U-Boot will detect this as invalid
>> and will reset the system on resume time. This GPIO can always be low
>> and not hurt anything. It will get pulled back high again during a
>> normal warm reset when it will default back to an input.
>>
>> To properly preserve the TPM state across suspend/resume and to make
>> the chrome U-Boot happy, properly set the GPIO to mask the
>> reset to the TPM.
>>
>> Signed-off-by: Doug Anderson
>> Signed-off-by: Vikas Sajjan
> (...)
>> + /* We need GPX0_6 to be low at sleep time; just keep it low always */
>> + mask_tpm_reset_regulator: mask-tpm-reset-regulator {
>> + compatible = "regulator-fixed";
>
> No matter how the discussion ends up, regulator-fixed is wrong.
OK, fair enough.
> Either folding it into the TPM driver or using a separate reset driver
> is fine with me.
OK, Vikas: do you want to code up the driver?
> So what about the generic delayed reset GPIO thing?
> http://marc.info/?l=linux-kernel&m=140309916607115&w=2
That's a neat concept and could be useful in other cases, but I think
it's just as much of a hack as using a regulator. This is not a reset
signal for the TPM. This is a signal that will mask the CPU's reset
signal (using a special bit of board-specific logic).
Personally I think Tomasz's idea of using hogs (after his patches
allowing a default output level) is the cleanest, but I think Stephen
didn't like that.
-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] ARM: dts: exynos 3250: add hsotg and usb2phy device nodes
On 07.07.2014 11:39, Marek Szyprowski wrote:
> This patch adds device tree nodes required to enable support for USB
> device controller.
>
> Signed-off-by: Marek Szyprowski
> ---
> Changelog:
> v2:
> - removed phandle to syscon, because mode switch register is not needed for
> 3250.
> ---
> arch/arm/boot/dts/exynos3250.dtsi | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi
> b/arch/arm/boot/dts/exynos3250.dtsi
> index eb457620975b..64a0ef44325a 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -309,6 +309,27 @@
> status = "disabled";
> };
>
> + hsotg: hsotg@1248 {
> + compatible = "samsung,s3c6400-hsotg";
> + reg = <0x1248 0x2>;
> + interrupts = <0 141 0>;
> + clocks = <&cmu CLK_USBOTG>;
> + clock-names = "otg";
> + phys = <&exynos_usbphy 0>;
> + phy-names = "usb2-phy";
> + status = "disabled";
> + };
> +
> + exynos_usbphy: exynos-usbphy@125B {
> + compatible = "samsung,exynos3250-usb2-phy";
> + reg = <0x125B 0x100>;
> + samsung,pmureg-phandle = <&pmu_system_controller>;
> + clocks = <&cmu CLK_USBOTG>, <&xusbxti>;
> + clock-names = "phy", "ref";
Are you sure these are right clocks for Exynos3250? I thought the ref
clock was supposed to be SCLK_UPLL on this SoC.
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] ARM: dts: remove display power domain for exynos5420
Hi Rahul, On 07.07.2014 15:37, Rahul Sharma wrote: > Hi Andrej, Inki, > > On 18 June 2014 12:06, Rahul Sharma wrote: >> Hi Andrej, >> >> On 18 June 2014 11:46, Andrzej Hajda wrote: >>> On 06/17/2014 07:49 AM, Rahul Sharma wrote: Hi All, Please review this patch. Regards, Rahul Sharma On 9 June 2014 16:58, Rahul Sharma wrote: > Display domain is removed due to instability issues. Explaining > the problem below: > > exynos_init_late triggers the pm_genpd_poweroff_unused which > powers off the unused power domains. This call hits before > the trigger to deferred probes. > > DRM DP Panel defers the probe due to supply get failure. By the > time, deferred probe is scheduled again, Display Power Domain is > powered off by pm_genpd_poweroff_unused. > > FIMD and DP drivers are accessing registers during Probe and Bind > callbacks. If display domain is enabled/disabled around register > accesses, display domain gets unstable and we are getting Power > Domain Disable fail notification. Increasing the Timeout also > didn't help. >>> >>> As I understand the problem is that fimd and dp drivers access hw >>> registers without enabling power domain. So the proper solution is to >>> fix these drivers. >> >> That is also a problem but I fixed those accesses in my local kernel before >> hitting this issue. If we do register accesses in FIMD/DP probe/bind we >> observes "Prefetch abort" exception. But here the problem is that 'DP >> domain disable' starts failing if we enable/disable multiple times. >> >>> >>> Btw. there are already patches removing hw access from probe/bind of >>> fimd. I guess removing also hw access from dp probe/bind could be a good >>> solution. >> >> Please let me know the links for posted patches. I will test with those >> patches. > > Is there any update on this? Please share the patches which fixes the > above issue or avoid the above scenario of multiple PM Domain enable/disable. > I will test them for exynos5 based boards. Otherwise we should get this change > merged else display will remain broken for exynos5 based boards. Andrzej is on holidays right now, so he won't be able to reply in this thread until he's back. Here are two patches I was able to find on the related MLs that might be fixing the cause of your issues: [PATCH] drm/exynos: remove hardware overlays disable from fimd probe (https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg31629.html) [PATCH] drm/exynos: fimd: Keep power enabled during fimd_bind (https://lkml.org/lkml/2014/7/4/188) 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 05/17] pwm: samsung: remove s5p64x0 related pwm codes
Kukjin,
On 08.07.2014 00:23, Kukjin Kim wrote:
> On 07/04/14 17:10, Tomasz Figa wrote:
>> Hi Kukjin,
>>
> Tomasz,
>
>> On 30.06.2014 23:32, Kukjin Kim wrote:
>>> This patch removes supporting s5p64x0 related pwm codes because of
>>> no more support for S5P6440 and S5P6450 SoCs. And this patch changes
>>> the name of s5p6440-pwm to exynos-pwm instead.
>>>
>>> Signed-off-by: Kukjin Kim
>>> Cc: Thierry Reding
>>> ---
>>> Documentation/devicetree/bindings/pwm/pwm-samsung.txt |1 -
>>> arch/arm/boot/dts/exynos4210-universal_c210.dts |2 +-
>>> drivers/clocksource/samsung_pwm_timer.c | 13 -
>>> drivers/pwm/pwm-samsung.c |5 ++---
>>> 4 files changed, 3 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
>>> b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
>>> index 5538de9..43925d3 100644
>>> --- a/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
>>> +++ b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
>>> @@ -11,7 +11,6 @@ Required properties:
>>> - compatible : should be one of following:
>>> samsung,s3c2410-pwm - for 16-bit timers present on S3C24xx SoCs
>>> samsung,s3c6400-pwm - for 32-bit timers present on S3C64xx SoCs
>>> -samsung,s5p6440-pwm - for 32-bit timers present on S5P64x0 SoCs
>>> samsung,s5pc100-pwm - for 32-bit timers present on S5PC100, S5PV210,
>>> Exynos4210 rev0 SoCs
>>> samsung,exynos4210-pwm - for 32-bit timers present on Exynos4210,
>>> diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
>>> b/arch/arm/boot/dts/exynos4210-universal_c210.dts
>>> index d50eb3a..0ca26e0 100644
>>> --- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
>>> +++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
>>> @@ -461,7 +461,7 @@
>>> };
>>>
>>> pwm@139D {
>>> - compatible = "samsung,s5p6440-pwm";
>>> + compatible = "samsung,exynos4210-pwm";
>>
>> There is a reason to use a different compatible string for Exynos4210
>> rev0. The PWM block is used as a timer there, while on newer revs MCT is
>> used. Sorry, but I have to NAK this patch.
>>
> I remember why exynos4210-universal_c210 uses PWM...OK.
>
>> As I explained in my reply to patch 11/17, I'd suggest keeping the PWM
>> drivers as is, because there is no need to remove support for DT
>> compatible strings.
>>
> OK, let me remove pwm related patches in this series but I think need to
> update the compatible strings, at least remove non-support SoC in doc?...
Device tree bindings are defined according to the first SoC in which
given hardware variant appeared and since they are stable, they should
stay as is. I don't think it will have any negative effects on
maintenance costs and it doesn't imply that the SoC is still supported.
(Anyway, with DT you can boot virtually any SoC, without the kernel
being aware of it, as long as it supports all the necessary IP blocks.)
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 6/6] ARM: EXYNOS: Register cpuidle device only on Exynos4210 and 5250
Hi, On Tuesday, July 08, 2014 11:15:21 PM Kukjin Kim wrote: > Tomasz Figa wrote: > > > > Currently, the Exynos cpuidle driver works correctly only on Exynos4210 > > and 5250. Trying to use it with just one CPU online on any other Exynos > > SoC will lead to system failure, due to unsupported AFTR mode on other > > SoCs. This patch fixes the problem by registering the driver only on > > supported SoCs and letting others simply use default WFI mode until > > support for them is added. > > > Hmm...I thought other SoCs have no problem on cpuidle except exynos5420 and > exynos5440something like this would be helpful to avoid system failure. > But unfortunately this conflicts with Pankaj's cleanup cpufreq_init() and > cpuidle_init() patch you've reviewed and I've applied in my local... > > I'm going to check which exynos is ok on cpuidle and then sort them out. Tomasz's patch is correct - currently only Exynos4210 and Exynos5250 work fine with AFTR mode and upstream kernel (AFTR gets triggered by offlining CPUs other than CPU0). [ Exynos4x12 and Exynos3250 need secure firmware support (patches for this need to be reworked on top of recent PM/firmware/cpuidle changes). Exynos5410 should use big_little cpuidle driver. ] Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] phy: Kconfig: Re-organize Exynos USB 2.0 PHY configs
On 30.06.2014 10:56, Sachin Kamat wrote: > Since the USB 2.0 PHYs are required only with EHCI/OHCI USB drivers, That's not true. They are also required for USB gadget controller supported by the DWC2 gadget driver (formerly s3c-hsotg). Otherwise the change makes sense to me. 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: [RFC] drm/exynos: abort commit when framebuffer is removed from plane
2014-06-20 0:13 GMT+09:00 Rahul Sharma :
> 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.
If user process requested drm_mode_rmfb with a fb_id, fb object to the
fb_id must be removed from crtc_idr table. So drm_mode_setcrtc should
be failed because there is no the fb object in the crtc_idr table
anymore.
I cannot understand how exynos_drm_crtc_plane_commit function could be
called. Can you give me more details?
Thanks,
Inki Dae
>
> 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
--
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] drm/exynos: fimd: Keep power enabled during fimd_bind
Thanks for patch. 2014-07-04 19:33 GMT+09:00 Tushar Behera : > Under some conditions (when IOMMU is enabled), fimd_bind() accesses > hardware registers and power-domain should be enabled during that time. > > fimd_bind --> fimd_mgr_initialize --> fimd_clear_channel > > If the power-domain is disabled by that time, we get a boot-time crash. > It would be better to keep power-domain enabled explicitly. > > Unhandled fault: external abort on non-linefetch (0x1008) at 0xf0180034 > Internal error: : 1008 [#1] PREEMPT SMP ARM > ... > PC is at fimd_bind+0x84/0x134 > LR is at component_bind_all+0xb4/0x1d8 > > Signed-off-by: Tushar Behera > --- > drivers/gpu/drm/exynos/exynos_drm_fimd.c |4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c > b/drivers/gpu/drm/exynos/exynos_drm_fimd.c > index 33161ad..34275fb 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c > @@ -888,11 +888,15 @@ static int fimd_bind(struct device *dev, struct device > *master, void *data) > struct fimd_context *ctx = fimd_manager.ctx; > struct drm_device *drm_dev = data; > > + pm_runtime_get_sync(dev); > + fimd driver has no runtime pm interfaces so pm_runtime_get_sync call will enable lcd0 power domain. So shouldn't fimd clock also be enabled? > fimd_mgr_initialize(&fimd_manager, drm_dev); And here would be good to call clk_disable_unprepare() and pm_runtime_put_sync(). Below codes don't access any fimd register. Or move these function calls into fimd_mgr_initialize(). Thanks, Inki Dae > exynos_drm_crtc_create(&fimd_manager); > if (ctx->display) > exynos_drm_create_enc_conn(drm_dev, ctx->display); > > + pm_runtime_put_sync(dev); > + > return 0; > > } > -- > 1.7.9.5 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 06/14] drm/exynos: fimd: support LCD I80 interface
2014-07-08 9:39 GMT+09:00 YoungJun Cho :
> To support MIPI command mode based I80 interface panel,
> FIMD should do followings:
> - Sets LCD I80 interface timings configuration.
> - Uses "lcd_sys" as an IRQ resource and sets relevant IRQ configuration.
> - Sets LCD block configuration for I80 interface.
> - Sets ideal(pixel) clock is 2 times faster than the original one
> to generate frame done IRQ prior to the next TE signal.
> - Implements trigger feature that transfers image data if there is page
> flip request, and implements TE handler to call trigger function.
>
> Signed-off-by: YoungJun Cho
> Acked-by: Inki Dae
> Acked-by: Kyungmin Park
> ---
> drivers/gpu/drm/exynos/Kconfig | 1 +
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 276
> ++-
> include/video/samsung_fimd.h | 3 +-
> 3 files changed, 235 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index 178d2a9..9ba1aae 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -28,6 +28,7 @@ config DRM_EXYNOS_FIMD
> bool "Exynos DRM FIMD"
> depends on DRM_EXYNOS && !FB_S3C
> select FB_MODE_HELPERS
> + select MFD_SYSCON
> help
> Choose this option if you want to use Exynos FIMD for DRM.
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 33161ad..207872d 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -20,6 +20,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
> #include
> @@ -61,6 +63,24 @@
> /* color key value register for hardware window 1 ~ 4. */
> #define WKEYCON1_BASE(x) ((WKEYCON1 + 0x140) + ((x - 1) * 8))
>
> +/* I80 / RGB trigger control register */
> +#define TRIGCON0x1A4
> +#define TRGMODE_I80_RGB_ENABLE_I80 (1 << 0)
> +#define SWTRGCMD_I80_RGB_ENABLE(1 << 1)
> +
> +/* display mode change control register except exynos4 */
> +#define VIDOUT_CON 0x000
> +#define VIDOUT_CON_F_I80_LDI0 (0x2 << 8)
> +
> +/* I80 interface control for main LDI register */
> +#define I80IFCONFAx(x) (0x1B0 + (x) * 4)
> +#define I80IFCONFBx(x) (0x1B8 + (x) * 4)
> +#define LCD_CS_SETUP(x)((x) << 16)
> +#define LCD_WR_SETUP(x)((x) << 12)
> +#define LCD_WR_ACTIVE(x) ((x) << 8)
> +#define LCD_WR_HOLD(x) ((x) << 4)
> +#define I80IFEN_ENABLE (1 << 0)
> +
> /* FIMD has totally five hardware windows. */
> #define WINDOWS_NR 5
>
> @@ -68,10 +88,14 @@
>
> struct fimd_driver_data {
> unsigned int timing_base;
> + unsigned int lcdblk_offset;
> + unsigned int lcdblk_vt_shift;
> + unsigned int lcdblk_bypass_shift;
>
> unsigned int has_shadowcon:1;
> unsigned int has_clksel:1;
> unsigned int has_limited_fmt:1;
> + unsigned int has_vidoutcon:1;
> };
>
> static struct fimd_driver_data s3c64xx_fimd_driver_data = {
> @@ -82,12 +106,19 @@ static struct fimd_driver_data s3c64xx_fimd_driver_data
> = {
>
> static struct fimd_driver_data exynos4_fimd_driver_data = {
> .timing_base = 0x0,
> + .lcdblk_offset = 0x210,
> + .lcdblk_vt_shift = 10,
> + .lcdblk_bypass_shift = 1,
> .has_shadowcon = 1,
> };
>
> static struct fimd_driver_data exynos5_fimd_driver_data = {
> .timing_base = 0x2,
> + .lcdblk_offset = 0x214,
> + .lcdblk_vt_shift = 24,
> + .lcdblk_bypass_shift = 15,
> .has_shadowcon = 1,
> + .has_vidoutcon = 1,
> };
>
> struct fimd_win_data {
> @@ -112,15 +143,22 @@ struct fimd_context {
> struct clk *bus_clk;
> struct clk *lcd_clk;
> void __iomem*regs;
> + struct regmap *sysreg;
> struct drm_display_mode mode;
> struct fimd_win_datawin_data[WINDOWS_NR];
> unsigned intdefault_win;
> unsigned long irq_flags;
> + u32 vidcon0;
> u32 vidcon1;
> + u32 vidout_con;
> + u32 i80ifcon;
> + booli80_if;
> boolsuspended;
> int pipe;
> wait_queue_head_t wait_vsync_queue;
> atomic_twait_vsync_event;
> + atomic_twin_updated;
> + atomic_ttriggering;
>
> struct exynos_drm_panel_info panel;
> struct fimd_driver_data *driv
Re: [RFC PATCH 1/3] watchdog: s3c2410: add restart notifier
On Tue, Jul 08, 2014 at 04:21:09PM +0200, Tomasz Figa wrote: > Hi Heiko, > > On 06.07.2014 20:42, Heiko Stübner wrote: > > On a lot of Samsung systems the watchdog is responsible for restarting the > > system and until now this code was contained in > > plat-samsung/watchdog-reset.c . > > > > With the introduction of the restart notifiers, this code can now move into > > driver itself, removing the need for arch-specific code. > > > > Tested on a S3C2442 based GTA02 > > Signed-off-by: Heiko Stuebner > > --- > > drivers/watchdog/s3c2410_wdt.c | 33 + > > 1 file changed, 33 insertions(+) > > > > diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c > > index 7c6ccd0..3f89912 100644 > > --- a/drivers/watchdog/s3c2410_wdt.c > > +++ b/drivers/watchdog/s3c2410_wdt.c > > @@ -41,6 +41,7 @@ > > #include > > #include > > #include > > +#include > > > > #define S3C2410_WTCON 0x00 > > #define S3C2410_WTDAT 0x04 > > @@ -438,6 +439,31 @@ static inline void > > s3c2410wdt_cpufreq_deregister(struct s3c2410_wdt *wdt) > > } > > #endif > > > > +static struct s3c2410_wdt *s3c2410wdt_restart_ctx; > > This isn't the most elegant way to store context data. Maybe you could > embed the notifier_block struct into s3c2410_wdt struct and then use > container of to retrieve it from s3c2410wdt_restart_notify()? > Excellent idea. I'll do that for the moxart handler as well. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/3] clk: samsung: register restart notifiers for s3c2412 and s3c2443
On Tue, Jul 08, 2014 at 04:24:34PM +0200, Tomasz Figa wrote: > Hi Heiko, > > On 06.07.2014 20:43, Heiko Stübner wrote: > > S3C2412, S3C2443 and their derivatives contain a special software-reset > > register in their system-controller. > > > > Therefore register a restart-notifier for those. > > I wonder if we really need to differentiate between these SoCs instead > of just using the watchdog reset for all of them. If there is no reason > to prefer software reset, then some code could be removed and things > would be more unified. > Depends if the other method is always available. If not, it might make sense to register this handler with lower priority to have a fallback. Guenter -- 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: dts: Add mask-tpm-reset to the device tree
On 08.07.2014 17:27, Doug Anderson wrote:
> Hi,
>
> On Tue, Jul 8, 2014 at 12:46 AM, Linus Walleij
> wrote:
>> On Thu, Jun 26, 2014 at 11:15 AM, Vikas Sajjan
>> wrote:
>>
>>> From: Doug Anderson
>>>
>>> The mask-tpm-reset GPIO is used by the kernel to prevent the TPM from
>>> being reset across sleep/wake. If we don't set it to anything then
>>> the TPM will be reset. U-Boot will detect this as invalid
>>> and will reset the system on resume time. This GPIO can always be low
>>> and not hurt anything. It will get pulled back high again during a
>>> normal warm reset when it will default back to an input.
>>>
>>> To properly preserve the TPM state across suspend/resume and to make
>>> the chrome U-Boot happy, properly set the GPIO to mask the
>>> reset to the TPM.
>>>
>>> Signed-off-by: Doug Anderson
>>> Signed-off-by: Vikas Sajjan
>> (...)
>>> + /* We need GPX0_6 to be low at sleep time; just keep it low always
>>> */
>>> + mask_tpm_reset_regulator: mask-tpm-reset-regulator {
>>> + compatible = "regulator-fixed";
>>
>> No matter how the discussion ends up, regulator-fixed is wrong.
>
> OK, fair enough.
>
>
>> Either folding it into the TPM driver or using a separate reset driver
>> is fine with me.
>
> OK, Vikas: do you want to code up the driver?
>
>
>> So what about the generic delayed reset GPIO thing?
>> http://marc.info/?l=linux-kernel&m=140309916607115&w=2
>
> That's a neat concept and could be useful in other cases, but I think
> it's just as much of a hack as using a regulator. This is not a reset
> signal for the TPM. This is a signal that will mask the CPU's reset
> signal (using a special bit of board-specific logic).
>
>
> Personally I think Tomasz's idea of using hogs (after his patches
> allowing a default output level) is the cleanest, but I think Stephen
> didn't like that.
I don't see any benefits of using complex interfaces over simply
initializing the pin to the right value once at boot-up or at
suspend/resume. As far as I understand Doug's explanation of the
problem, nothing else is expected from the OS with respect to this pin.
Moreover it doesn't affect operation of any drivers.
So I'm still for the simplest and effective solution, i.e. hogs.
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
[PATCH v5 06/14] drm/exynos: fimd: support LCD I80 interface
To support MIPI command mode based I80 interface panel,
FIMD should do followings:
- Sets LCD I80 interface timings configuration.
- Uses "lcd_sys" as an IRQ resource and sets relevant IRQ configuration.
- Sets LCD block configuration for I80 interface.
- Sets ideal(pixel) clock is 2 times faster than the original one
to generate frame done IRQ prior to the next TE signal.
- Implements trigger feature that transfers image data if there is page
flip request, and implements TE handler to call trigger function.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/exynos/Kconfig | 1 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 276 ++-
include/video/samsung_fimd.h | 3 +-
3 files changed, 235 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 178d2a9..9ba1aae 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -28,6 +28,7 @@ config DRM_EXYNOS_FIMD
bool "Exynos DRM FIMD"
depends on DRM_EXYNOS && !FB_S3C
select FB_MODE_HELPERS
+ select MFD_SYSCON
help
Choose this option if you want to use Exynos FIMD for DRM.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 33161ad..28a3168 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -20,6 +20,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -61,6 +63,24 @@
/* color key value register for hardware window 1 ~ 4. */
#define WKEYCON1_BASE(x) ((WKEYCON1 + 0x140) + ((x - 1) * 8))
+/* I80 / RGB trigger control register */
+#define TRIGCON0x1A4
+#define TRGMODE_I80_RGB_ENABLE_I80 (1 << 0)
+#define SWTRGCMD_I80_RGB_ENABLE(1 << 1)
+
+/* display mode change control register except exynos4 */
+#define VIDOUT_CON 0x000
+#define VIDOUT_CON_F_I80_LDI0 (0x2 << 8)
+
+/* I80 interface control for main LDI register */
+#define I80IFCONFAx(x) (0x1B0 + (x) * 4)
+#define I80IFCONFBx(x) (0x1B8 + (x) * 4)
+#define LCD_CS_SETUP(x)((x) << 16)
+#define LCD_WR_SETUP(x)((x) << 12)
+#define LCD_WR_ACTIVE(x) ((x) << 8)
+#define LCD_WR_HOLD(x) ((x) << 4)
+#define I80IFEN_ENABLE (1 << 0)
+
/* FIMD has totally five hardware windows. */
#define WINDOWS_NR 5
@@ -68,10 +88,14 @@
struct fimd_driver_data {
unsigned int timing_base;
+ unsigned int lcdblk_offset;
+ unsigned int lcdblk_vt_shift;
+ unsigned int lcdblk_bypass_shift;
unsigned int has_shadowcon:1;
unsigned int has_clksel:1;
unsigned int has_limited_fmt:1;
+ unsigned int has_vidoutcon:1;
};
static struct fimd_driver_data s3c64xx_fimd_driver_data = {
@@ -82,12 +106,19 @@ static struct fimd_driver_data s3c64xx_fimd_driver_data = {
static struct fimd_driver_data exynos4_fimd_driver_data = {
.timing_base = 0x0,
+ .lcdblk_offset = 0x210,
+ .lcdblk_vt_shift = 10,
+ .lcdblk_bypass_shift = 1,
.has_shadowcon = 1,
};
static struct fimd_driver_data exynos5_fimd_driver_data = {
.timing_base = 0x2,
+ .lcdblk_offset = 0x214,
+ .lcdblk_vt_shift = 24,
+ .lcdblk_bypass_shift = 15,
.has_shadowcon = 1,
+ .has_vidoutcon = 1,
};
struct fimd_win_data {
@@ -112,15 +143,22 @@ struct fimd_context {
struct clk *bus_clk;
struct clk *lcd_clk;
void __iomem*regs;
+ struct regmap *sysreg;
struct drm_display_mode mode;
struct fimd_win_datawin_data[WINDOWS_NR];
unsigned intdefault_win;
unsigned long irq_flags;
+ u32 vidcon0;
u32 vidcon1;
+ u32 vidout_con;
+ u32 i80ifcon;
+ booli80_if;
boolsuspended;
int pipe;
wait_queue_head_t wait_vsync_queue;
atomic_twait_vsync_event;
+ atomic_twin_updated;
+ atomic_ttriggering;
struct exynos_drm_panel_info panel;
struct fimd_driver_data *driver_data;
@@ -243,6 +281,14 @@ static u32 fimd_calc_clkdiv(struct fimd_context *ctx,
unsigned long ideal_clk = mode->htotal * mode->vtotal * mode->vrefresh;
u32 clkdiv;
+ if (ctx->i80_if) {
+ /*
+* The frame done interrupt sho
Re: [PATCH] Input: s3c2410_ts: Move to clk_prepare_enable/clk_disable_unprepare
On Mon, Jun 30, 2014 at 10:09:37PM +0300, Vasily Khoruzhick wrote:
> Use clk_prepare_enable/clk_disable_unprepare to make the driver
> work properly with common clock framework.
>
> Signed-off-by: Vasily Khoruzhick
> ---
> drivers/input/touchscreen/s3c2410_ts.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/input/touchscreen/s3c2410_ts.c
> b/drivers/input/touchscreen/s3c2410_ts.c
> index 19cb247..c0e0baa 100644
> --- a/drivers/input/touchscreen/s3c2410_ts.c
> +++ b/drivers/input/touchscreen/s3c2410_ts.c
> @@ -264,7 +264,7 @@ static int s3c2410ts_probe(struct platform_device *pdev)
> return -ENOENT;
> }
>
> - clk_enable(ts.clock);
> + clk_prepare_enable(ts.clock);
> dev_dbg(dev, "got and enabled clocks\n");
>
> ts.irq_tc = ret = platform_get_irq(pdev, 0);
> @@ -369,7 +369,7 @@ static int s3c2410ts_remove(struct platform_device *pdev)
> free_irq(ts.irq_tc, ts.input);
> del_timer_sync(&touch_timer);
>
> - clk_disable(ts.clock);
> + clk_disable_unprepare(ts.clock);
> clk_put(ts.clock);
>
> input_unregister_device(ts.input);
> @@ -383,7 +383,7 @@ static int s3c2410ts_suspend(struct device *dev)
> {
> writel(TSC_SLEEP, ts.io + S3C2410_ADCTSC);
> disable_irq(ts.irq_tc);
> - clk_disable(ts.clock);
> + clk_disable_unprepare(ts.clock);
Do we really need to unprepare on suspend? Why simply disabling is not
enough here?
Thanks.
>
> return 0;
> }
> @@ -393,7 +393,7 @@ static int s3c2410ts_resume(struct device *dev)
> struct platform_device *pdev = to_platform_device(dev);
> struct s3c2410_ts_mach_info *info = dev_get_platdata(&pdev->dev);
>
> - clk_enable(ts.clock);
> + clk_prepare_enable(ts.clock);
> enable_irq(ts.irq_tc);
>
> /* Initialise registers */
> --
> 2.0.0
>
--
Dmitry
--
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] devicetree: Add generic IOMMU device tree bindings
On 6/30/2014 2:52 AM, Will Deacon wrote: > Hi Olav, > > On Fri, Jun 27, 2014 at 11:23:27PM +0100, Olav Haugan wrote: >> On 6/25/2014 2:18 AM, Will Deacon wrote: >>> Why can't it be dynamically detected? Whilst the StreamIDs are fixed in >>> hardware (from the SMMU architecture perspective), the SMRs are completely >>> programmable. Why doesn't something like Andreas's proposal work for you? >>> The idea there was to find the constant bits among the StreamIDs for a >>> master and create the mask accordingly. >>> >> Lets say I have an IOMMU with 2 masters and 2 SMRn slots with the >> following stream IDs coming from the masters: >> >> Master 1: 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28 >> Master 2: 0x30 >> >> To make this work I would program SMR[0] with StreamID 0x20 and mask 0xF >> to ignore lower 4 bits. SMR[1] would just be StreamID 0x30 with mask 0x0. >> >> However, I could also have an IOMMU with 2 masters and 9 SMRn slots with >> the following stream IDs: >> >> Master 1: 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28 >> Master 2: 0x29 >> >> Here I would program all SMRn and leave the mask to be 0 for all SMRn's. >> So how do I detect when to apply a mask or not? > > You would aim to use the smallest number of SMRs per master possible. > You could probably use: > > Master 1: SMR[0].id == 0x20, SMR[0].mask = 0x07 > SMR[1].id == 0x28, SMR[1].mask = 0x00 > > Master 2: SMR[2].id == 0x29, SMR[2].mask = 0x00 So how does an algorithm figure this out in both my examples? The algorithm would have to know about both (all) bus masters and their stream IDs for a specific SMMU. If the algorithm operates on the set of stream IDs for one bus master at a time the algorithm has no way of knowing which bits can be ignored since it doesn't know the value of the other stream IDs for the other bus masters and thus could potentially create a mask that could cause a stream ID to match in two different entries. >> I am not familiar with Andreas's proposal. Do you have a link? > > http://marc.info/?l=linux-arm-kernel&m=139110598005846&w=2 Unless I am mistaken the algorithm works on one bus master at a time. I don't think that will work. Thanks, Olav Haugan -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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] thermal: exynos: fix ordering in exynos_tmu_remove()
On Tue, Jul 8, 2014 at 6:39 PM, Bartlomiej Zolnierkiewicz
wrote:
> It might not be a problem currently but unregister/uninitialize things
> in the reverse order that they are registered/initialized.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
> Acked-by: Kyungmin Park
Changes look fine,
Reviewed-by: Amit Daniel Kachhap
> ---
> drivers/thermal/samsung/exynos_tmu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index d7ca9f4..6243ba0 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -759,10 +759,10 @@ static int exynos_tmu_remove(struct platform_device
> *pdev)
> {
> struct exynos_tmu_data *data = platform_get_drvdata(pdev);
>
> - exynos_tmu_control(pdev, false);
> -
> exynos_unregister_thermal(data->reg_conf);
>
> + exynos_tmu_control(pdev, false);
> +
> clk_unprepare(data->clk);
> if (!IS_ERR(data->clk_sec))
> clk_unprepare(data->clk_sec);
> --
> 1.8.2.3
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] ARM: dts: Add I2S dt node for Exynos3250
From: Tomasz Figa
This patch add I2S (Inter-IC Sound) dt node which supports 1-port stereo
(1 channels) IIS-bus for audio interface with DMA-based operation.
Signed-off-by: Tomasz Figa
Signed-off-by: Inha Song
Tested-by: Inha Song
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
Changes from v1:
- Fix wrong name of property (pinctrl-names)
- Change phanle name (i2s->i2s2)
arch/arm/boot/dts/exynos3250.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 3e678fa..77a06df 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -425,6 +425,19 @@
status = "disabled";
};
+ i2s2: i2s@1397 {
+ compatible = "samsung,s3c6410-i2s";
+ reg = <0x1397 0x100>;
+ interrupts = <0 126 0>;
+ clocks = <&cmu CLK_I2S>, <&cmu CLK_SCLK_I2S>;
+ clock-names = "iis", "i2s_opclk0";
+ dmas = <&pdma0 14>, <&pdma0 13>;
+ dma-names = "tx", "rx";
+ pinctrl-0 = <&i2s2_bus>;
+ pinctrl-names = "default";
+ status = "disabled";
+ };
+
pwm: pwm@139D {
compatible = "samsung,exynos4210-pwm";
reg = <0x139D 0x1000>;
--
1.8.0
--
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] thermal: samsung: Add TMU support for Exynos3250 SoC
On 07/01/2014 09:33 AM, Chanwoo Choi wrote:
> This patch add registers, bit fields and compatible strings for Exynos3250 TMU
> (Thermal Management Unit). Exynos3250 uses the Cortex-A7 dual cores and has
> a target speed of 1.0 GHz.
>
> Signed-off-by: Chanwoo Choi
> [Add MUX address setting bits by Jonghwa Lee]
> Signed-off-by: Jonghwa Lee
> Acked-by: Kyungmin Park
> ---
> .../devicetree/bindings/thermal/exynos-thermal.txt | 1 +
> drivers/thermal/samsung/exynos_tmu.c | 7 +-
> drivers/thermal/samsung/exynos_tmu.h | 3 +-
> drivers/thermal/samsung/exynos_tmu_data.c | 89
> ++
> drivers/thermal/samsung/exynos_tmu_data.h | 7 ++
> 5 files changed, 105 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> index c949092..ae738f5 100644
> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> @@ -3,6 +3,7 @@
> ** Required properties:
>
> - compatible : One of the following:
> +"samsung,exynos3250-tmu"
> "samsung,exynos4412-tmu"
> "samsung,exynos4210-tmu"
> "samsung,exynos5250-tmu"
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index 2412090..97ebc1e 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -501,6 +501,10 @@ static irqreturn_t exynos_tmu_irq(int irq, void *id)
>
> static const struct of_device_id exynos_tmu_match[] = {
> {
> + .compatible = "samsung,exynos3250-tmu",
> + .data = (void *)EXYNOS3250_TMU_DRV_DATA,
> + },
> + {
> .compatible = "samsung,exynos4210-tmu",
> .data = (void *)EXYNOS4210_TMU_DRV_DATA,
> },
> @@ -675,7 +679,8 @@ static int exynos_tmu_probe(struct platform_device *pdev)
> goto err_clk_sec;
> }
>
> - if (pdata->type == SOC_ARCH_EXYNOS4210 ||
> + if (pdata->type == SOC_ARCH_EXYNOS3250 ||
> + pdata->type == SOC_ARCH_EXYNOS4210 ||
> pdata->type == SOC_ARCH_EXYNOS4412 ||
> pdata->type == SOC_ARCH_EXYNOS5250 ||
> pdata->type == SOC_ARCH_EXYNOS5260 ||
> diff --git a/drivers/thermal/samsung/exynos_tmu.h
> b/drivers/thermal/samsung/exynos_tmu.h
> index edd08cf..1b4a644 100644
> --- a/drivers/thermal/samsung/exynos_tmu.h
> +++ b/drivers/thermal/samsung/exynos_tmu.h
> @@ -40,7 +40,8 @@ enum calibration_mode {
> };
>
> enum soc_type {
> - SOC_ARCH_EXYNOS4210 = 1,
> + SOC_ARCH_EXYNOS3250 = 1,
> + SOC_ARCH_EXYNOS4210,
> SOC_ARCH_EXYNOS4412,
> SOC_ARCH_EXYNOS5250,
> SOC_ARCH_EXYNOS5260,
> diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
> b/drivers/thermal/samsung/exynos_tmu_data.c
> index c1d81dc..aa8e0de 100644
> --- a/drivers/thermal/samsung/exynos_tmu_data.c
> +++ b/drivers/thermal/samsung/exynos_tmu_data.c
> @@ -90,6 +90,95 @@ struct exynos_tmu_init_data const
> exynos4210_default_tmu_data = {
> };
> #endif
>
> +#if defined(CONFIG_SOC_EXYNOS3250)
> +static const struct exynos_tmu_registers exynos3250_tmu_registers = {
> + .triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
> + .triminfo_25_shift = EXYNOS_TRIMINFO_25_SHIFT,
> + .triminfo_85_shift = EXYNOS_TRIMINFO_85_SHIFT,
> + .tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
> + .test_mux_addr_shift = EXYNOS4412_MUX_ADDR_SHIFT,
> + .buf_vref_sel_shift = EXYNOS_TMU_REF_VOLTAGE_SHIFT,
> + .buf_vref_sel_mask = EXYNOS_TMU_REF_VOLTAGE_MASK,
> + .therm_trip_mode_shift = EXYNOS_TMU_TRIP_MODE_SHIFT,
> + .therm_trip_mode_mask = EXYNOS_TMU_TRIP_MODE_MASK,
> + .therm_trip_en_shift = EXYNOS_TMU_THERM_TRIP_EN_SHIFT,
> + .buf_slope_sel_shift = EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT,
> + .buf_slope_sel_mask = EXYNOS_TMU_BUF_SLOPE_SEL_MASK,
> + .core_en_shift = EXYNOS_TMU_CORE_EN_SHIFT,
> + .tmu_status = EXYNOS_TMU_REG_STATUS,
> + .tmu_cur_temp = EXYNOS_TMU_REG_CURRENT_TEMP,
> + .threshold_th0 = EXYNOS_THD_TEMP_RISE,
> + .threshold_th1 = EXYNOS_THD_TEMP_FALL,
> + .tmu_inten = EXYNOS_TMU_REG_INTEN,
> + .inten_rise0_shift = EXYNOS_TMU_INTEN_RISE0_SHIFT,
> + .inten_rise1_shift = EXYNOS_TMU_INTEN_RISE1_SHIFT,
> + .inten_rise2_shift = EXYNOS_TMU_INTEN_RISE2_SHIFT,
> + .inten_fall0_shift = EXYNOS_TMU_INTEN_FALL0_SHIFT,
> + .tmu_intstat = EXYNOS_TMU_REG_INTSTAT,
> + .tmu_intclear = EXYNOS_TMU_REG_INTCLEAR,
> + .intclr_fall_shift = EXYNOS_TMU_CLEAR_FALL_INT_SHIFT,
> + .intclr_rise_shift = EXYNOS_TMU_RISE_INT_SHIFT,
> + .intclr_rise_mask = EXYNOS_TMU_RISE_INT_MASK,
> + .intclr_fall_mask = EXYNOS_TMU_FALL_INT_MASK,
> + .emul_con = EXYNOS_EMUL_CON,
> + .emul_temp_shift = EXYNOS_EMUL_DATA_SHIFT,
> + .emul_time_shift = EXYNOS_EMUL_TIME_SHIFT,
> + .emul_time_mask
Re: [PATCH 1/2] phy: Kconfig: Re-organize Exynos USB 2.0 PHY configs
Hi Tomasz, On Tue, Jul 8, 2014 at 9:15 PM, Tomasz Figa wrote: > On 30.06.2014 10:56, Sachin Kamat wrote: >> Since the USB 2.0 PHYs are required only with EHCI/OHCI USB drivers, > > That's not true. They are also required for USB gadget controller > supported by the DWC2 gadget driver (formerly s3c-hsotg). Otherwise the > change makes sense to me. Do you propose I amend just the patch description or also add a dependency on USB_DWC2 along with EHCI and OHCI. I do not have anything to test this. Based on your input I will re-spin the patch. -- 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
[PATCH v7 2/4] ARM: EXYNOS: Refactored code for using PMU address via DT
Under "arm/mach-exynos" many files are using PMU register offsets.
Since we have added support for accessing PMU base address via DT,
now we can remove PMU mapping from exynosX_iodesc. Let's convert
all these access using iomapped address.
This will help us in removing static mapping of PMU base address
as well as help in reducing dependency over machine header files.
Thus helping for migration of PMU implementation from machine to
driver folder which can be reused for ARM64 bsed SoC.
Also as we have removed static mappings from "regs-pmu.h" it does
not need map.h anymore. But "platsmp.c" needed this and till now it
got included indirectly. So lets move header inclusion of
"mach/map.h" from "regs-pmu.h" to "platsmp.c".
Signed-off-by: Pankaj Dubey
Reviewed-by: Tomasz Figa
---
arch/arm/mach-exynos/common.h| 14 +-
arch/arm/mach-exynos/exynos.c| 12 +-
arch/arm/mach-exynos/include/mach/map.h |3 -
arch/arm/mach-exynos/mcpm-exynos.c |8 +-
arch/arm/mach-exynos/platsmp.c |4 +-
arch/arm/mach-exynos/pm.c| 76 ++--
arch/arm/mach-exynos/pmu.c | 40 +-
arch/arm/mach-exynos/regs-pmu.h | 522 +-
arch/arm/plat-samsung/include/plat/map-s5p.h |1 -
9 files changed, 339 insertions(+), 341 deletions(-)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index f8daa9c..47b904b 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -134,7 +134,7 @@ extern void exynos_cpu_die(unsigned int cpu);
/* PMU(Power Management Unit) support */
-#define PMU_TABLE_END NULL
+#define PMU_TABLE_END (-1U)
enum sys_powerdown {
SYS_AFTR,
@@ -144,7 +144,7 @@ enum sys_powerdown {
};
struct exynos_pmu_conf {
- void __iomem *reg;
+ unsigned int offset;
unsigned int val[NUM_SYS_POWERDOWN];
};
@@ -160,4 +160,14 @@ extern void exynos_enter_aftr(void);
extern void s5p_init_cpu(void __iomem *cpuid_addr);
extern unsigned int samsung_rev(void);
+static inline void pmu_raw_writel(u32 val, u32 offset)
+{
+ __raw_writel(val, pmu_base_addr + offset);
+}
+
+static inline u32 pmu_raw_readl(u32 offset)
+{
+ return __raw_readl(pmu_base_addr + offset);
+}
+
#endif /* __ARCH_ARM_MACH_EXYNOS_COMMON_H */
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 173aac8..d75d3e8 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -61,11 +61,6 @@ static struct map_desc exynos4_iodesc[] __initdata = {
.length = SZ_4K,
.type = MT_DEVICE,
}, {
- .virtual= (unsigned long)S5P_VA_PMU,
- .pfn= __phys_to_pfn(EXYNOS4_PA_PMU),
- .length = SZ_64K,
- .type = MT_DEVICE,
- }, {
.virtual= (unsigned long)S5P_VA_COMBINER_BASE,
.pfn= __phys_to_pfn(EXYNOS4_PA_COMBINER),
.length = SZ_4K,
@@ -139,11 +134,6 @@ static struct map_desc exynos5_iodesc[] __initdata = {
.pfn= __phys_to_pfn(EXYNOS5_PA_CMU),
.length = 144 * SZ_1K,
.type = MT_DEVICE,
- }, {
- .virtual= (unsigned long)S5P_VA_PMU,
- .pfn= __phys_to_pfn(EXYNOS5_PA_PMU),
- .length = SZ_64K,
- .type = MT_DEVICE,
},
};
@@ -151,7 +141,7 @@ static void exynos_restart(enum reboot_mode mode, const
char *cmd)
{
struct device_node *np;
u32 val = 0x1;
- void __iomem *addr = EXYNOS_SWRESET;
+ void __iomem *addr = pmu_base_addr + EXYNOS_SWRESET;
if (of_machine_is_compatible("samsung,exynos5440")) {
u32 status;
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index 963002f..f0b7e92 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -27,9 +27,6 @@
#define EXYNOS4_PA_SYSCON 0x1001
#define EXYNOS5_PA_SYSCON 0x10050100
-#define EXYNOS4_PA_PMU 0x1002
-#define EXYNOS5_PA_PMU 0x1004
-
#define EXYNOS4_PA_CMU 0x1003
#define EXYNOS5_PA_CMU 0x1001
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
b/arch/arm/mach-exynos/mcpm-exynos.c
index 9315ba9..70e8ccd 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -55,7 +55,7 @@
"dsb\n\t" \
"ldmfd sp!, {fp, ip}" \
: \
- : "Ir" (S5P_INFORM0) \
+ : "Ir" (pmu_base_addr + S5P_INFORM0) \
: "r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7", \
"r9", "r10", "lr", "memory")
@@ -337,7 +337,7 @@ static int __init exynos_mcpm_i
[PATCH v7 0/4] ARM: Exynos: PMU cleanup and refactoring for using DT
This patch series, modifies Exynos Power Management Unit (PMU) related code for converting it into a platform_driver. This is also preparation for moving PMU related code out of machine folder into a either "drivers/mfd", or "drivers/power" or some other suitable place so that ARM64 based SoC can utilize common piece of code. These patches are created on top of Kukjin Kim's for-next. I have tested this patches on Exynos5250 Snow board for system boot and S2R. This patch series depends on following two patch series: [1]: mfd: syscon: Decouple syscon interface from syscon devices. https://lkml.org/lkml/2014/6/24/188 [2]: Cleanup patches for mach-exynos. http://www.spinics.net/lists/arm-kernel/msg341474.html Patch v6 and discussion can be found here: https://lkml.org/lkml/2014/7/7/22 Change since v6: - Removed NULL check for pmu_data in pmu.c. - Moved pmu_raw_readl and pmu_raw_writel inline helper function into common.h. Change Since v5: - Squashed patch "Move "mach/map.h" inclusion from regs-pmu.h to platsmp.c" into patch "Refactored code for using PMU address via DT". - Addressed review comments from Tomasz Figa. - Using init_irq machine function to initialize PMU mapping instead of init_time. - Rebased on latest Kukjin Kim's for-next branch. Changes Since v4: - Splitted patch series in two parts. Part 1 has code cleanup under mach-exynos and posted as separate patch [2]. Current patchset is part 2 which modified exynos pmu implementation for making it platform driver. - Removed dependency over early_syscon API. - Removed usage of regmap read/write APIs. - Modified probe function to register exynos pmu as syscon provider using Tomasz Figa's syscon patch [1]. - Address various other review comments from Tomasz Figa. - Removed signed-off-by of Young-Gun Jang , as this id is no more valid. Taking ownership of all his patches. Changes Since v3: - Optimized exynos_pmu_probe function by removing exynos_pmu_data_init as suggested by Vikas Sajjan. - Modified syscon_early_regmap_lookup_by_phandle and syscon_regmap_lookup_by_phandle function call to pass property as NULL. Changes Since v2: - Rebased on top of Daniel Lezcano's Exynos cpuidle refactor patches. - Removed early mapping of PMU base address from exynos.c and removed "get_exynos_pmuaddr" function. Instead of this added code in platsmp.c to get PMU base address using of_iomap as suggested by Tomasz Figa. - Converted PMU implementation into platform_driver by using static platform_device method. Changes Since v1: - Rebased on latest for-next of Kukjin Kim's tree. - Updated patch: Add support for mapping PMU base address via DT - Removed __initdata from declaration of "exynos_pmu_base", as it caused kernel crash as pointed out by Vikas Sajjan. - Added support for Syscon initialization and getting PMU regmap handle as suggested by Sylwester. Since current implementation of early intialization [1] has limitation that "early_syscon_init" requires DT to be unflattened and system should be able to allocate memory, we can't use regmap handles for platsmp.c file as "smp_secondary_init" will be called before DT unflattening. So I have kept both method for accessing PMU base address. platsmp.c will use ioremmaped address where as rest other files can use regmap handle. - Updated patch: Refactored code for PMU register mapping via DT - Modified to use regmap_read/write when using regmap handle. - Added patch: Add device tree based initialization support for PMU. - Convert existing PMU implementation to be a device tree based before moving it to "drivers/mfd" folder. As suggested by Bartlomiej. - Dropped making a platform_driver for PMU, as currently PMU binding has two compatibility strings as "samsung, exynosxxx-pmu", "syscon", once we enable MFD_SYSCON config option, current "syscon" driver probe gets called and PMU probe never gets called. So modified PMU initialization code to scan DT and match against supported compatiblity string in driver code, and once we get matching node use that for accessing PMU regmap handle using "syscon_early_regmap_lookup_by_phandle". If there is any better solution please suggest. Pankaj Dubey (4): ARM: EXYNOS: Add support for mapping PMU base address via DT ARM: EXYNOS: Refactored code for using PMU address via DT ARM: EXYNOS: Add platform driver support for Exynos PMU ARM: EXYNOS: Move PMU specific definitions from common.h arch/arm/mach-exynos/Kconfig |1 + arch/arm/mach-exynos/common.h| 28 +- arch/arm/mach-exynos/exynos-pmu.h| 24 ++ arch/arm/mach-exynos/exynos.c| 49 ++- arch/arm/mach-exynos/include/mach/map.h |3 - arch/arm/mach-exynos/mcpm-exynos.c |8 +- arch/arm/mach-exynos/pla
[PATCH v7 4/4] ARM: EXYNOS: Move PMU specific definitions from common.h
This patch moves PMU specific definitions into a new file
as exynos-pmu.h.
This will help in reducing dependency of common.h in pmu.c.
Signed-off-by: Pankaj Dubey
Reviewed-by: Tomasz Figa
---
arch/arm/mach-exynos/common.h | 17 -
arch/arm/mach-exynos/exynos-pmu.h | 24
arch/arm/mach-exynos/pm.c |1 +
arch/arm/mach-exynos/pmu.c| 20 +++-
4 files changed, 44 insertions(+), 18 deletions(-)
create mode 100644 arch/arm/mach-exynos/exynos-pmu.h
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 47b904b..9019d86 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -132,23 +132,6 @@ extern struct smp_operations exynos_smp_ops;
extern void exynos_cpu_die(unsigned int cpu);
-/* PMU(Power Management Unit) support */
-
-#define PMU_TABLE_END (-1U)
-
-enum sys_powerdown {
- SYS_AFTR,
- SYS_LPA,
- SYS_SLEEP,
- NUM_SYS_POWERDOWN,
-};
-
-struct exynos_pmu_conf {
- unsigned int offset;
- unsigned int val[NUM_SYS_POWERDOWN];
-};
-
-extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
extern void exynos_cpu_power_down(int cpu);
extern void exynos_cpu_power_up(int cpu);
extern int exynos_cpu_power_state(int cpu);
diff --git a/arch/arm/mach-exynos/exynos-pmu.h
b/arch/arm/mach-exynos/exynos-pmu.h
new file mode 100644
index 000..a2ab0d5
--- /dev/null
+++ b/arch/arm/mach-exynos/exynos-pmu.h
@@ -0,0 +1,24 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Header for EXYNOS PMU Driver support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __EXYNOS_PMU_H
+#define __EXYNOS_PMU_H
+
+enum sys_powerdown {
+ SYS_AFTR,
+ SYS_LPA,
+ SYS_SLEEP,
+ NUM_SYS_POWERDOWN,
+};
+
+extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
+
+#endif /* __EXYNOS_PMU_H */
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index bcb96be..b2efe8c 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -34,6 +34,7 @@
#include
#include "common.h"
+#include "exynos-pmu.h"
#include "regs-pmu.h"
#include "regs-sys.h"
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index 5b76728..117f333 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -15,9 +15,16 @@
#include
#include
-#include "common.h"
+#include "exynos-pmu.h"
#include "regs-pmu.h"
+#define PMU_TABLE_END (-1U)
+
+struct exynos_pmu_conf {
+ unsigned int offset;
+ unsigned int val[NUM_SYS_POWERDOWN];
+};
+
struct exynos_pmu_data {
const struct exynos_pmu_conf *pmu_config;
const struct exynos_pmu_conf *pmu_config_extra;
@@ -31,8 +38,19 @@ struct exynos_pmu_context {
const struct exynos_pmu_data *pmu_data;
};
+static void __iomem *pmu_base_addr;
static struct exynos_pmu_context *pmu_context;
+static inline void pmu_raw_writel(u32 val, u32 offset)
+{
+ __raw_writel(val, pmu_base_addr + offset);
+}
+
+static inline u32 pmu_raw_readl(u32 offset)
+{
+ return __raw_readl(pmu_base_addr + offset);
+}
+
static const struct exynos_pmu_conf exynos4210_pmu_config[] = {
/* { .offset = offset, .val = { AFTR, LPA, SLEEP } */
{ S5P_ARM_CORE0_LOWPWR, { 0x0, 0x0, 0x2 } },
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 3/4] ARM: EXYNOS: Add platform driver support for Exynos PMU
This patch modifies Exynos Power Management Unit (PMU) initialization
implementation in following way:
- Added platform driver support and probe function where Exynos PMU
driver will register itself as syscon provider with syscon framework.
- Added platform struct exynos_pmu_data to hold platform specific data.
- For each SoC's PMU support now we can add platform data and statically
bind PMU configuration and SoC specific initialization function.
- Separate each SoC's PMU initialization function and make it as part of
platform data.
- It also removes uses of soc_is_exynosXYZ().
Signed-off-by: Pankaj Dubey
Reviewed-by: Tomasz Figa
---
arch/arm/mach-exynos/Kconfig |1 +
arch/arm/mach-exynos/pmu.c | 185 +-
2 files changed, 146 insertions(+), 40 deletions(-)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 8f9b66c..a2944ac 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -24,6 +24,7 @@ menuconfig ARCH_EXYNOS
select PM_GENERIC_DOMAINS if PM_RUNTIME
select S5P_DEV_MFC
select SRAM
+ select MFD_SYSCON
help
Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5)
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index ff9d23f..5b76728 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2011-2012 Samsung Electronics Co., Ltd.
+ * Copyright (c) 2011-2014 Samsung Electronics Co., Ltd.
* http://www.samsung.com/
*
* EXYNOS - CPU PMU(Power Management Unit) support
@@ -10,12 +10,28 @@
*/
#include
-#include
+#include
+#include
+#include
+#include
#include "common.h"
#include "regs-pmu.h"
-static const struct exynos_pmu_conf *exynos_pmu_config;
+struct exynos_pmu_data {
+ const struct exynos_pmu_conf *pmu_config;
+ const struct exynos_pmu_conf *pmu_config_extra;
+
+ void (*pmu_init)(void);
+ void (*powerdown_conf)(enum sys_powerdown);
+};
+
+struct exynos_pmu_context {
+ struct device *dev;
+ const struct exynos_pmu_data *pmu_data;
+};
+
+static struct exynos_pmu_context *pmu_context;
static const struct exynos_pmu_conf exynos4210_pmu_config[] = {
/* { .offset = offset, .val = { AFTR, LPA, SLEEP } */
@@ -335,7 +351,7 @@ static unsigned int const exynos5_list_diable_wfi_wfe[] = {
EXYNOS5_ISP_ARM_OPTION,
};
-static void exynos5_init_pmu(void)
+static void exynos5_powerdown_conf(enum sys_powerdown mode)
{
unsigned int i;
unsigned int tmp;
@@ -372,51 +388,140 @@ void exynos_sys_powerdown_conf(enum sys_powerdown mode)
{
unsigned int i;
- if (soc_is_exynos5250())
- exynos5_init_pmu();
+ const struct exynos_pmu_data *pmu_data = pmu_context->pmu_data;
- for (i = 0; (exynos_pmu_config[i].offset != PMU_TABLE_END) ; i++)
- pmu_raw_writel(exynos_pmu_config[i].val[mode],
- exynos_pmu_config[i].offset);
+ if (pmu_data->powerdown_conf)
+ pmu_data->powerdown_conf(mode);
- if (soc_is_exynos4412()) {
- for (i = 0; exynos4412_pmu_config[i].offset != PMU_TABLE_END ;
i++)
- pmu_raw_writel(exynos4412_pmu_config[i].val[mode],
- exynos4412_pmu_config[i].offset);
+ if (pmu_data->pmu_config) {
+ for (i = 0; (pmu_data->pmu_config[i].offset != PMU_TABLE_END) ;
i++)
+ pmu_raw_writel(pmu_data->pmu_config[i].val[mode],
+ pmu_data->pmu_config[i].offset);
+ }
+
+ if (pmu_data->pmu_config_extra) {
+ for (i = 0; pmu_data->pmu_config_extra[i].offset !=
PMU_TABLE_END; i++)
+ pmu_raw_writel(pmu_data->pmu_config_extra[i].val[mode],
+ pmu_data->pmu_config_extra[i].offset);
}
}
-static int __init exynos_pmu_init(void)
+static void exynos5250_pmu_init(void)
{
unsigned int value;
+ /*
+* When SYS_WDTRESET is set, watchdog timer reset request
+* is ignored by power management unit.
+*/
+ value = pmu_raw_readl(EXYNOS5_AUTO_WDTRESET_DISABLE);
+ value &= ~EXYNOS5_SYS_WDTRESET;
+ pmu_raw_writel(value, EXYNOS5_AUTO_WDTRESET_DISABLE);
+
+ value = pmu_raw_readl(EXYNOS5_MASK_WDTRESET_REQUEST);
+ value &= ~EXYNOS5_SYS_WDTRESET;
+ pmu_raw_writel(value, EXYNOS5_MASK_WDTRESET_REQUEST);
+}
+
+static const struct exynos_pmu_data exynos4210_pmu_data = {
+ .pmu_config = exynos4210_pmu_config,
+};
+
+static const struct exynos_pmu_data exynos4212_pmu_data = {
+ .pmu_config = exynos4x12_pmu_config,
+};
+
+static const struct exynos_pmu_data exynos4412_pmu_data = {
+ .pmu_config = exynos4x12_pmu_config,
+ .pmu_config_extra = exynos4412_pmu_config,
+};
+
+stati
[PATCH v7 1/4] ARM: EXYNOS: Add support for mapping PMU base address via DT
Add support for mapping Samsung Power Management Unit (PMU)
base address from device tree.
Signed-off-by: Pankaj Dubey
Reviewed-by: Tomasz Figa
---
arch/arm/mach-exynos/common.h |1 +
arch/arm/mach-exynos/exynos.c | 37 +
2 files changed, 38 insertions(+)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 152b464..f8daa9c 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -113,6 +113,7 @@ IS_SAMSUNG_CPU(exynos5800, EXYNOS5800_SOC_ID,
EXYNOS5_SOC_MASK)
extern void __iomem *sysram_ns_base_addr;
extern void __iomem *sysram_base_addr;
+extern void __iomem *pmu_base_addr;
void exynos_sysram_init(void);
void exynos_firmware_init(void);
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 186f35d..173aac8 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -31,6 +32,8 @@
#include "regs-pmu.h"
#include "regs-sys.h"
+void __iomem *pmu_base_addr;
+
static struct map_desc exynos4_iodesc[] __initdata = {
{
.virtual= (unsigned long)S3C_VA_SYS,
@@ -253,6 +256,39 @@ static void __init exynos_init_io(void)
exynos_map_io();
}
+static const struct of_device_id exynos_dt_pmu_match[] = {
+ { .compatible = "samsung,exynos3250-pmu" },
+ { .compatible = "samsung,exynos4210-pmu" },
+ { .compatible = "samsung,exynos4212-pmu" },
+ { .compatible = "samsung,exynos4412-pmu" },
+ { .compatible = "samsung,exynos5250-pmu" },
+ { .compatible = "samsung,exynos5420-pmu" },
+ { /*sentinel*/ },
+};
+
+static void exynos_map_pmu(void)
+{
+ struct device_node *np;
+
+ np = of_find_matching_node(NULL, exynos_dt_pmu_match);
+ if (np)
+ pmu_base_addr = of_iomap(np, 0);
+
+ if (!pmu_base_addr)
+ panic("failed to find exynos pmu register\n");
+}
+
+static void __init exynos_init_irq(void)
+{
+ irqchip_init();
+ /*
+* Since platsmp.c needs pmu base address by the time
+* DT is not unflatten so we can't use DT APIs before
+* init_irq
+*/
+ exynos_map_pmu();
+}
+
static void __init exynos_dt_machine_init(void)
{
struct device_node *i2c_np;
@@ -336,6 +372,7 @@ DT_MACHINE_START(EXYNOS_DT, "SAMSUNG EXYNOS (Flattened
Device Tree)")
.smp= smp_ops(exynos_smp_ops),
.map_io = exynos_init_io,
.init_early = exynos_firmware_init,
+ .init_irq = exynos_init_irq,
.init_machine = exynos_dt_machine_init,
.init_late = exynos_init_late,
.dt_compat = exynos_dt_compat,
--
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 1/2] phy: Kconfig: Re-organize Exynos USB 2.0 PHY configs
On Wednesday, July 09, 2014 12:42 PM, Sachin Kamat wrote: > On Tue, Jul 8, 2014 at 9:15 PM, Tomasz Figa wrote: > > On 30.06.2014 10:56, Sachin Kamat wrote: > >> Since the USB 2.0 PHYs are required only with EHCI/OHCI USB drivers, > > > > That's not true. They are also required for USB gadget controller > > supported by the DWC2 gadget driver (formerly s3c-hsotg). Otherwise the > > change makes sense to me. > > Do you propose I amend just the patch description or also add a dependency on > USB_DWC2 along with EHCI and OHCI. I do not have anything to test this. Based > on your input I will re-spin the patch. I agree with Tomasz Figa's statement. Personally, I think that it would be good to amend the commit message and add a dependency on USB_DWC2. :-) Thank you. Best regards, Jingoo Han > > -- > 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 V4 00/10] drm: exynos: few patches to enhance bridge chip support
Hi Daniel, Thierry and Rob, Currently, the following boards are working fine with the bridge chip series: - snow - spring - peach_pit - peach_pi And, I did change my original patchset based on your comments here: (1) [RFC V2 0/3] drm/bridge: panel and chaining http://www.spinics.net/lists/linux-samsung-soc/msg30160.html (2) [RFC V3 0/3] drm/bridge: panel and chaining http://www.spinics.net/lists/linux-samsung-soc/msg30507.html If you think this is not the right way of doing it, please come forward with more suggestions, or kindly ACK it. I am just wondering how long can I keep waiting for comments? Regards, Ajay -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/7] drm/exynos: Support DP CLKCON register in FIMD driver
ping
On Mon, Jun 30, 2014 at 9:39 PM, Inki Dae wrote:
> 2014-06-30 14:31 GMT+09:00 Andrzej Hajda :
>> On 06/30/2014 03:14 AM, Jingoo Han wrote:
>>> On Friday, June 27, 2014 10:03 PM, Ajay kumar wrote:
On Fri, Jun 27, 2014 at 6:14 PM, Andrzej Hajda wrote:
> On 06/27/2014 01:48 PM, Ajay kumar wrote:
>> On Fri, Jun 27, 2014 at 4:52 PM, Andrzej Hajda
>> wrote:
>>> +CC DT
>>>
>>> On 06/27/2014 12:12 PM, Ajay Kumar wrote:
Add the missing setting for DP CLKCON register.
This register is present on Exynos5 based FIMD controllers,
and needs to be set if we are using DP.
Signed-off-by: Ajay Kumar
---
.../devicetree/bindings/video/samsung-fimd.txt |1 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 23
include/video/samsung_fimd.h |4
3 files changed, 28 insertions(+)
>>> [.]
>>>
static const struct of_device_id fimd_driver_dt_match[] = {
@@ -331,6 +341,10 @@ static void fimd_commit(struct exynos_drm_manager
*mgr)
if (clkdiv > 1)
val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
+ if (ctx->driver_data->has_dp_clkcon &&
+ ctx->exynos_fimd_output_type == EXYNOS_FIMD_OUTPUT_DP)
+ writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
+
writel(val, ctx->regs + VIDCON0);
> New code should not split VIDCON0 related code.It should be moved few
> lines above or few lines below.
Ok, for better readability.
> Anyway this code should be rather placed in power related functions of
> dp encoder, as it enables dp. The only question
> is if DP_CLKCON update can be performed after VIDCON0 update. If yes the
> solution of the whole problem
I will check this.
> seems to be simple:
> - fimd should provide function fimd_set_dp_clk_gate or sth similar,
> - this function should be called in exynos_dp_poweron/exynos_dp_poweroff.
> I hope I have not missed anything this time.
But, it won't look good to export a FIMD function which sets a FIMD
register,
and call it in DP driver!
What does Inki/Jingoo have to say about this?
>>> I agree with Ajay Kumar's opinion.
>>> It doesn't look good to export the function to set FIMD register
>>> and call it by DP driver.
>>
>> DP_CLKCON HW register shows clearly there is direct hardware dependency
>> between DP and FIMD.
>> Reflecting this dependency in drivers is just a consequence of HW design.
>
> Right, and I cannot understand why mDNIe and DP clock enable bit
> exists in FIMD ip. :(
>
>> Moreover the register gates also clock for MDNIE, this solution can be
>> used there as well.
>>
>> Anyway the most important is that we should avoid adding DT bindings for
>> things we can evaluate in drivers.
>>
>
> It wouldn't be best way only to avoid adding DT binding. DT binding
> could be good way to handle complicated hardware pipelines if needed.
> Of course, if driver can handle it simply, it would be better to avoid
> adding DT binding. However, Exynos SoC are complicated.
>
> Exynos SoC have more IPs to should be considered; SMIES, mDNIe and MIE
> as image enhancement devices, and eDP, MIPI-DSI, and DPI (FIMD
> connected to panel directly) as Display bus devices and parallel panel
> device. And image enhancement device and Display bus device can be
> used together.
>
> FIMD Panel
> FIMD Display bus device Panel
> FIMD image enhancement device Panel
> FIMD image enhancement device FIMD-Lite Panel
> FIMD image enhancement device Display bus device
> Panel
> FIMD image enhancement device FIMD-Lite
> Display bus device Panel
>
> And Display bus devices and parallel device couldn't be switched in
> runtime since kernel has been booted. However, image enhancement
> devices can be enabled or disabled in runtime so the output path of
> FIMD can be changed to another path dynamically - actually, I had
> handled such scenarios. So if Exynos drm driver should be considered
> for above all cases, it'd make Eyxnos drm driver too complicated.
>
> If DT people and other SoC maintainers give us your opinions, it would
> be helpful for us. I will look into other SoC how they are handling
> similar cases.
>
> Thanks,
> Inki Dae
>
>> Regards
>> Andrzej
>>
>>>
>>> Best regards,
>>> Jingoo Han
Regards,
Ajay
>>> []
>>>
>>>
>>
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More maj
