Re: DT on s3c24xx
Hello,
[Cc += linusw, linux-gpio]
On Wed, Dec 17, 2014 at 10:04:24PM +0300, Vasily Khoruzhick wrote:
> I'd like to port several s3c24xx to DT, and I'm stuck with s3c24xx LCD
> controller and power drivers for H1940 and RX1950.
>
> Please see [1]. I want to move this function into another LCD power
> driver, but I'm not sure what to do with s3c_gpio_cfgpin(). I need to
> change pin function in runtime, and as far as I understand it should
> be handled via pinctrl driver somehow. But how?
You can pass >1 pinctrl setups to a node:
somedevice {
pinctrl-names = "default", "foo", "bar";
pinctrl-0 = <&pinctrl_somedevice_default>;
pinctrl-1 = <&pinctrl_somedevice_foo>;
pinctrl-2 = <&pinctrl_somedevice_bar>;
cfg-gpios = <&gpio4 12 3>, <&gpio2 7 5>;
};
Then I think you can fiddle with pinctrl_select_state(). For the gpios
you can then use the standard gpiod_{request,direction_{in,out}put}
combo.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
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: [PATCHv4 1/8] devfreq: event: Add new devfreq_event class to provide basic data for devfreq governor
Dear Myungjoo,
Thanks for your review.
On 12/18/2014 03:24 PM, MyungJoo Ham wrote:
> Hi Chanwoo,
>
> I love the idea and I now have a little mechanical issues in your code.
>
>> ---
>> drivers/devfreq/Kconfig | 2 +
>> drivers/devfreq/Makefile| 5 +-
>> drivers/devfreq/devfreq-event.c | 449
>>
>> drivers/devfreq/event/Makefile | 1 +
>> include/linux/devfreq.h | 160 ++
>> 5 files changed, 616 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/devfreq/devfreq-event.c
>> create mode 100644 drivers/devfreq/event/Makefile
>>
>> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
>> index faf4e70..4d15b62 100644
>> --- a/drivers/devfreq/Kconfig
>> +++ b/drivers/devfreq/Kconfig
>> @@ -87,4 +87,6 @@ config ARM_EXYNOS5_BUS_DEVFREQ
>>It reads PPMU counters of memory controllers and adjusts the
>>operating frequencies and voltages with OPP support.
>>
>> +comment "DEVFREQ Event Drivers"
>> +
>> endif # PM_DEVFREQ
>> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
>> index 16138c9..a1ffabe 100644
>> --- a/drivers/devfreq/Makefile
>> +++ b/drivers/devfreq/Makefile
>> @@ -1,4 +1,4 @@
>> -obj-$(CONFIG_PM_DEVFREQ)+= devfreq.o
>> +obj-$(CONFIG_PM_DEVFREQ)+= devfreq.o devfreq-event.o
>> obj-$(CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND) += governor_simpleondemand.o
>> obj-$(CONFIG_DEVFREQ_GOV_PERFORMANCE) += governor_performance.o
>> obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE) += governor_powersave.o
>> @@ -7,3 +7,6 @@ obj-$(CONFIG_DEVFREQ_GOV_USERSPACE) += governor_userspace.o
>> # DEVFREQ Drivers
>> obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ) += exynos/
>> obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ) += exynos/
>> +
>> +# DEVFREQ Event Drivers
>> +obj-$(CONFIG_PM_DEVFREQ)+= event/
>>
>
> It looks getting mature fast.
> However, I would like to suggest you to
>
> allow not to compile devfreq-event.c and not include its compiled object
> if devfreq.c is required but devfreq-event.c is not required.
> (e.g., add CONFIG_PM_DEVFREQ_EVENT and let it be enabled when needed)
> just a little concern for lightweight devices.
> (this change might require a bit more work on the header as well)
> - Or do you think devfreq-event.c will become almost mandatory for
>most devfreq drivers?
I agree your opinion.
I'll add CONFIG_PM_DEVFREQ_EVENT according to your comment.
>
>
> [snip]
>
>> diff --git a/drivers/devfreq/devfreq-event.c
>> b/drivers/devfreq/devfreq-event.c
>> new file mode 100644
>> index 000..0e1948e
>> --- /dev/null
>> +++ b/drivers/devfreq/devfreq-event.c
>> @@ -0,0 +1,449 @@
>> +/*
>> + * devfreq-event: Generic DEVFREQ Event class driver
>
> DEVFREQ is a generic DVFS mechanism (or subsystem).
>
> Plus, I thought devfreq-event is considered to be a "framework"
> for devfreq event class drivers. Am I mistaken?
You're right. just "class driver" description is not proper.
I'll modify the description of devfreq-event.c as following:
or If you have other opinion, would you please let me know about it?
devfreq-event: DEVFREQ-Event Framework to provide raw data of Non-CPU
Devices.
> [snip]
>
>> +struct devfreq_event_dev *devfreq_event_add_edev(struct device *dev,
>> + struct devfreq_event_desc
>> *desc)
>> +{
>> + struct devfreq_event_dev *edev;
>> + static atomic_t event_no = ATOMIC_INIT(0);
>> + int ret;
>> +
>> + if (!dev || !desc)
>> + return ERR_PTR(-EINVAL);
>> +
>> + if (!desc->name || !desc->ops)
>> + return ERR_PTR(-EINVAL);
>> +
>> + if (!desc->ops->set_event || !desc->ops->get_event)
>> + return ERR_PTR(-EINVAL);
>> +
>> + edev = devm_kzalloc(dev, sizeof(*edev), GFP_KERNEL);
>> + if (!edev)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + mutex_lock(&devfreq_event_list_lock);
>
> You seem to lock that global lock too long. That lock is only required
> while you operate the list. The data to be protected by this mutex is
> devfreq_event_list. Until the new entry is added to the list, the new
> entry is free from protection. (may be delayed right before list_add)
OK. I'll move global lock right before calling list_add() on below.
>
>> + mutex_init(&edev->lock);
>> + edev->desc = desc;
>> + edev->dev.parent = dev;
>> + edev->dev.class = devfreq_event_class;
>> + edev->dev.release = devfreq_event_release_edev;
>> +
>> + dev_set_name(&edev->dev, "event.%d", atomic_inc_return(&event_no) -
>> 1);
>> + ret = device_register(&edev->dev);
>> + if (ret < 0) {
>> + put_device(&edev->dev);
>> + mutex_unlock(&devfreq_event_list_lock);
>> + return ERR_PTR(ret);
>> + }
>> + dev_set_drvdata(&edev->dev, edev);
>> +
>> + INIT_LIST_HEAD(&edev->node);
>> + list_add
Re: [PATCH] clk: samsung: Fix Exynos 5420 pinctrl setup and clock disable failure due to domain being gated
Quoting Mike Turquette (2014-12-17 07:23:22) > Quoting Krzysztof Kozlowski (2014-12-16 00:20:15) > > On pon, 2014-12-15 at 14:26 -0800, Kevin Hilman wrote: > > > Kevin Hilman writes: > > > > > > > Sylwester Nawrocki writes: > > > > > > > >> On 09/12/14 13:59, Krzysztof Kozlowski wrote: > > > >>> On pią, 2014-12-05 at 15:15 +0100, Krzysztof Kozlowski wrote: > > > > Audio subsystem clocks are located in separate block. On Exynos > > > > 5420 if > > > > clock for this block (from main clock domain) 'mau_epll' is gated > > > > then > > > > any read or write to audss registers will block. > > > > > > > > This kind of boot hang was observed on Arndale Octa and Peach > > > > Pi/Pit > > > > after introducing runtime PM to pl330 DMA driver. After that > > > > commit the > > > > 'mau_epll' was gated, because the "amba" clock was disabled and > > > > there > > > > were no more users of mau_epll. > > > > > > > > The system hang on one of steps: > > > > 1. Disabling unused clocks from audss block. > > > > 2. During audss GPIO setup (just before probing i2s0 because > > > >samsung_pinmux_setup() tried to access memory from audss block > > > > which was > > > >gated. > > > > > > > > Add a workaround for this by enabling the 'mau_epll' clock in > > > > probe. > > > > > > > > Signed-off-by: Krzysztof Kozlowski > > > > --- > > > > drivers/clk/samsung/clk-exynos-audss.c | 29 > > > > - > > > > 1 file changed, 28 insertions(+), 1 deletion(-) > > > >>> > > > >>> Sorry for pinging so quick but merge window is open and it looks like > > > >>> booting Exynos542x boards will be broken (because pl330 will no longer > > > >>> hold adma clock enabled so whole audss domain will be gated). > > > >>> > > > >>> This is a non-intrusive workaround for that issue, as wanted by > > > >>> Sylwester: > > > >>> https://lkml.org/lkml/2014/12/5/223 > > > >>> > > > >>> Any comments on this? > > > >> > > > >> The patch looks OK to me, it would be good though if someone else > > > >> has confirmed it fixes the bug. I don't have any clock patches queued > > > >> at the moment. Perhaps you could apply it directly, Mike ? > > > > > > > > I confirm it fixes the boot hang in linux-next (next-20141210) on my > > > > exynos5800-peach-pi and exynos5420-arndale-octa. Tested both > > > > exynos_defconfig and multi_v7_defconfig. > > > > > > > > Tested-by: Kevin Hilman > > > > > > What's the status of this patch? linux-next is still broken for several > > > Exynos5 platforms without this fix. > > > > I believe not only next is broken but also current mainline because > > runtime PM for pl330 was merged yesterday... > > > > The patch received two tested-bys (Kevin's and Javier's) and Sylwester's > > ack. > > > > Mike, could you pick the patch and send it to Linus after rc1? > > Will do. To be clear, I pulled this into clk-next towards -rc1, so it won't need to go through as an -rc fix. Regards, Mike > > Regards, > Mike > > > > > Best regards, > > Krzysztof > > -- 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: [PATCHv4 1/8] devfreq: event: Add new devfreq_event class to provide basic data for devfreq governor
Hi Chanwoo,
I love the idea and I now have a little mechanical issues in your code.
> ---
> drivers/devfreq/Kconfig | 2 +
> drivers/devfreq/Makefile| 5 +-
> drivers/devfreq/devfreq-event.c | 449
>
> drivers/devfreq/event/Makefile | 1 +
> include/linux/devfreq.h | 160 ++
> 5 files changed, 616 insertions(+), 1 deletion(-)
> create mode 100644 drivers/devfreq/devfreq-event.c
> create mode 100644 drivers/devfreq/event/Makefile
>
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index faf4e70..4d15b62 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -87,4 +87,6 @@ config ARM_EXYNOS5_BUS_DEVFREQ
> It reads PPMU counters of memory controllers and adjusts the
> operating frequencies and voltages with OPP support.
>
> +comment "DEVFREQ Event Drivers"
> +
> endif # PM_DEVFREQ
> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
> index 16138c9..a1ffabe 100644
> --- a/drivers/devfreq/Makefile
> +++ b/drivers/devfreq/Makefile
> @@ -1,4 +1,4 @@
> -obj-$(CONFIG_PM_DEVFREQ) += devfreq.o
> +obj-$(CONFIG_PM_DEVFREQ) += devfreq.o devfreq-event.o
> obj-$(CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND)+= governor_simpleondemand.o
> obj-$(CONFIG_DEVFREQ_GOV_PERFORMANCE)+= governor_performance.o
> obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE) += governor_powersave.o
> @@ -7,3 +7,6 @@ obj-$(CONFIG_DEVFREQ_GOV_USERSPACE) += governor_userspace.o
> # DEVFREQ Drivers
> obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ)+= exynos/
> obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ)+= exynos/
> +
> +# DEVFREQ Event Drivers
> +obj-$(CONFIG_PM_DEVFREQ) += event/
>
It looks getting mature fast.
However, I would like to suggest you to
allow not to compile devfreq-event.c and not include its compiled object
if devfreq.c is required but devfreq-event.c is not required.
(e.g., add CONFIG_PM_DEVFREQ_EVENT and let it be enabled when needed)
just a little concern for lightweight devices.
(this change might require a bit more work on the header as well)
- Or do you think devfreq-event.c will become almost mandatory for
most devfreq drivers?
[snip]
> diff --git a/drivers/devfreq/devfreq-event.c b/drivers/devfreq/devfreq-event.c
> new file mode 100644
> index 000..0e1948e
> --- /dev/null
> +++ b/drivers/devfreq/devfreq-event.c
> @@ -0,0 +1,449 @@
> +/*
> + * devfreq-event: Generic DEVFREQ Event class driver
DEVFREQ is a generic DVFS mechanism (or subsystem).
Plus, I thought devfreq-event is considered to be a "framework"
for devfreq event class drivers. Am I mistaken?
[snip]
> +struct devfreq_event_dev *devfreq_event_add_edev(struct device *dev,
> + struct devfreq_event_desc
> *desc)
> +{
> + struct devfreq_event_dev *edev;
> + static atomic_t event_no = ATOMIC_INIT(0);
> + int ret;
> +
> + if (!dev || !desc)
> + return ERR_PTR(-EINVAL);
> +
> + if (!desc->name || !desc->ops)
> + return ERR_PTR(-EINVAL);
> +
> + if (!desc->ops->set_event || !desc->ops->get_event)
> + return ERR_PTR(-EINVAL);
> +
> + edev = devm_kzalloc(dev, sizeof(*edev), GFP_KERNEL);
> + if (!edev)
> + return ERR_PTR(-ENOMEM);
> +
> + mutex_lock(&devfreq_event_list_lock);
You seem to lock that global lock too long. That lock is only required
while you operate the list. The data to be protected by this mutex is
devfreq_event_list. Until the new entry is added to the list, the new
entry is free from protection. (may be delayed right before list_add)
> + mutex_init(&edev->lock);
> + edev->desc = desc;
> + edev->dev.parent = dev;
> + edev->dev.class = devfreq_event_class;
> + edev->dev.release = devfreq_event_release_edev;
> +
> + dev_set_name(&edev->dev, "event.%d", atomic_inc_return(&event_no) -
> 1);
> + ret = device_register(&edev->dev);
> + if (ret < 0) {
> + put_device(&edev->dev);
> + mutex_unlock(&devfreq_event_list_lock);
> + return ERR_PTR(ret);
> + }
> + dev_set_drvdata(&edev->dev, edev);
> +
> + INIT_LIST_HEAD(&edev->node);
> + list_add(&edev->node, &devfreq_event_list);
> + mutex_unlock(&devfreq_event_list_lock);
> +
> + return edev;
> +}
[snip / reversed maybe.. sorry]
> +/**
> + * devfreq_event_is_enabled() - Check whether devfreq-event dev is enabled or
> + * not.
> + * @edev : the devfreq-event device
> + *
> + * Note that this function check whether devfreq-event dev is enabled or not.
> + * If return true, the devfreq-event dev is enabeld. If return false, the
> + * devfreq-event dev is disabled.
> + */
> +bool devfreq_event_is_enabled(struct devfreq_event_dev *edev)
> +{
> + bool enabled = false;
> +
> + if (!edev || !
Re: [PATCH v7 1/3] Input: add regulator haptic driver
On Thursday, December 18, 2014 10:17:42 AM Jaewon Kim wrote: > Hi Dmity, > > 2014년 12월 18일 07:06에 Dmitry Torokhov 이(가) 쓴 글: > > HI Jaewon, > > > > On Wed, Dec 17, 2014 at 12:35:06PM +0900, Jaewon Kim wrote: > >> This patch adds support for haptic driver controlled by > >> voltage of regulator. And this driver support for > >> Force Feedback interface from input framework > >> > >> Signed-off-by: Jaewon Kim > >> Signed-off-by: Hyunhee Kim > >> Acked-by: Kyungmin Park > >> Tested-by: Chanwoo Choi > >> Reviewed-by: Chanwoo Choi > >> Reviewed-by: Pankaj Dubey > > > > Does the driver still work if you apply the patch below on top of yours? > > > > Thanks. > > Yes, there is no problem to apply this one first. Thank you. Then I'll fold it into yours and queue the driver for the next release. Thanks. -- 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 v7 1/3] Input: add regulator haptic driver
Hi Dmity, 2014년 12월 18일 07:06에 Dmitry Torokhov 이(가) 쓴 글: HI Jaewon, On Wed, Dec 17, 2014 at 12:35:06PM +0900, Jaewon Kim wrote: This patch adds support for haptic driver controlled by voltage of regulator. And this driver support for Force Feedback interface from input framework Signed-off-by: Jaewon Kim Signed-off-by: Hyunhee Kim Acked-by: Kyungmin Park Tested-by: Chanwoo Choi Reviewed-by: Chanwoo Choi Reviewed-by: Pankaj Dubey Does the driver still work if you apply the patch below on top of yours? Thanks. Yes, there is no problem to apply this one first. Thanks to review my patches. Thanks Jaewon Kim -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v3 1/2] PM / Domains: Extend API pm_genpd_dev_need_restore to use restore types
On Wednesday, December 17, 2014 10:25:09 AM Kevin Hilman wrote: > amit daniel kachhap writes: > > > On Wed, Dec 17, 2014 at 3:40 AM, Kevin Hilman wrote: > >> Marek Szyprowski writes: > >> > >>> Hello, > >>> > >>> On 2014-12-13 17:51, Amit Daniel Kachhap wrote: > Instead of using bool to restore suspended devices initially, use flags > like GPD_DEV_SUSPEND_INIT, GPD_DEV_RESTORE_INIT and > GPD_DEV_RESTORE_FORCE. > The first two flags will be similar to the existing true/false > functionality. > The third flag may be used to force restore of suspended devices > whenever their associated power domain is turned on. > > Currently, PD power off function powers off all the associated unused > devices. The functionality added in this patch is similar to it. > > This feature may be used for those devices which are always in ON state > if the PD associated with them is ON but may need local runtime resume > and suspend during PD On/Off. These devices (like clock) may not > implement > complete pm_runtime calls such as pm_runtime_get/pm_runtime_put due to > subsystems interaction behaviour or any other reason. > > The model works like, > DEV1 (Attaches itself with PD but no calls to pm_runtime_get and > / pm_runtime_put. Its local runtime_suspend/resume is invoked > via > /GPD_DEV_RESTORE_FORCE option) > / > PD -- DEV2 (Implements complete PM runtime and calls pm_runtime_get and > \ pm_runtime_put. This in turn invokes PD On/Off) > \ > DEV3 (Similar to DEV1) > > Signed-off-by: Amit Daniel Kachhap > >>> > >>> The idea of adding new gen_pd flag and reusing runtime pm calls intead > >>> of additional notifiers looks promising, but I have some doubts. > >> > >> I agree, this is better than notifiers, but I have some doubts too. > > > > Thanks, > > > >> > >>> don't see any guarantee that devices with GPD_DEV_RESTORE_FORCE flag > >>> will be suspended after all "normal" devices and restored before > >>> them. Without such assumption it will be hard to use this approach for > >>> iommu related activities, because device might need to use (in its > >>> suspend/resume callbacks) the functionality provided by the other > >>> device with GPD_DEV_RESTORE_FORCE flag. Maybe some additional flags > >>> like suspend/resume priority (or more flags) will solve somehow this > >>> dependency. > >> > >> At a deeper level, the problem with this approach is that this is more > >> generically a runtime PM dependency problem, not a genpd problem. For > >> example, what happens when the same kind of dependency exists on a > >> platform using a custom PM domain instead of genpd (like ACPI.) ? > > > > This patch does not try to solve runtime PM dependencies between > > devices. As an example, if there are three devices D1, D2, D3 in a > > power domain. Device D3 would update the power domain state > > requirement using runtime PM API but devices D1 and D2 do not want to > > control the domain but just want to be notified when the power domain > > state changes. > > Yes, I understand that. > > The question is: what do you do when you have the same dependency > problem and you're not using genpd (for example, some SoCs have > implmeented their own PM domains, and ACPI devices are managed by their > own PM domain, not genpd.) > > >> What's needed to solve this problem is a generalized way to have runtime > >> PM dependencies between devices. Runtime PM already automatically > >> handles parent devices as one type of dependent device (e.g. a parent > >> device needs to be runtime PM resumed before its child.) So what's > >> needed is a generic way to other PM dependencies with the runtime PM > >> core (not the genpd core.) > > > > Considering the example above with three devices, device D1 and D2 are > > passive components in this power domain. These devices only need to > > know the state changes of the power domains but would not control the > > power domain themselves nor put forth constraints in the power domain > > state changes. So I did not clearly understand as to how this example > > could be solved by introducing changes in runtime PM core. > > Your solution only solves the problems for devices managed by genpd. > > If I understood your example correctly, what you really want to solve > this problem more generically is to be able to tell the runtime PM core > that D3 has a dependency on D1 and D2. Then, whenver the runtime PM > core is doing get/put operations for D3, it needs to also do them for D1 > and D2. > > This will accomplish the same as your proposed approach, but work for > any devices in any PM domains. Plus, it is not limited to runtime PM, really. It affects system suspend too. -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "uns
Re: Enable runtime PM automatically?
On Wednesday, December 17, 2014 08:33:13 PM Geert Uytterhoeven wrote:
> On Tue, Dec 16, 2014 at 11:10 PM, Kevin Hilman wrote:
> > At a deeper level, the problem with this approach is that this is more
> > generically a runtime PM dependency problem, not a genpd problem. For
> > example, what happens when the same kind of dependency exists on a
> > platform using a custom PM domain instead of genpd (like ACPI.) ?
> >
> > What's needed to solve this problem is a generalized way to have runtime
> > PM dependencies between devices. Runtime PM already automatically
> > handles parent devices as one type of dependent device (e.g. a parent
> > device needs to be runtime PM resumed before its child.) So what's
> > needed is a generic way to other PM dependencies with the runtime PM
> > core (not the genpd core.)
> >
> > If runtime PM handles the dependencies corretcly, then genpd (and any
> > other PM domain) will get them "for free".
>
> Having the proper dependencies is not sufficient. Currently drivers have to do
> something to use runtime PM.
>
> By default, runtime PM is disabled for a device
> ("device.power.disable_depth = 1").
Which isn't the case for PCI devices.
> However, if PM domains are active, drivers must be runtime PM-aware for the
> gpd_dev_ops.start() method to be called in the first place (perhaps this is
> just
> one bug that's easy to fix --- the device is "assumed suspended", but can be
> used). They must
> 1. call pm_runtime_enable() to enable runtime PM for the device,
> 2. call pm_runtime_get_sync() to prevent the device from being put in a
> low-power state at any time. This second call has the
> "side-effect" of calling
> gpd_dev_ops.start().
>
> Hence, if PM domains are enabled, wouldn't it make sense to
> 1. enable runtime PM by default, for all devices (bound and unbound),
I guess you mean for devices with and without drivers here?
> 2. call pm_runtime_get_sync(), for all devices bound to a driver.
> Of course we have to keep track if drivers call any of the pm_runtime_*()
> methods theirselves, as that would have to move them from automatic to
> manual mode.
>
> Would this be feasible?
PCI does something similar and IMO it would make sense to do that for all
devices, at least where we have a known way to power them up/down without a
driver.
There's a couple of questions, though. First, how many drivers would break
if we enabled runtime PM by default? Second, if we do that, how do we
figure out the initial value of runtime PM status in general? Finally,
what about drivers that need to work with and without PM domains (for example,
some systems they run on have PM domains, while some other don't)?
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH v3 18/19] iommu: exynos: init from dt-specific callback instead of initcall
Hi Arnd, On Wednesday 17 December 2014 22:58:47 Arnd Bergmann wrote: > On Wednesday 17 December 2014 18:02:51 Laurent Pinchart wrote: > > On Wednesday 17 December 2014 16:41:33 Arnd Bergmann wrote: > >> On Wednesday 17 December 2014 16:39:02 Laurent Pinchart wrote: > >>> On Wednesday 17 December 2014 15:27:36 Arnd Bergmann wrote: > On Wednesday 17 December 2014 01:24:42 Laurent Pinchart wrote: > > If we forbid the IOMMU driver from being compiled as a module > > can't we just rely on deferred probing ? The bus master driver > > will just be reprobed after the IOMMU gets probed, like for other > > devices. > > > > This could fail in case the IOMMU device permanently fails to > > probe. There would be something very wrong in the system in that > > case, Enabling the bus masters totally transparently without IOMMU > > support could not be such a good idea. > > I believe in the majority of cases today, the IOMMU is entirely > optional. There are valid reasons for not including the IOMMU driver > in the kernel, e.g. when you know that all the machines with that > driver can DMA to all of their RAM and you want to avoid the > overhead of IOTLB misses. > >>> > >>> Should that really be controlled by compiling the IOMMU driver out, > >>> wouldn't it be better to disable the IOMMU devices in DT in that case > >>> ? > >> > >> It's a policy decision that should only depend on the user. Modifying > >> the DT is wrong here IMHO because the device is still connected to the > >> IOMMU in hardware and we should correctly represent that. > > > > I was thinking about setting status = "disabled" on the IOMMU nodes, not > > removing the IOMMU references in the bus master nodes. > > But that still requires a modification of the DT. The hardware is the > same, so I don't see why we should update the dtb based on kernel > configuration. It wouldn't be the first time we encode configuration information in DT, but I agree it's not an optimal solution. Setting iommu=off on the kernel command line is better, and should be easy to implement. -- Regards, Laurent Pinchart -- 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 1/3] Input: add regulator haptic driver
HI Jaewon,
On Wed, Dec 17, 2014 at 12:35:06PM +0900, Jaewon Kim wrote:
> This patch adds support for haptic driver controlled by
> voltage of regulator. And this driver support for
> Force Feedback interface from input framework
>
> Signed-off-by: Jaewon Kim
> Signed-off-by: Hyunhee Kim
> Acked-by: Kyungmin Park
> Tested-by: Chanwoo Choi
> Reviewed-by: Chanwoo Choi
> Reviewed-by: Pankaj Dubey
Does the driver still work if you apply the patch below on top of yours?
Thanks.
--
Dmitry
Input: regulator-haptics - misc changes
From: Dmitry Torokhov
Signed-off-by: Dmitry Torokhov
---
drivers/input/misc/Kconfig|4 -
drivers/input/misc/regulator-haptic.c | 164 -
2 files changed, 100 insertions(+), 68 deletions(-)
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index e5e556d..0b652c5 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -395,11 +395,11 @@ config INPUT_CM109
called cm109.
config INPUT_REGULATOR_HAPTIC
- tristate "regulator haptics support"
+ tristate "Regulator haptics support"
select INPUT_FF_MEMLESS
help
This option enables device driver support for the haptic controlled
- by regulator. This driver supports ff-memless interface
+ by a regulator. This driver supports ff-memless interface
from input framework.
To compile this driver as a module, choose M here: the
diff --git a/drivers/input/misc/regulator-haptic.c
b/drivers/input/misc/regulator-haptic.c
index 16f5ec8..9426221 100644
--- a/drivers/input/misc/regulator-haptic.c
+++ b/drivers/input/misc/regulator-haptic.c
@@ -28,55 +28,78 @@ struct regulator_haptic {
struct work_struct work;
struct mutex mutex;
- bool enabled;
- bool suspend_state;
+ bool active;
+ bool suspended;
+
unsigned int max_volt;
unsigned int min_volt;
- unsigned int intensity;
unsigned int magnitude;
};
-static void regulator_haptic_enable(struct regulator_haptic *haptic, bool
state)
+static int regulator_haptic_toggle(struct regulator_haptic *haptic, bool on)
{
int error;
- if (haptic->enabled == state)
- return;
+ if (haptic->active != on) {
+
+ error = on ? regulator_enable(haptic->regulator) :
+regulator_disable(haptic->regulator);
+ if (error) {
+ dev_err(haptic->dev,
+ "failed to switch regulator %s: %d\n",
+ on ? "on" : "off", error);
+ return error;
+ }
+
+ haptic->active = on;
+ }
- error = state ? regulator_enable(haptic->regulator) :
- regulator_disable(haptic->regulator);
+ return 0;
+}
+
+static int regulator_haptic_set_voltage(struct regulator_haptic *haptic,
+unsigned int magnitude)
+{
+ u64 volt_mag_multi;
+ unsigned int intensity;
+ int error;
+
+ volt_mag_multi = (u64)(haptic->max_volt - haptic->min_volt) * magnitude;
+ intensity = (unsigned int)(volt_mag_multi >> MAX_MAGNITUDE_SHIFT);
+
+ error = regulator_set_voltage(haptic->regulator,
+ intensity + haptic->min_volt,
+ haptic->max_volt);
if (error) {
- dev_err(haptic->dev, "cannot enable regulator\n");
- return;
+ dev_err(haptic->dev, "cannot set regulator voltage to %d: %d\n",
+ intensity + haptic->min_volt, error);
+ return error;
}
- haptic->enabled = state;
+ return 0;
}
static void regulator_haptic_work(struct work_struct *work)
{
struct regulator_haptic *haptic = container_of(work,
struct regulator_haptic, work);
+ unsigned int magnitude;
int error;
mutex_lock(&haptic->mutex);
- if (haptic->suspend_state)
- goto err;
+ if (haptic->suspended)
+ goto out;
- error = regulator_set_voltage(haptic->regulator,
- haptic->intensity + haptic->min_volt, haptic->max_volt);
- if (error) {
- dev_err(haptic->dev, "cannot set regulator voltage\n");
- goto err;
- }
+ magnitude = ACCESS_ONCE(haptic->magnitude);
- if (haptic->magnitude)
- regulator_haptic_enable(haptic, true);
- else
- regulator_haptic_enable(haptic, false);
+ error = regulator_haptic_set_voltage(haptic, magnitude);
+ if (error)
+ goto out;
-err:
+ regulator_haptic_toggle(haptic, magnitude != 0);
+
+out:
mutex_unlock(&haptic->mutex);
}
@@ -84,18 +107,11 @@ static int regulator_haptic_play_effect(st
Re: [Linaro-mm-sig] [PATCH v3 18/19] iommu: exynos: init from dt-specific callback instead of initcall
On Wednesday 17 December 2014 18:02:51 Laurent Pinchart wrote: > On Wednesday 17 December 2014 16:41:33 Arnd Bergmann wrote: > > On Wednesday 17 December 2014 16:39:02 Laurent Pinchart wrote: > > > On Wednesday 17 December 2014 15:27:36 Arnd Bergmann wrote: > > > > On Wednesday 17 December 2014 01:24:42 Laurent Pinchart wrote: > > > > > If we forbid the IOMMU driver from being compiled as a module can't we > > > > > just rely on deferred probing ? The bus master driver will just be > > > > > reprobed after the IOMMU gets probed, like for other devices. > > > > > > > > > > This could fail in case the IOMMU device permanently fails to probe. > > > > > There > > > > > would be something very wrong in the system in that case, Enabling the > > > > > bus > > > > > masters totally transparently without IOMMU support could not be such > > > > > a > > > > > good idea. > > > > > > > > I believe in the majority of cases today, the IOMMU is entirely > > > > optional. > > > > There are valid reasons for not including the IOMMU driver in the > > > > kernel, > > > > e.g. when you know that all the machines with that driver can DMA to > > > > all of their RAM and you want to avoid the overhead of IOTLB misses. > > > > > > Should that really be controlled by compiling the IOMMU driver out, > > > wouldn't it be better to disable the IOMMU devices in DT in that case ? > > > > It's a policy decision that should only depend on the user. Modifying the > > DT is wrong here IMHO because the device is still connected to the IOMMU > > in hardware and we should correctly represent that. > > I was thinking about setting status = "disabled" on the IOMMU nodes, not > removing the IOMMU references in the bus master nodes. But that still requires a modification of the DT. The hardware is the same, so I don't see why we should update the dtb based on kernel configuration. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Enable runtime PM automatically?
On Tue, Dec 16, 2014 at 11:10 PM, Kevin Hilman wrote:
> At a deeper level, the problem with this approach is that this is more
> generically a runtime PM dependency problem, not a genpd problem. For
> example, what happens when the same kind of dependency exists on a
> platform using a custom PM domain instead of genpd (like ACPI.) ?
>
> What's needed to solve this problem is a generalized way to have runtime
> PM dependencies between devices. Runtime PM already automatically
> handles parent devices as one type of dependent device (e.g. a parent
> device needs to be runtime PM resumed before its child.) So what's
> needed is a generic way to other PM dependencies with the runtime PM
> core (not the genpd core.)
>
> If runtime PM handles the dependencies corretcly, then genpd (and any
> other PM domain) will get them "for free".
Having the proper dependencies is not sufficient. Currently drivers have to do
something to use runtime PM.
By default, runtime PM is disabled for a device
("device.power.disable_depth = 1").
However, if PM domains are active, drivers must be runtime PM-aware for the
gpd_dev_ops.start() method to be called in the first place (perhaps this is just
one bug that's easy to fix --- the device is "assumed suspended", but can be
used). They must
1. call pm_runtime_enable() to enable runtime PM for the device,
2. call pm_runtime_get_sync() to prevent the device from being put in a
low-power state at any time. This second call has the
"side-effect" of calling
gpd_dev_ops.start().
Hence, if PM domains are enabled, wouldn't it make sense to
1. enable runtime PM by default, for all devices (bound and unbound),
2. call pm_runtime_get_sync(), for all devices bound to a driver.
Of course we have to keep track if drivers call any of the pm_runtime_*()
methods theirselves, as that would have to move them from automatic to
manual mode.
Would this be feasible?
This would avoid the need to add minimal runtime PM support to each and every
driver, because:
- its device resides in a PM domain, cfr. e.g. commit df0c6c80232f2ad4
("gpio: rcar: Add minimal runtime PM support"),
- its device is a child of a device in a PM domain, cfr. e.g. commit
3a611e26e958b037 ("net/smsc911x: Add minimal runtime PM support").
There's a similar issue for "transparent" buses that don't need a kernel driver
(compatible = "simple-bus"). If they're in a PM domain, runtime PM must be
enabled for them, so their bus devices are resumed when a child device on the
bus is resumed by runtime PM. Having runtime PM enabled by default
would avoid the need to add a minimal driver for the bus which just
enables runtime PM, cfr. [PATCH v2 0/8] Add Simple Power-Managed Bus Support
(https://lkml.org/lkml/2014/12/17/359).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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
DT on s3c24xx
Hi, I'd like to port several s3c24xx to DT, and I'm stuck with s3c24xx LCD controller and power drivers for H1940 and RX1950. Please see [1]. I want to move this function into another LCD power driver, but I'm not sure what to do with s3c_gpio_cfgpin(). I need to change pin function in runtime, and as far as I understand it should be handled via pinctrl driver somehow. But how? Also please see [2] and [3]. s3c2410fb driver modifies gpio registers (and pinmux, they're same block on s3c24xx) directly. What would be best way to get rid of that? Regards Vasily [1] https://github.com/anarsoul/linux-2.6/blob/v3.18-anarsoul-wip/arch/arm/mach-s3c24xx/mach-h1940.c#L599 [2] https://github.com/anarsoul/linux-2.6/blob/v3.18-anarsoul-wip/arch/arm/mach-s3c24xx/mach-h1940.c#L221 [3] https://github.com/anarsoul/linux-2.6/blob/v3.18-anarsoul-wip/drivers/video/fbdev/s3c2410fb.c#L709 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v3 1/2] PM / Domains: Extend API pm_genpd_dev_need_restore to use restore types
amit daniel kachhap writes: > On Wed, Dec 17, 2014 at 3:40 AM, Kevin Hilman wrote: >> Marek Szyprowski writes: >> >>> Hello, >>> >>> On 2014-12-13 17:51, Amit Daniel Kachhap wrote: Instead of using bool to restore suspended devices initially, use flags like GPD_DEV_SUSPEND_INIT, GPD_DEV_RESTORE_INIT and GPD_DEV_RESTORE_FORCE. The first two flags will be similar to the existing true/false functionality. The third flag may be used to force restore of suspended devices whenever their associated power domain is turned on. Currently, PD power off function powers off all the associated unused devices. The functionality added in this patch is similar to it. This feature may be used for those devices which are always in ON state if the PD associated with them is ON but may need local runtime resume and suspend during PD On/Off. These devices (like clock) may not implement complete pm_runtime calls such as pm_runtime_get/pm_runtime_put due to subsystems interaction behaviour or any other reason. The model works like, DEV1 (Attaches itself with PD but no calls to pm_runtime_get and / pm_runtime_put. Its local runtime_suspend/resume is invoked via /GPD_DEV_RESTORE_FORCE option) / PD -- DEV2 (Implements complete PM runtime and calls pm_runtime_get and \ pm_runtime_put. This in turn invokes PD On/Off) \ DEV3 (Similar to DEV1) Signed-off-by: Amit Daniel Kachhap >>> >>> The idea of adding new gen_pd flag and reusing runtime pm calls intead >>> of additional notifiers looks promising, but I have some doubts. >> >> I agree, this is better than notifiers, but I have some doubts too. > > Thanks, > >> >>> don't see any guarantee that devices with GPD_DEV_RESTORE_FORCE flag >>> will be suspended after all "normal" devices and restored before >>> them. Without such assumption it will be hard to use this approach for >>> iommu related activities, because device might need to use (in its >>> suspend/resume callbacks) the functionality provided by the other >>> device with GPD_DEV_RESTORE_FORCE flag. Maybe some additional flags >>> like suspend/resume priority (or more flags) will solve somehow this >>> dependency. >> >> At a deeper level, the problem with this approach is that this is more >> generically a runtime PM dependency problem, not a genpd problem. For >> example, what happens when the same kind of dependency exists on a >> platform using a custom PM domain instead of genpd (like ACPI.) ? > > This patch does not try to solve runtime PM dependencies between > devices. As an example, if there are three devices D1, D2, D3 in a > power domain. Device D3 would update the power domain state > requirement using runtime PM API but devices D1 and D2 do not want to > control the domain but just want to be notified when the power domain > state changes. Yes, I understand that. The question is: what do you do when you have the same dependency problem and you're not using genpd (for example, some SoCs have implmeented their own PM domains, and ACPI devices are managed by their own PM domain, not genpd.) >> What's needed to solve this problem is a generalized way to have runtime >> PM dependencies between devices. Runtime PM already automatically >> handles parent devices as one type of dependent device (e.g. a parent >> device needs to be runtime PM resumed before its child.) So what's >> needed is a generic way to other PM dependencies with the runtime PM >> core (not the genpd core.) > > Considering the example above with three devices, device D1 and D2 are > passive components in this power domain. These devices only need to > know the state changes of the power domains but would not control the > power domain themselves nor put forth constraints in the power domain > state changes. So I did not clearly understand as to how this example > could be solved by introducing changes in runtime PM core. Your solution only solves the problems for devices managed by genpd. If I understood your example correctly, what you really want to solve this problem more generically is to be able to tell the runtime PM core that D3 has a dependency on D1 and D2. Then, whenver the runtime PM core is doing get/put operations for D3, it needs to also do them for D1 and D2. This will accomplish the same as your proposed approach, but work for any devices in any PM domains. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH/RFC 12/14] ASoC: samsung: i2s: Add clock provider for the I2S internal clocks
On 12/12/14 21:03, Mark Brown wrote:
> On Thu, Dec 11, 2014 at 06:45:50PM +0100, Sylwester Nawrocki wrote:
>
>> +Optional Properties:
>>
>> - samsung,idma-addr: Internal DMA register base address of the audio
>>sub system(used in secondary sound source).
>> - pinctrl-0: Should specify pin control groups used for this controller.
>> - pinctrl-names: Should contain only one value - "default".
>> +- #clock-cells: should be 1, this property must be present if the I2S device
>> + is a clock provider in terms of the common clock bindings, described in
>> + ../clock/clock-bindings.txt.
>> +- clock-output-names: from the common clock bindings, names of the CDCLK
>> + I2S output clocks, suggested values are "i2s_cdclk0", "i2s_cdclk1",
>> + "i2s_cdclk3" for the I2S0, I2S1, I2S2 devices recpectively.
>> +
>
> Why not make this mandatory going forwards? You can add a note saying
> that older DTs may not have it.
I guess that makes more sense, I'll move it to the mandatory properties
section.
>> +The assignment of indices for the I2Sx clock provider is as follows:
>> + 0 - the CDCLK (CODECLKO) gate clock,
>> + 1 - the RCLK prescaler divider clock (corresponding to the IISPSR
>> register),
>> + 2 - the RCLKSRC mux clock (corresponding to RCLKSRC bit in register
>> IISMOD).
>
> Why use the indicies here, they only seem to add obscurity?
I didn't want to create a separate header file, with all the GPL copyright
notice header etc, for just this enumeration.
Anyway I'll put these as macro definitions into include/dt-bindings/sound
/samsung-i2s.h.
>> +clk_put(rclksrc);
>> +}
>> +/*
>
> Missing blank line.
>
>> + * Register the mux and div clocks only if both source clocks
>> + * are available, i.e. for the I2S0 instance and versions with
>> + * QUIRK_NO_MUXPSR quirk not set.
>> + */
>
> Why not proceed even if one is missing? This repeats in words the if
> statement but doesn't explain why we're doing this.
Right, I should have said here that this is really to distinguish between
I2S0 and I2S1, I2S2. So we register the mux and div clocks only for
the IIS Multi Audio Interface (I2S0) and not for the IIS Bus Interface
(I2S1, I2S2) instances.
However, it seems I got confused by same compatible string set for
I2S0..I2S2 in arch/arm/boot/dts/exynos4.dtsi - "samsung,s5pv210-i2s",
where for I2S1, I2S2 it should be "samsung,s3c6410-i2s". So we have,
for example, QUIRK_NO_MUXPSR set for them. There seems to be no similar
bug in arch/arm/boot/dts/exynos5250.dtsi.
I'll drop that mux input clock test the and fix the compatible strings
for exynos4 in dts.
>> +ret = of_clk_add_provider(dev->of_node, of_clk_src_onecell_get,
>> + &i2s->clk_data);
>> +if (ret < 0) {
>> +dev_err(dev, "failed to add clock provider\n");
>
> Best practice is to print the error code.
Yeah, I'll add it.
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: SAMSUNG: remove dead #elif CONFIG_S3C24XX_DMAC
Am Mittwoch, 17. Dezember 2014, 16:52:40 schrieb Arnd Bergmann:
> On Wednesday 17 December 2014 16:40:37 Stefan Hengelein wrote:
> > The corresponding CPP-block can never be selected since there are
> > conflicting Kconfig constraints:
> > - CONFIG_S3C24XX_DMAC has a dependency on ARCH_S3C24XX
> > - The surrounding CPP-block needs CONFIG_S3C64XX_DEV_SPI0 to be defined.
> >
> > - CONFIG_S3C64XX_DEV_SPI0 is only selected by MACH_WLF_CRAGG_6410
> > - MACH_WLF_CRAGG_6410 however has a dependency on ARCH_S3C64XX
> >
> > (through a surrounding if-statement in Kconfig)
> >
> > - ARCH_S3C64XX and ARCH_S3C24XX are mutually exclusive since they are
> >
> > declared in the same choice and cannot be enabled at the same time.
> >
> > Hence, the innner block
> >
> > "#elif defined(CONFIG_S3C24XX_DMAC)"
> >
> > cannot be enabled at the same time with the surrounding block
> >
> > "#ifdef CONFIG_S3C64XX_DEV_SPI0"
> >
> > and therefore is dead.
> >
> > This (logical) defect has been found with the undertaker tool
> > (https://undertaker.cs.fau.de)
>
> Nice catch!
>
> > Signed-off-by: Stefan Hengelein
> > ---
> >
> > arch/arm/plat-samsung/devs.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
> > index 83c7d15..b38b601 100644
> > --- a/arch/arm/plat-samsung/devs.c
> > +++ b/arch/arm/plat-samsung/devs.c
> > @@ -1134,8 +1134,6 @@ void __init s3c64xx_spi0_set_platdata(int
> > (*cfg_gpio)(void), int src_clk_nr,>
> > pd.filter = pl330_filter;
> >
> > #elif defined(CONFIG_S3C64XX_PL080)
> >
> > pd.filter = pl08x_filter_id;
> >
> > -#elif defined(CONFIG_S3C24XX_DMAC)
> > - pd.filter = s3c24xx_dma_filter;
> >
> > #endif
> >
> > s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi0);
>
> This was introduced in 7f99ef2284b46f ("ARM: SAMSUNG: set
> s3c24xx_dma_filter for s3c64xx-spi0 device"), but never used on s3c24xx as
> far as I can tell. Heiko, can you comment on the patch? Did this
> simply get obsoleted by the DT conversion of s3c2416 and s3c2443?
We just have no in-tree users currently.
The S3C2416 and S3C2450 use the same type of spi controllers as the s3c64xx.
When writing the s3c24xx dma driver I also used this to test the driver. The
change was necessary to make the driver talk to my s3c2416 device, so it made
sense at the time.
As the s3c24xx-dma driver currently is still lacking dt support [burried
somewhere on my todo list], board files are also currently the only way to do
fast spi on those at all.
So removing this is dependent on how hard we want to make it for downstream
users [there seem to be a small number of those]. If this were part of
removing all non-dt cruft from the driver after s3c64xx migrated to be dt-only
I wouldn't object, but as it only affects the 2 lines of s3c24xx support,
personally I'd like to keep it around :-) .
Heiko
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH v3 18/19] iommu: exynos: init from dt-specific callback instead of initcall
Hi Arnd, On Wednesday 17 December 2014 16:41:33 Arnd Bergmann wrote: > On Wednesday 17 December 2014 16:39:02 Laurent Pinchart wrote: > > On Wednesday 17 December 2014 15:27:36 Arnd Bergmann wrote: > > > On Wednesday 17 December 2014 01:24:42 Laurent Pinchart wrote: > > > > If we forbid the IOMMU driver from being compiled as a module can't we > > > > just rely on deferred probing ? The bus master driver will just be > > > > reprobed after the IOMMU gets probed, like for other devices. > > > > > > > > This could fail in case the IOMMU device permanently fails to probe. > > > > There > > > > would be something very wrong in the system in that case, Enabling the > > > > bus > > > > masters totally transparently without IOMMU support could not be such > > > > a > > > > good idea. > > > > > > I believe in the majority of cases today, the IOMMU is entirely > > > optional. > > > There are valid reasons for not including the IOMMU driver in the > > > kernel, > > > e.g. when you know that all the machines with that driver can DMA to > > > all of their RAM and you want to avoid the overhead of IOTLB misses. > > > > Should that really be controlled by compiling the IOMMU driver out, > > wouldn't it be better to disable the IOMMU devices in DT in that case ? > > It's a policy decision that should only depend on the user. Modifying the > DT is wrong here IMHO because the device is still connected to the IOMMU > in hardware and we should correctly represent that. I was thinking about setting status = "disabled" on the IOMMU nodes, not removing the IOMMU references in the bus master nodes. > You can normally set 'iommu=off' or 'iommu=force' on the command line > to force it on or off rather than letting the IOMMU driver decide whether > the device turns it on. Not enabling the IOMMU at all should really just > behave the same way as 'iommu=off', anything else would be very confusing. Setting iommu=off sounds fine to me. The IOMMU core would then return a "no IOMMU present" error instead of -EPROBE_DEFER, and probing of the bus masters would continue without IOMMU support. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH v3 18/19] iommu: exynos: init from dt-specific callback instead of initcall
On Wednesday 17 December 2014 15:53:25 Lucas Stach wrote: > Am Mittwoch, den 17.12.2014, 15:27 +0100 schrieb Arnd Bergmann: > > On Wednesday 17 December 2014 01:24:42 Laurent Pinchart wrote: > > > > > > If we forbid the IOMMU driver from being compiled as a module can't we > > > just > > > rely on deferred probing ? The bus master driver will just be reprobed > > > after > > > the IOMMU gets probed, like for other devices. > > > > > > This could fail in case the IOMMU device permanently fails to probe. > > > There > > > would be something very wrong in the system in that case, Enabling the > > > bus > > > masters totally transparently without IOMMU support could not be such a > > > good > > > idea. > > > > I believe in the majority of cases today, the IOMMU is entirely optional. > > There are valid reasons for not including the IOMMU driver in the kernel, > > e.g. when you know that all the machines with that driver can DMA to > > all of their RAM and you want to avoid the overhead of IOTLB misses. > > > This is similar to the problems we discussed with the componentized > device framework and in the end everybody agreed on a simple rule: > if the device node is enabled in the DT there must be a driver bound to > it before other devices depending on this node can be probed. > > If we apply the same logic to the IOMMU situation we get two > possibilities to allow bypassing the IOMMU: > 1. completely disable the IOMMU node in the DT > 2. leave node enabled in DT, but add a bypass property > > Obviously the second option still requires to have the IOMMU driver > available, but is more flexible. Right now everything depends on the > IOMMU being in passthrough mode at reset with no driver bound. If a > device comes around where this isn't the case thing will break with the > current assumptions or the first option. > > Having the IOMMU node enabled in DT with no driver available to the > kernel seems like an invalid configuration which should be expected to > break. Exactly the same thing as with componentized devices... One differences here is that for the IOMMU, we should generally be able to fall back to swiotlb (currently only on ARM64, not ARM32, until someone adds support). I can see your point regarding machines that have a mandatory IOMMU with no fallback when there is no driver, but we can support them by making the iommu driver selected through Kconfig for that platform, while still allowing other platforms to work with drivers left out of the kernel. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: SAMSUNG: remove dead #elif CONFIG_S3C24XX_DMAC
On Wednesday 17 December 2014 16:40:37 Stefan Hengelein wrote:
> The corresponding CPP-block can never be selected since there are
> conflicting Kconfig constraints:
> - CONFIG_S3C24XX_DMAC has a dependency on ARCH_S3C24XX
> - The surrounding CPP-block needs CONFIG_S3C64XX_DEV_SPI0 to be defined.
> - CONFIG_S3C64XX_DEV_SPI0 is only selected by MACH_WLF_CRAGG_6410
> - MACH_WLF_CRAGG_6410 however has a dependency on ARCH_S3C64XX
> (through a surrounding if-statement in Kconfig)
> - ARCH_S3C64XX and ARCH_S3C24XX are mutually exclusive since they are
> declared in the same choice and cannot be enabled at the same time.
>
> Hence, the innner block
> "#elif defined(CONFIG_S3C24XX_DMAC)"
> cannot be enabled at the same time with the surrounding block
> "#ifdef CONFIG_S3C64XX_DEV_SPI0"
> and therefore is dead.
>
> This (logical) defect has been found with the undertaker tool
> (https://undertaker.cs.fau.de)
Nice catch!
> Signed-off-by: Stefan Hengelein
> ---
> arch/arm/plat-samsung/devs.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
> index 83c7d15..b38b601 100644
> --- a/arch/arm/plat-samsung/devs.c
> +++ b/arch/arm/plat-samsung/devs.c
> @@ -1134,8 +1134,6 @@ void __init s3c64xx_spi0_set_platdata(int
> (*cfg_gpio)(void), int src_clk_nr,
> pd.filter = pl330_filter;
> #elif defined(CONFIG_S3C64XX_PL080)
> pd.filter = pl08x_filter_id;
> -#elif defined(CONFIG_S3C24XX_DMAC)
> - pd.filter = s3c24xx_dma_filter;
> #endif
>
> s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi0);
>
This was introduced in 7f99ef2284b46f ("ARM: SAMSUNG: set
s3c24xx_dma_filter for s3c64xx-spi0 device"), but never used on s3c24xx as
far as I can tell. Heiko, can you comment on the patch? Did this
simply get obsoleted by the DT conversion of s3c2416 and s3c2443?
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: SAMSUNG: remove dead #elif CONFIG_S3C24XX_DMAC
The corresponding CPP-block can never be selected since there are conflicting Kconfig constraints: - CONFIG_S3C24XX_DMAC has a dependency on ARCH_S3C24XX - The surrounding CPP-block needs CONFIG_S3C64XX_DEV_SPI0 to be defined. - CONFIG_S3C64XX_DEV_SPI0 is only selected by MACH_WLF_CRAGG_6410 - MACH_WLF_CRAGG_6410 however has a dependency on ARCH_S3C64XX (through a surrounding if-statement in Kconfig) - ARCH_S3C64XX and ARCH_S3C24XX are mutually exclusive since they are declared in the same choice and cannot be enabled at the same time. Hence, the innner block "#elif defined(CONFIG_S3C24XX_DMAC)" cannot be enabled at the same time with the surrounding block "#ifdef CONFIG_S3C64XX_DEV_SPI0" and therefore is dead. This (logical) defect has been found with the undertaker tool (https://undertaker.cs.fau.de) Signed-off-by: Stefan Hengelein --- arch/arm/plat-samsung/devs.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c index 83c7d15..b38b601 100644 --- a/arch/arm/plat-samsung/devs.c +++ b/arch/arm/plat-samsung/devs.c @@ -1134,8 +1134,6 @@ void __init s3c64xx_spi0_set_platdata(int (*cfg_gpio)(void), int src_clk_nr, pd.filter = pl330_filter; #elif defined(CONFIG_S3C64XX_PL080) pd.filter = pl08x_filter_id; -#elif defined(CONFIG_S3C24XX_DMAC) - pd.filter = s3c24xx_dma_filter; #endif s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi0); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH v3 18/19] iommu: exynos: init from dt-specific callback instead of initcall
On Wednesday 17 December 2014 16:39:02 Laurent Pinchart wrote: > > On Wednesday 17 December 2014 15:27:36 Arnd Bergmann wrote: > > On Wednesday 17 December 2014 01:24:42 Laurent Pinchart wrote: > > > If we forbid the IOMMU driver from being compiled as a module can't we > > > just rely on deferred probing ? The bus master driver will just be > > > reprobed after the IOMMU gets probed, like for other devices. > > > > > > This could fail in case the IOMMU device permanently fails to probe. There > > > would be something very wrong in the system in that case, Enabling the bus > > > masters totally transparently without IOMMU support could not be such a > > > good idea. > > > > I believe in the majority of cases today, the IOMMU is entirely optional. > > There are valid reasons for not including the IOMMU driver in the kernel, > > e.g. when you know that all the machines with that driver can DMA to > > all of their RAM and you want to avoid the overhead of IOTLB misses. > > Should that really be controlled by compiling the IOMMU driver out, wouldn't > it be better to disable the IOMMU devices in DT in that case ? It's a policy decision that should only depend on the user. Modifying the DT is wrong here IMHO because the device is still connected to the IOMMU in hardware and we should correctly represent that. You can normally set 'iommu=off' or 'iommu=force' on the command line to force it on or off rather than letting the IOMMU driver decide whether the device turns it on. Not enabling the IOMMU at all should really just behave the same way as 'iommu=off', anything else would be very confusing. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk: samsung: Fix Exynos 5420 pinctrl setup and clock disable failure due to domain being gated
Quoting Krzysztof Kozlowski (2014-12-16 00:20:15) > On pon, 2014-12-15 at 14:26 -0800, Kevin Hilman wrote: > > Kevin Hilman writes: > > > > > Sylwester Nawrocki writes: > > > > > >> On 09/12/14 13:59, Krzysztof Kozlowski wrote: > > >>> On pią, 2014-12-05 at 15:15 +0100, Krzysztof Kozlowski wrote: > > > Audio subsystem clocks are located in separate block. On Exynos 5420 > > > if > > > clock for this block (from main clock domain) 'mau_epll' is gated > > > then > > > any read or write to audss registers will block. > > > > > > This kind of boot hang was observed on Arndale Octa and Peach Pi/Pit > > > after introducing runtime PM to pl330 DMA driver. After that commit > > > the > > > 'mau_epll' was gated, because the "amba" clock was disabled and there > > > were no more users of mau_epll. > > > > > > The system hang on one of steps: > > > 1. Disabling unused clocks from audss block. > > > 2. During audss GPIO setup (just before probing i2s0 because > > >samsung_pinmux_setup() tried to access memory from audss block > > > which was > > >gated. > > > > > > Add a workaround for this by enabling the 'mau_epll' clock in probe. > > > > > > Signed-off-by: Krzysztof Kozlowski > > > --- > > > drivers/clk/samsung/clk-exynos-audss.c | 29 > > > - > > > 1 file changed, 28 insertions(+), 1 deletion(-) > > >>> > > >>> Sorry for pinging so quick but merge window is open and it looks like > > >>> booting Exynos542x boards will be broken (because pl330 will no longer > > >>> hold adma clock enabled so whole audss domain will be gated). > > >>> > > >>> This is a non-intrusive workaround for that issue, as wanted by > > >>> Sylwester: > > >>> https://lkml.org/lkml/2014/12/5/223 > > >>> > > >>> Any comments on this? > > >> > > >> The patch looks OK to me, it would be good though if someone else > > >> has confirmed it fixes the bug. I don't have any clock patches queued > > >> at the moment. Perhaps you could apply it directly, Mike ? > > > > > > I confirm it fixes the boot hang in linux-next (next-20141210) on my > > > exynos5800-peach-pi and exynos5420-arndale-octa. Tested both > > > exynos_defconfig and multi_v7_defconfig. > > > > > > Tested-by: Kevin Hilman > > > > What's the status of this patch? linux-next is still broken for several > > Exynos5 platforms without this fix. > > I believe not only next is broken but also current mainline because > runtime PM for pl330 was merged yesterday... > > The patch received two tested-bys (Kevin's and Javier's) and Sylwester's > ack. > > Mike, could you pick the patch and send it to Linus after rc1? Will do. Regards, Mike > > Best regards, > Krzysztof > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 11/14] ASoC: samsung: odroidx2: Handle I2S CDCLK clock conditionally
On 12/12/14 19:53, Mark Brown wrote: > On Thu, Dec 11, 2014 at 06:45:49PM +0100, Sylwester Nawrocki wrote: >> > If the codec control it's master clock provider by the I2S module >> > we should not be touching it with set_sysclk() calls. >> > So skip the set_sysclk() call in the machine driver if "clocks" >> > property is found in the codec device node. > > Please clarify in the changelog here that this is a transition measure > to support old DTs, it's not clear why we might want to do things for > the I2S controller by fishing around in the CODEC DT otherwise. Indeed, there is some room for improvement. I'll add such note to the commit description. Presumably this whole driver could be removed after a kernel release or two, since we switched Odroid X2/U3 to the simple-card. -- Regards, Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 04/14] ASoC: samsung: i2s: Request memory region in driver probe()
On 12/12/14 19:49, Mark Brown wrote: > On Thu, Dec 11, 2014 at 06:45:42PM +0100, Sylwester Nawrocki wrote: >> > The memory mapped registers region is common for both DAIs so request >> > it in the I2S platform device driver's probe for the platform device >> > corresponding to the primary DAI, rather than in the ASoC DAI's probe >> > callback. While at it switch to devm_ioremap_resource(). This also >> > drops the hard coded (0x100) register region size in the driver. > > This doesn't apply against current code, please check and resend. It seems I've used your topic/samsung branch as a base. Let me rebase to the for-next branch and resend. -- Regards, Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v3 1/2] PM / Domains: Extend API pm_genpd_dev_need_restore to use restore types
On Wed, Dec 17, 2014 at 6:38 PM, Marek Szyprowski wrote: > Hello, > > > On 2014-12-17 03:43, amit daniel kachhap wrote: >> >> On Tue, Dec 16, 2014 at 4:40 PM, Marek Szyprowski >> wrote: >>> >>> Hello, >>> >>> On 2014-12-13 17:51, Amit Daniel Kachhap wrote: Instead of using bool to restore suspended devices initially, use flags like GPD_DEV_SUSPEND_INIT, GPD_DEV_RESTORE_INIT and GPD_DEV_RESTORE_FORCE. The first two flags will be similar to the existing true/false functionality. The third flag may be used to force restore of suspended devices whenever their associated power domain is turned on. Currently, PD power off function powers off all the associated unused devices. The functionality added in this patch is similar to it. This feature may be used for those devices which are always in ON state if the PD associated with them is ON but may need local runtime resume and suspend during PD On/Off. These devices (like clock) may not implement complete pm_runtime calls such as pm_runtime_get/pm_runtime_put due to subsystems interaction behaviour or any other reason. The model works like, DEV1 (Attaches itself with PD but no calls to pm_runtime_get and / pm_runtime_put. Its local runtime_suspend/resume is invoked via / GPD_DEV_RESTORE_FORCE option) / PD -- DEV2 (Implements complete PM runtime and calls pm_runtime_get and \pm_runtime_put. This in turn invokes PD On/Off) \ DEV3 (Similar to DEV1) Signed-off-by: Amit Daniel Kachhap >>> >>> >>> The idea of adding new gen_pd flag and reusing runtime pm calls intead of >>> additional >>> notifiers looks promising, but I have some doubts. I don't see any >>> guarantee >>> that >>> devices with GPD_DEV_RESTORE_FORCE flag will be suspended after all >>> "normal" >>> devices >>> and restored before them. Without such assumption it will be hard to use >>> this approach >>> for iommu related activities, because device might need to use (in its >>> suspend/resume >>> callbacks) the functionality provided by the other device with >>> GPD_DEV_RESTORE_FORCE >>> flag. Maybe some additional flags like suspend/resume priority (or more >>> flags) will >>> solve somehow this dependency. >> >> Thanks for pointing this issue out. I agree that there is no priority >> in suspending devices with this flag. But this works well in syncing >> with power domain on/off as the devices of these types have only >> dependency with power domain. BTW I tested this implementation with >> your first version of IOMMU save/restore patches. Although i have not >> posted those but they work fine. I can post those after cleaning them >> up. > > > Right, they will work, but mainly because right now master devices don't > do any memory DMA operations in suspend/resume callbacks. However, to > propose > it as a generic solution, the priority and the order of operations should be > somehow determined. Hi, I feel this behavior is analogous to system sleep where the devices suspend/resume are called based on initialization types like early init, pre core, post core , late init etc. These types handle the priority and interdependency among devices. So, In my opinion we can use the same for power domain also. if these types are not sufficient enough than it may be considered for future work. Regards, Amit Daniel > >> Here, the ordering between various devices is taken care as they are >> probed at different point of time(clock then IOMMU). so the suspend >> happens in reverse probe order and resume happens in probe order. I >> will check more on this and get back. > > > Right now, it probably used the order of probing. Because iommu controllers > are probed earlier, so they are handled before the master devices. > > > Best regards > -- > Marek Szyprowski, PhD > Samsung R&D Institute Poland > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH v3 18/19] iommu: exynos: init from dt-specific callback instead of initcall
Am Mittwoch, den 17.12.2014, 15:27 +0100 schrieb Arnd Bergmann: > On Wednesday 17 December 2014 01:24:42 Laurent Pinchart wrote: > > > > If we forbid the IOMMU driver from being compiled as a module can't we just > > rely on deferred probing ? The bus master driver will just be reprobed > > after > > the IOMMU gets probed, like for other devices. > > > > This could fail in case the IOMMU device permanently fails to probe. There > > would be something very wrong in the system in that case, Enabling the bus > > masters totally transparently without IOMMU support could not be such a > > good > > idea. > > I believe in the majority of cases today, the IOMMU is entirely optional. > There are valid reasons for not including the IOMMU driver in the kernel, > e.g. when you know that all the machines with that driver can DMA to > all of their RAM and you want to avoid the overhead of IOTLB misses. > This is similar to the problems we discussed with the componentized device framework and in the end everybody agreed on a simple rule: if the device node is enabled in the DT there must be a driver bound to it before other devices depending on this node can be probed. If we apply the same logic to the IOMMU situation we get two possibilities to allow bypassing the IOMMU: 1. completely disable the IOMMU node in the DT 2. leave node enabled in DT, but add a bypass property Obviously the second option still requires to have the IOMMU driver available, but is more flexible. Right now everything depends on the IOMMU being in passthrough mode at reset with no driver bound. If a device comes around where this isn't the case thing will break with the current assumptions or the first option. Having the IOMMU node enabled in DT with no driver available to the kernel seems like an invalid configuration which should be expected to break. Exactly the same thing as with componentized devices... Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH v3 18/19] iommu: exynos: init from dt-specific callback instead of initcall
Hi Arnd, On Wednesday 17 December 2014 15:27:36 Arnd Bergmann wrote: > On Wednesday 17 December 2014 01:24:42 Laurent Pinchart wrote: > > If we forbid the IOMMU driver from being compiled as a module can't we > > just rely on deferred probing ? The bus master driver will just be > > reprobed after the IOMMU gets probed, like for other devices. > > > > This could fail in case the IOMMU device permanently fails to probe. There > > would be something very wrong in the system in that case, Enabling the bus > > masters totally transparently without IOMMU support could not be such a > > good idea. > > I believe in the majority of cases today, the IOMMU is entirely optional. > There are valid reasons for not including the IOMMU driver in the kernel, > e.g. when you know that all the machines with that driver can DMA to > all of their RAM and you want to avoid the overhead of IOTLB misses. Should that really be controlled by compiling the IOMMU driver out, wouldn't it be better to disable the IOMMU devices in DT in that case ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v3 1/2] PM / Domains: Extend API pm_genpd_dev_need_restore to use restore types
On Wed, Dec 17, 2014 at 3:40 AM, Kevin Hilman wrote: > Marek Szyprowski writes: > >> Hello, >> >> On 2014-12-13 17:51, Amit Daniel Kachhap wrote: >>> Instead of using bool to restore suspended devices initially, use flags >>> like GPD_DEV_SUSPEND_INIT, GPD_DEV_RESTORE_INIT and GPD_DEV_RESTORE_FORCE. >>> The first two flags will be similar to the existing true/false >>> functionality. >>> The third flag may be used to force restore of suspended devices >>> whenever their associated power domain is turned on. >>> >>> Currently, PD power off function powers off all the associated unused >>> devices. The functionality added in this patch is similar to it. >>> >>> This feature may be used for those devices which are always in ON state >>> if the PD associated with them is ON but may need local runtime resume >>> and suspend during PD On/Off. These devices (like clock) may not implement >>> complete pm_runtime calls such as pm_runtime_get/pm_runtime_put due to >>> subsystems interaction behaviour or any other reason. >>> >>> The model works like, >>> DEV1 (Attaches itself with PD but no calls to pm_runtime_get and >>> / pm_runtime_put. Its local runtime_suspend/resume is invoked via >>> /GPD_DEV_RESTORE_FORCE option) >>>/ >>> PD -- DEV2 (Implements complete PM runtime and calls pm_runtime_get and >>>\ pm_runtime_put. This in turn invokes PD On/Off) >>> \ >>> DEV3 (Similar to DEV1) >>> >>> Signed-off-by: Amit Daniel Kachhap >> >> The idea of adding new gen_pd flag and reusing runtime pm calls intead >> of additional notifiers looks promising, but I have some doubts. > > I agree, this is better than notifiers, but I have some doubts too. Thanks, > >> don't see any guarantee that devices with GPD_DEV_RESTORE_FORCE flag >> will be suspended after all "normal" devices and restored before >> them. Without such assumption it will be hard to use this approach for >> iommu related activities, because device might need to use (in its >> suspend/resume callbacks) the functionality provided by the other >> device with GPD_DEV_RESTORE_FORCE flag. Maybe some additional flags >> like suspend/resume priority (or more flags) will solve somehow this >> dependency. > > At a deeper level, the problem with this approach is that this is more > generically a runtime PM dependency problem, not a genpd problem. For > example, what happens when the same kind of dependency exists on a > platform using a custom PM domain instead of genpd (like ACPI.) ? This patch does not try to solve runtime PM dependencies between devices. As an example, if there are three devices D1, D2, D3 in a power domain. Device D3 would update the power domain state requirement using runtime PM API but devices D1 and D2 do not want to control the domain but just want to be notified when the power domain state changes. > > What's needed to solve this problem is a generalized way to have runtime > PM dependencies between devices. Runtime PM already automatically > handles parent devices as one type of dependent device (e.g. a parent > device needs to be runtime PM resumed before its child.) So what's > needed is a generic way to other PM dependencies with the runtime PM > core (not the genpd core.) Considering the example above with three devices, device D1 and D2 are passive components in this power domain. These devices only need to know the state changes of the power domains but would not control the power domain themselves nor put forth constraints in the power domain state changes. So I did not clearly understand as to how this example could be solved by introducing changes in runtime PM core. Regards, Amit Daniel > > If runtime PM handles the dependencies corretcly, then genpd (and any > other PM domain) will get them "for free". > > Kevin > -- > To unsubscribe from this list: send the line "unsubscribe linux-pm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH v3 18/19] iommu: exynos: init from dt-specific callback instead of initcall
On Wednesday 17 December 2014 01:24:42 Laurent Pinchart wrote: > > If we forbid the IOMMU driver from being compiled as a module can't we just > rely on deferred probing ? The bus master driver will just be reprobed after > the IOMMU gets probed, like for other devices. > > This could fail in case the IOMMU device permanently fails to probe. There > would be something very wrong in the system in that case, Enabling the bus > masters totally transparently without IOMMU support could not be such a good > idea. I believe in the majority of cases today, the IOMMU is entirely optional. There are valid reasons for not including the IOMMU driver in the kernel, e.g. when you know that all the machines with that driver can DMA to all of their RAM and you want to avoid the overhead of IOTLB misses. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] s5p-jpeg: Adding Exynos7 Jpeg variant support
Hi Tony,
Thanks for the patches.
Please process them with scripts/checkpatch.pl as you will be submitting
the next version - they contain many coding style related issues.
My remaining comments below.
On 12/17/2014 08:27 AM, Tony K Nadackal wrote:
Fimp_jpeg used in Exynos7 is a revised version. Some register
configurations are slightly different from Jpeg in Exynos4.
Added one more variant SJPEG_EXYNOS7 to handle these differences.
Signed-off-by: Tony K Nadackal
---
This patch is created and tested on top of linux-next-20141210.
It can be cleanly applied on media-next and kgene/for-next.
.../bindings/media/exynos-jpeg-codec.txt | 2 +-
drivers/media/platform/s5p-jpeg/jpeg-core.c| 69 +++---
drivers/media/platform/s5p-jpeg/jpeg-core.h| 1 +
drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c | 33 ++-
drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.h | 8 ++-
drivers/media/platform/s5p-jpeg/jpeg-regs.h| 17 --
6 files changed, 98 insertions(+), 32 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
index bf52ed4..cd19417 100644
--- a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
+++ b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
@@ -4,7 +4,7 @@ Required properties:
- compatible : should be one of:
"samsung,s5pv210-jpeg", "samsung,exynos4210-jpeg",
- "samsung,exynos3250-jpeg";
+ "samsung,exynos3250-jpeg", "samsung,exynos7-jpeg";
- reg : address and length of the JPEG codec IP register set;
- interrupts : specifies the JPEG codec IP interrupt;
- clock-names : should contain:
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 54fa5d9..ad42a4e 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -1225,8 +1225,9 @@ static int s5p_jpeg_try_fmt_vid_cap(struct file *file,
void *priv,
return -EINVAL;
}
- if ((ctx->jpeg->variant->version != SJPEG_EXYNOS4) ||
- (ctx->mode != S5P_JPEG_DECODE))
+ if (((ctx->jpeg->variant->version != SJPEG_EXYNOS4) &&
+ (ctx->jpeg->variant->version != SJPEG_EXYNOS7)) ||
+ (ctx->mode != S5P_JPEG_DECODE))
goto exit;
/*
@@ -1349,7 +1350,8 @@ static int s5p_jpeg_s_fmt(struct s5p_jpeg_ctx *ct, struct
v4l2_format *f)
* the JPEG_IMAGE_SIZE register. In order to avoid sysmmu
* page fault calculate proper buffer size in such a case.
*/
- if (ct->jpeg->variant->version == SJPEG_EXYNOS4 &&
+ if (((ct->jpeg->variant->version == SJPEG_EXYNOS4) ||
+ (ct->jpeg->variant->version == SJPEG_EXYNOS7)) &&
f_type == FMT_TYPE_OUTPUT && ct->mode == S5P_JPEG_ENCODE)
q_data->size = exynos4_jpeg_get_output_buffer_size(ct,
f,
@@ -1901,7 +1903,6 @@ static void exynos4_jpeg_device_run(void *priv)
if (ctx->mode == S5P_JPEG_ENCODE) {
exynos4_jpeg_sw_reset(jpeg->regs);
- exynos4_jpeg_set_interrupt(jpeg->regs);
exynos4_jpeg_set_huf_table_enable(jpeg->regs, 1);
exynos4_jpeg_set_huff_tbl(jpeg->regs);
@@ -1918,20 +1919,60 @@ static void exynos4_jpeg_device_run(void *priv)
exynos4_jpeg_set_stream_size(jpeg->regs, ctx->cap_q.w,
ctx->cap_q.h);
- exynos4_jpeg_set_enc_out_fmt(jpeg->regs, ctx->subsampling);
- exynos4_jpeg_set_img_fmt(jpeg->regs, ctx->out_q.fmt->fourcc);
+ if (ctx->jpeg->variant->version == SJPEG_EXYNOS7) {
+ exynos4_jpeg_set_interrupt(jpeg->regs, SJPEG_EXYNOS7);
+ exynos4_jpeg_set_enc_out_fmt(jpeg->regs,
+ ctx->subsampling, EXYNOS7_ENC_FMT_MASK);
+ exynos4_jpeg_set_img_fmt(jpeg->regs,
+ ctx->out_q.fmt->fourcc,
+ EXYNOS7_SWAP_CHROMA_SHIFT);
+ } else {
+ exynos4_jpeg_set_interrupt(jpeg->regs, SJPEG_EXYNOS4);
+ exynos4_jpeg_set_enc_out_fmt(jpeg->regs,
+ ctx->subsampling, EXYNOS4_ENC_FMT_MASK);
+ exynos4_jpeg_set_img_fmt(jpeg->regs,
+ ctx->out_q.fmt->fourcc,
+ EXYNOS4_SWAP_CHROMA_SHIFT);
+ }
+
I'd implement it this way:
exynos4_jpeg_set_interrupt(jpeg->regs, ctx->jpeg->variant->version);
exynos4_jpeg_set_enc_out_fmt(jpeg->regs, ctx->subsampling,
[PATCH] usb: dwc2: add support for initial state for dual-role mode
DWC2 module on Exynos SoCs is used only as peripheral controller (UDC),
so add support for selecting default initial state for dual-role mode. The
default init mode can be overridden by device tree 'dr_mode' property.
This patch enables to use usb gadget on Exynos SoCs, when DWC2 driver has
been compiled as 'dual-role driver'.
Signed-off-by: Marek Szyprowski
---
drivers/usb/dwc2/core.h | 3 +++
drivers/usb/dwc2/platform.c | 62 ++---
2 files changed, 56 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 7a70a13..b0fed4e 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -354,6 +354,7 @@ struct dwc2_core_params {
int reload_ctl;
int ahbcfg;
int uframe_sched;
+ int default_dr_mode;
};
/**
@@ -570,6 +571,8 @@ struct dwc2_hsotg {
struct dwc2_core_params *core_params;
enum usb_otg_state op_state;
enum usb_dr_mode dr_mode;
+ unsigned int hcd_enabled:1;
+ unsigned int gadget_enabled:1;
struct phy *phy;
struct usb_phy *uphy;
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 6a795aa..8abf437 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -76,6 +76,7 @@ static const struct dwc2_core_params params_bcm2835 = {
.reload_ctl = 0,
.ahbcfg = 0x10,
.uframe_sched = 0,
+ .default_dr_mode= USB_DR_MODE_OTG,
};
static const struct dwc2_core_params params_rk3066 = {
@@ -104,6 +105,36 @@ static const struct dwc2_core_params params_rk3066 = {
.reload_ctl = -1,
.ahbcfg = 0x7, /* INCR16 */
.uframe_sched = -1,
+ .default_dr_mode= USB_DR_MODE_OTG,
+};
+
+static const struct dwc2_core_params params_s3c_hsotg = {
+ .otg_cap= -1,
+ .otg_ver= -1,
+ .dma_enable = 0,
+ .dma_desc_enable= 0,
+ .speed = -1,
+ .enable_dynamic_fifo= -1,
+ .en_multiple_tx_fifo= -1,
+ .host_rx_fifo_size = -1,
+ .host_nperio_tx_fifo_size = -1,
+ .host_perio_tx_fifo_size= -1,
+ .max_transfer_size = -1,
+ .max_packet_count = -1,
+ .host_channels = -1,
+ .phy_type = -1,
+ .phy_utmi_width = -1,
+ .phy_ulpi_ddr = -1,
+ .phy_ulpi_ext_vbus = -1,
+ .i2c_enable = -1,
+ .ulpi_fs_ls = -1,
+ .host_support_fs_ls_low_power = -1,
+ .host_ls_low_power_phy_clk = -1,
+ .ts_dline = -1,
+ .reload_ctl = -1,
+ .ahbcfg = -1,
+ .uframe_sched = -1,
+ .default_dr_mode= USB_DR_MODE_PERIPHERAL,
};
/**
@@ -121,8 +152,10 @@ static int dwc2_driver_remove(struct platform_device *dev)
{
struct dwc2_hsotg *hsotg = platform_get_drvdata(dev);
- dwc2_hcd_remove(hsotg);
- s3c_hsotg_remove(hsotg);
+ if (hsotg->hcd_enabled)
+ dwc2_hcd_remove(hsotg);
+ if (hsotg->gadget_enabled)
+ s3c_hsotg_remove(hsotg);
return 0;
}
@@ -131,7 +164,7 @@ static const struct of_device_id dwc2_of_match_table[] = {
{ .compatible = "brcm,bcm2835-usb", .data = ¶ms_bcm2835 },
{ .compatible = "rockchip,rk3066-usb", .data = ¶ms_rk3066 },
{ .compatible = "snps,dwc2", .data = NULL },
- { .compatible = "samsung,s3c6400-hsotg", .data = NULL},
+ { .compatible = "samsung,s3c6400-hsotg", .data = ¶ms_s3c_hsotg },
{},
};
MODULE_DEVICE_TABLE(of, dwc2_of_match_table);
@@ -211,15 +244,26 @@ static int dwc2_driver_probe(struct platform_device *dev)
(unsigned long)res->start, hsotg->regs);
hsotg->dr_mode = of_usb_get_dr_mode(dev->dev.of_node);
+ if (hsotg->dr_mode == USB_DR_MODE_UNKNOWN &&
+ params->default_dr_mode > USB_DR_MODE_UNKNOWN)
+ hsotg->dr_mode = params->default_dr_mode;
spin_lock_init(&hsotg->lock);
mutex_init(&hsotg->init_mutex);
- retval = dwc2_gadget_init(hsotg, irq);
- if (retval)
- return retval;
- retval = dwc2_hcd_init(hsotg, irq, params);
- if (retval)
- return retval;
+
+ if (hsotg->dr_mode != USB_DR_MODE_HOST) {
+ retval = dwc2_gadget_init(hsotg, irq);
+ if (retval)
+ return retval;
+ hsotg->gadget_enabled = 1;
+ }
+
+ if (hsotg->dr_mode != USB_DR_MODE_PERIPHERA
Re: [PATCH RFC v3 1/2] PM / Domains: Extend API pm_genpd_dev_need_restore to use restore types
Hello, On 2014-12-17 03:43, amit daniel kachhap wrote: On Tue, Dec 16, 2014 at 4:40 PM, Marek Szyprowski wrote: Hello, On 2014-12-13 17:51, Amit Daniel Kachhap wrote: Instead of using bool to restore suspended devices initially, use flags like GPD_DEV_SUSPEND_INIT, GPD_DEV_RESTORE_INIT and GPD_DEV_RESTORE_FORCE. The first two flags will be similar to the existing true/false functionality. The third flag may be used to force restore of suspended devices whenever their associated power domain is turned on. Currently, PD power off function powers off all the associated unused devices. The functionality added in this patch is similar to it. This feature may be used for those devices which are always in ON state if the PD associated with them is ON but may need local runtime resume and suspend during PD On/Off. These devices (like clock) may not implement complete pm_runtime calls such as pm_runtime_get/pm_runtime_put due to subsystems interaction behaviour or any other reason. The model works like, DEV1 (Attaches itself with PD but no calls to pm_runtime_get and / pm_runtime_put. Its local runtime_suspend/resume is invoked via / GPD_DEV_RESTORE_FORCE option) / PD -- DEV2 (Implements complete PM runtime and calls pm_runtime_get and \pm_runtime_put. This in turn invokes PD On/Off) \ DEV3 (Similar to DEV1) Signed-off-by: Amit Daniel Kachhap The idea of adding new gen_pd flag and reusing runtime pm calls intead of additional notifiers looks promising, but I have some doubts. I don't see any guarantee that devices with GPD_DEV_RESTORE_FORCE flag will be suspended after all "normal" devices and restored before them. Without such assumption it will be hard to use this approach for iommu related activities, because device might need to use (in its suspend/resume callbacks) the functionality provided by the other device with GPD_DEV_RESTORE_FORCE flag. Maybe some additional flags like suspend/resume priority (or more flags) will solve somehow this dependency. Thanks for pointing this issue out. I agree that there is no priority in suspending devices with this flag. But this works well in syncing with power domain on/off as the devices of these types have only dependency with power domain. BTW I tested this implementation with your first version of IOMMU save/restore patches. Although i have not posted those but they work fine. I can post those after cleaning them up. Right, they will work, but mainly because right now master devices don't do any memory DMA operations in suspend/resume callbacks. However, to propose it as a generic solution, the priority and the order of operations should be somehow determined. Here, the ordering between various devices is taken care as they are probed at different point of time(clock then IOMMU). so the suspend happens in reverse probe order and resume happens in probe order. I will check more on this and get back. Right now, it probably used the order of probing. Because iommu controllers are probed earlier, so they are handled before the master devices. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland -- 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 V8 00/14] drm/exynos: few patches to enhance bridge chip support
Hi Javier, On Wednesday 17 December 2014 10:31:41 Javier Martinez Canillas wrote: > On 12/16/2014 12:37 AM, Laurent Pinchart wrote: > > Hi Javier, > > > >> Tomi and Laurent, > >> > >> You asked Ajay to change his series to use the video port and enpoints DT > >> bindings instead of phandles, could you please review his latest version? > >> > >> I guess is now too late for 3.19 since we are in the middle of the merge > >> window but it would be great if this series can at least made it to 3.20. > > > > I don't have time to review the series in details right now, but I'm happy > > with the DT bindings, and have no big issue with the rest of the patches. > > I > > don't really like the of_drm_find_bridge() concept introduced in 03/14 but > > I won't nack it given lack of time to implement an alternative proposal. > > It's an internal API, it can always be reworked later anyway. > > Thanks a lot for taking the time to look at the DT bindings, You're welcome. Sorry for the long delay. > then I guess that the series are finally ready to be merged? >From my point of view, yes. > Ajay's series don't apply cleanly anymore because it has been a while since > he posted it but he can rebase on top of 3.19-rc1 once it is released and > re-resend. -- Regards, Laurent Pinchart -- 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] Input: atmel_mxt_ts - Add support for T100 multi-touch
On 16/12/14 17:46, Javier Martinez Canillas wrote: > On 12/16/2014 06:07 PM, Nick Dyer wrote: >> I had been keeping them separate on the basis that we don't want changes to >> support new T100 features to cause regressions in the old T9 handling. But >> there is a fair amount of duplication as you say, probably worth addressing. > > Yeah but if there are regressions I think we should address those instead of > duplicating code, to make the driver more maintainable in the long term. True enough. We will have to be careful to test on both types of device. -- 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 V8 00/14] drm/exynos: few patches to enhance bridge chip support
Hello Laurent and Tomi, On 12/16/2014 12:37 AM, Laurent Pinchart wrote: > Hi Javier, >> Tomi and Laurent, >> >> You asked Ajay to change his series to use the video port and enpoints DT >> bindings instead of phandles, could you please review his latest version? >> >> I guess is now too late for 3.19 since we are in the middle of the merge >> window but it would be great if this series can at least made it to 3.20. > > I don't have time to review the series in details right now, but I'm happy > with the DT bindings, and have no big issue with the rest of the patches. I > don't really like the of_drm_find_bridge() concept introduced in 03/14 but I > won't nack it given lack of time to implement an alternative proposal. It's > an > internal API, it can always be reworked later anyway. > Thanks a lot for taking the time to look at the DT bindings, then I guess that the series are finally ready to be merged? Ajay's series don't apply cleanly anymore because it has been a while since he posted it but he can rebase on top of 3.19-rc1 once it is released and re-resend. Best regards, Javier -- 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
