Re: [PATCH 0/7] drm/exynos/hdmi: refactoring/cleanup patches
On 07/09/2015 11:28 PM, Andrzej Hajda wrote: > Hi Inki, Joonyoung, > > These patches removes obsolete and old structures, to simplify further > development. They should not change behavior of the driver. > > The patchset is based on exynos-drm-next plus my HDMI related fixes [1]. > > The patchset was tested on Universal and Odroid U3. > > [1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/132348 > > Regards > Andrzej > > > Andrzej Hajda (7): > drm/exynos/hdmi: remove old platform data code > drm/exynos/hdmi: Simplify HPD gpio handling > drm/exynos/hdmi: remove private lock code > drm/exynos/hdmi: add driver data pointer to private context > drm/exynos/hdmi: remove redundant configuration fields > drm/exynos/hdmi: remove hdmi_v13_conf struct > drm/exynos/hdmi: remove hdmi_v14_conf struct > > drivers/gpu/drm/exynos/exynos_hdmi.c | 860 > ++- > 1 file changed, 245 insertions(+), 615 deletions(-) > Looks good to me about this patchset, Reviewed-by: Joonyoung Shim -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6] ARM: dts: add exynos5422-cpus.dtsi to correct cpu order
On 14.07.2015 14:36, Mauro Ribeiro wrote: > In my opinion since its something configurable by the board and not > SoC specific it should be defined (or re-defined) on the board dts. > > If one makes a 5422 board booting from A15's that patch will be > already invalid and causing the issue that it fixes. Indeed this is configurable by the board. For Odroid XU3 this is fixed (hard-wired) but other boards may have it in different way. We already discussed this and Chanho Park is here: http://www.spinics.net/lists/linux-samsung-soc/msg44924.html http://www.spinics.net/lists/linux-samsung-soc/msg44930.html There were no additional objections to the patchset in that time. 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: [PATCHv6] ARM: dts: add exynos5422-cpus.dtsi to correct cpu order
In my opinion since its something configurable by the board and not SoC specific it should be defined (or re-defined) on the board dts. If one makes a 5422 board booting from A15's that patch will be already invalid and causing the issue that it fixes. 2015-07-14 2:04 GMT-03:00 Kukjin Kim : > Krzysztof Kozlowski wrote: >> >> On 14.07.2015 09:24, Chanho Park wrote: >> > The odroid-xu3 board which is based on exynos5422 not exynos5800 is >> > booted from cortex-a7 core unlike exynos5800. The odroid-xu3's cpu order >> > is quite strange. cpu0 and cpu5-7 are cortex-a7 cores and cpu1-4 are >> > cortex-a15 cores. To correct this mis-odering, I added exynos5422-cpus.dtsi >> > and reversing cpu orders from exynos5420. Now, cpu0-3 are cortex-a7 and >> > cpu4-7 are cortex-a15. >> > >> > Reviewed-by: Krzysztof Kozlowski >> > Signed-off-by: Chanho Park >> > --- >> > Change from v4: >> > - Resend patch with correct signed-off >> > >> > Changes from v4: >> > - Remove temporal patch in e-mail body >> > >> > Changes from v3: >> > - include this exynos5422-cpus.dtsi in the >> > exynos5422-odroidxu3-common.dtsi >> > >> > Changes from v2: >> > - drop inclusion of exynos5420.dtsi from exynos5422-cpus.dtsi >> > - drop compatibles from exynos5422-cpus.dtsi >> > >> > Changes from v1: >> > - rename exynos5422.dtsi to exynos5422-cpus.dtsi >> > - include the dtsi file top of the exynos5422-odroidxu3.dts >> > >> > Secondary cpu booting problem[1] is not resolved yet. Need more >> > investigations >> > to work booting 8 cores correctly. >> > >> > [1]: http://www.spinics.net/lists/linux-samsung-soc/msg45525.html >> > >> > arch/arm/boot/dts/exynos5422-cpus.dtsi | 81 >> > ++ >> > arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 1 + >> > 2 files changed, 82 insertions(+) >> > create mode 100644 arch/arm/boot/dts/exynos5422-cpus.dtsi >> >> Thanks, applied to my tree. I'll send it to Kukjin for v4.3 unless he >> picks it also. >> > Well, let me see. I'm thinking we need to sort out the cpu ordering and dtsi > inclusions for exynos5420, 5422 and 5800 related to DT files. > > See, > > 1) exynos5420 DT (cpu0~3: a15, cpu 4~7: a7) > 2) exynos5800 DT is including exynos5420 DT > 3) exynos5422 and exynos5800 based boards are including exynos5800 DT. > > Then making exynos5422-cpus DT for exynos5422 based boards? > (cpu0~3: a7, cpu4~7: a15) > > I think, it could cause confusion when new board based on them are added > because it's not clear and the boot cpu could be selected by bootloader part. > > So how about creating exynos5422-cpus and exynos5420-cpus then including the > cpus DT file in each board accordingly? > > Or more clear way to avoid confusion? > > - 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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv6] ARM: dts: add exynos5422-cpus.dtsi to correct cpu order
Krzysztof Kozlowski wrote: > > On 14.07.2015 09:24, Chanho Park wrote: > > The odroid-xu3 board which is based on exynos5422 not exynos5800 is > > booted from cortex-a7 core unlike exynos5800. The odroid-xu3's cpu order > > is quite strange. cpu0 and cpu5-7 are cortex-a7 cores and cpu1-4 are > > cortex-a15 cores. To correct this mis-odering, I added exynos5422-cpus.dtsi > > and reversing cpu orders from exynos5420. Now, cpu0-3 are cortex-a7 and > > cpu4-7 are cortex-a15. > > > > Reviewed-by: Krzysztof Kozlowski > > Signed-off-by: Chanho Park > > --- > > Change from v4: > > - Resend patch with correct signed-off > > > > Changes from v4: > > - Remove temporal patch in e-mail body > > > > Changes from v3: > > - include this exynos5422-cpus.dtsi in the exynos5422-odroidxu3-common.dtsi > > > > Changes from v2: > > - drop inclusion of exynos5420.dtsi from exynos5422-cpus.dtsi > > - drop compatibles from exynos5422-cpus.dtsi > > > > Changes from v1: > > - rename exynos5422.dtsi to exynos5422-cpus.dtsi > > - include the dtsi file top of the exynos5422-odroidxu3.dts > > > > Secondary cpu booting problem[1] is not resolved yet. Need more > > investigations > > to work booting 8 cores correctly. > > > > [1]: http://www.spinics.net/lists/linux-samsung-soc/msg45525.html > > > > arch/arm/boot/dts/exynos5422-cpus.dtsi | 81 > > ++ > > arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 1 + > > 2 files changed, 82 insertions(+) > > create mode 100644 arch/arm/boot/dts/exynos5422-cpus.dtsi > > Thanks, applied to my tree. I'll send it to Kukjin for v4.3 unless he > picks it also. > Well, let me see. I'm thinking we need to sort out the cpu ordering and dtsi inclusions for exynos5420, 5422 and 5800 related to DT files. See, 1) exynos5420 DT (cpu0~3: a15, cpu 4~7: a7) 2) exynos5800 DT is including exynos5420 DT 3) exynos5422 and exynos5800 based boards are including exynos5800 DT. Then making exynos5422-cpus DT for exynos5422 based boards? (cpu0~3: a7, cpu4~7: a15) I think, it could cause confusion when new board based on them are added because it's not clear and the boot cpu could be selected by bootloader part. So how about creating exynos5422-cpus and exynos5420-cpus then including the cpus DT file in each board accordingly? Or more clear way to avoid confusion? - 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] serial: samsung: Remove redundant DEBUG_LL check
Krzysztof Kozlowski wrote:
>
> On 13.07.2015 20:18, Javier Martinez Canillas wrote:
> > Commit 84f57d9e3685 ("tty: serial/samsung: fix modular build") fixed
> > build issues when the driver was built as a module. One of those was
> > that printascii is only accessible when the driver is built-in.
> >
> > But there is no need to check for defined(CONFIG_DEBUG_LL) since the
> > SERIAL_SAMSUNG_DEBUG Kconfig symbol already depends on DEBUG_LL.
> >
> > Signed-off-by: Javier Martinez Canillas
Acked-by: Kukjin Kim
Thanks,
Kukjin
> >
> > ---
> >
> > drivers/tty/serial/samsung.c | 1 -
> > 1 file changed, 1 deletion(-)
>
> Although this redundancy is not harmful the patch seems fine, so:
> Reviewed-by: Krzysztof Kozlowski
>
> 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] serial: samsung: Remove redundant DEBUG_LL check
On 13.07.2015 20:18, Javier Martinez Canillas wrote:
> Commit 84f57d9e3685 ("tty: serial/samsung: fix modular build") fixed
> build issues when the driver was built as a module. One of those was
> that printascii is only accessible when the driver is built-in.
>
> But there is no need to check for defined(CONFIG_DEBUG_LL) since the
> SERIAL_SAMSUNG_DEBUG Kconfig symbol already depends on DEBUG_LL.
>
> Signed-off-by: Javier Martinez Canillas
>
> ---
>
> drivers/tty/serial/samsung.c | 1 -
> 1 file changed, 1 deletion(-)
Although this redundancy is not harmful the patch seems fine, so:
Reviewed-by: Krzysztof Kozlowski
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: [PATCHv6] ARM: dts: add exynos5422-cpus.dtsi to correct cpu order
On 14.07.2015 09:24, Chanho Park wrote: > The odroid-xu3 board which is based on exynos5422 not exynos5800 is > booted from cortex-a7 core unlike exynos5800. The odroid-xu3's cpu order > is quite strange. cpu0 and cpu5-7 are cortex-a7 cores and cpu1-4 are > cortex-a15 cores. To correct this mis-odering, I added exynos5422-cpus.dtsi > and reversing cpu orders from exynos5420. Now, cpu0-3 are cortex-a7 and > cpu4-7 are cortex-a15. > > Reviewed-by: Krzysztof Kozlowski > Signed-off-by: Chanho Park > --- > Change from v4: > - Resend patch with correct signed-off > > Changes from v4: > - Remove temporal patch in e-mail body > > Changes from v3: > - include this exynos5422-cpus.dtsi in the exynos5422-odroidxu3-common.dtsi > > Changes from v2: > - drop inclusion of exynos5420.dtsi from exynos5422-cpus.dtsi > - drop compatibles from exynos5422-cpus.dtsi > > Changes from v1: > - rename exynos5422.dtsi to exynos5422-cpus.dtsi > - include the dtsi file top of the exynos5422-odroidxu3.dts > > Secondary cpu booting problem[1] is not resolved yet. Need more investigations > to work booting 8 cores correctly. > > [1]: http://www.spinics.net/lists/linux-samsung-soc/msg45525.html > > arch/arm/boot/dts/exynos5422-cpus.dtsi | 81 > ++ > arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 1 + > 2 files changed, 82 insertions(+) > create mode 100644 arch/arm/boot/dts/exynos5422-cpus.dtsi Thanks, applied to my tree. I'll send it to Kukjin for v4.3 unless he picks it also. 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
[PATCHv6] ARM: dts: add exynos5422-cpus.dtsi to correct cpu order
The odroid-xu3 board which is based on exynos5422 not exynos5800 is
booted from cortex-a7 core unlike exynos5800. The odroid-xu3's cpu order
is quite strange. cpu0 and cpu5-7 are cortex-a7 cores and cpu1-4 are
cortex-a15 cores. To correct this mis-odering, I added exynos5422-cpus.dtsi
and reversing cpu orders from exynos5420. Now, cpu0-3 are cortex-a7 and
cpu4-7 are cortex-a15.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Chanho Park
---
Change from v4:
- Resend patch with correct signed-off
Changes from v4:
- Remove temporal patch in e-mail body
Changes from v3:
- include this exynos5422-cpus.dtsi in the exynos5422-odroidxu3-common.dtsi
Changes from v2:
- drop inclusion of exynos5420.dtsi from exynos5422-cpus.dtsi
- drop compatibles from exynos5422-cpus.dtsi
Changes from v1:
- rename exynos5422.dtsi to exynos5422-cpus.dtsi
- include the dtsi file top of the exynos5422-odroidxu3.dts
Secondary cpu booting problem[1] is not resolved yet. Need more investigations
to work booting 8 cores correctly.
[1]: http://www.spinics.net/lists/linux-samsung-soc/msg45525.html
arch/arm/boot/dts/exynos5422-cpus.dtsi | 81 ++
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 1 +
2 files changed, 82 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5422-cpus.dtsi
diff --git a/arch/arm/boot/dts/exynos5422-cpus.dtsi
b/arch/arm/boot/dts/exynos5422-cpus.dtsi
new file mode 100644
index 000..b7f60c8
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5422-cpus.dtsi
@@ -0,0 +1,81 @@
+/*
+ * SAMSUNG EXYNOS5422 SoC cpu device tree source
+ *
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * The only difference between EXYNOS5422 and EXYNOS5800 is cpu ordering. The
+ * EXYNOS5422 is booting from Cortex-A7 core while the EXYNOS5800 is booting
+ * from Cortex-A15 core.
+ *
+ * EXYNOS5422 based board files can include this file to provide cpu ordering
+ * which could boot a cortex-a7 from cpu0.
+ *
+ * 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.
+ */
+
+&cpu0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x100>;
+ clock-frequency = <10>;
+ cci-control-port = <&cci_control0>;
+};
+
+&cpu1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x101>;
+ clock-frequency = <10>;
+ cci-control-port = <&cci_control0>;
+};
+
+&cpu2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x102>;
+ clock-frequency = <10>;
+ cci-control-port = <&cci_control0>;
+};
+
+&cpu3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x103>;
+ clock-frequency = <10>;
+ cci-control-port = <&cci_control0>;
+};
+
+&cpu4 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0x0>;
+ clock-frequency = <18>;
+ cci-control-port = <&cci_control1>;
+};
+
+&cpu5 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0x1>;
+ clock-frequency = <18>;
+ cci-control-port = <&cci_control1>;
+};
+
+&cpu6 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0x2>;
+ clock-frequency = <18>;
+ cci-control-port = <&cci_control1>;
+};
+
+&cpu7 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0x3>;
+ clock-frequency = <18>;
+ cci-control-port = <&cci_control1>;
+};
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 8adf455..f603133 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -15,6 +15,7 @@
#include
#include
#include "exynos5800.dtsi"
+#include "exynos5422-cpus.dtsi"
/ {
memory {
--
2.1.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 4/6] ARM: dts: Exynos4210: add CPU OPP and regulator supply property
On 13.07.2015 23:27, Bartlomiej Zolnierkiewicz wrote: > On Monday, July 13, 2015 01:20:41 PM Bartlomiej Zolnierkiewicz wrote: >> On Monday, July 13, 2015 08:10:21 PM Krzysztof Kozlowski wrote: >>> 2015-07-13 20:02 GMT+09:00 Bartlomiej Zolnierkiewicz >>> : Hi, On Tuesday, June 23, 2015 09:24:40 AM Krzysztof Kozlowski wrote: > On 23.06.2015 08:46, Krzysztof Kozlowski wrote: >> On 23.06.2015 00:04, Michael Turquette wrote: >>> Quoting Kukjin Kim (2015-06-21 18:46:26) Krzysztof Kozlowski wrote: > > On 22.06.2015 10:38, Kukjin Kim wrote: >> Krzysztof Kozlowski wrote: >>> 2015-05-08 9:18 GMT+09:00 Krzysztof Kozlowski >>> : 2015-04-04 1:43 GMT+09:00 Bartlomiej Zolnierkiewicz : > From: Thomas Abraham > > For Exynos4210 platforms, add CPU operating points and CPU > regulator supply properties for migrating from Exynos specific > cpufreq driver to using generic cpufreq driver. > > Changes by Bartlomiej: > - removed Exynos5250 and Exynos5420 support for now > > Cc: Kukjin Kim > Cc: Doug Anderson > Cc: Javier Martinez Canillas > Cc: Andreas Faerber > Cc: Sachin Kamat > Cc: Andreas Farber > Cc: Javier Martinez Canillas > Signed-off-by: Thomas Abraham > Signed-off-by: Bartlomiej Zolnierkiewicz > Acked-by: Krzysztof Kozlowski >>> >>> Rebased and applied to my tree, I'll sent it later to Kukjin unless >>> he >>> picks it by himself from LKML. >>> >> Hi, as far as I know, this is for v4.2 not v4.1 so it will be >> applied based on >> v4.2-rc1 after v4.2-rc1 release. > > You mean it is for v4.3, not v4.2? > Oops, yes v4.3. Thanks for the correction. >>> >>> Kukjin & Krzysztof, >>> >>> I'm confused on this point. I was planning to take patches 1, 2, 3, 5 >>> and 6 towards 4.2 (e.g. in the pull request that I'll send out this >>> week). >>> >>> Is patch 4 going out for 4.2 or 4.3? >> >> It is quite late for sending pull request to arm-soc for 4.2. >> For example SoCFPGA pull request from last week was rejected: >> http://comments.gmane.org/gmane.linux.ports.arm.kernel/417980 > > Oh, that was wrong link. Here it is: > http://www.spinics.net/lists/arm-kernel/msg425911.html > >> If you want to take it for 4.2 then I am fine with it but this will >> cause some easy but annoying conflicts. There aren't difficult - just >> most of nodes in board DTS changed their place. >> >> Example of resolution (target file after merge, with cpu nodes reordered >> alphabetically): >> https://github.com/krzk/linux/commit/2cec3cb48abaf44848c62f1c0836b772eb4680dd This patch is needed for v4.2 as other changes has been already merged. Krzysztof/Kukjin, could you please take care of it? >>> >>> Of course! It is already in my queue. I'll send it later to Kukjin for >>> 4.3 (unless he picks it also). >> >> It is in your queue for v4.3 but the patch is needed for v4.2, >> without it cpufreq support will not work for Exynos4210 platforms. >> >>> BTW for other patchsets you still need acks from Samsung clock >>> maintainers. Did you poke Sylwester or Tomasz about it? >> >> Sylwester, please review/ack Samsung specific clock changes in >> Exynos5250 cpufreq and Exynos4x12 cpufreq patch series. >> >> Patch series: >> >> * [PATCH v3 0/4] cpufreq: use generic cpufreq drivers for Exynos5250 platform >> (http://lkml.org/lkml/2015/7/1/311) >> >> * [PATCH v2 0/7] cpufreq: use generic cpufreq drivers for Exynos4x12 platform >> (http://lkml.org/lkml/2015/7/9/419) >> >> Samsung clock specific changes: >> >> * [PATCH v3 1/4] clk: samsung: exynos5250: add cpu clock configuration data >> and instantiate cpu clock >> (http://lkml.org/lkml/2015/7/1/313) >> >> * [PATCH v2 4/7] clk: samsung: exynos4x12: add cpu clock configuration data >> and instantiate cpu clock >> (http://lkml.org/lkml/2015/7/9/424) > > BTW corresponding changes for Exynos4210 has already been merged and 2 above > patches are quite obvious so review should be very quick & simple. > > [ Unfortunately Sylwester is currently very busy with a more priority work so > it may still take some time to get his ACKs. ] The review would be fast and already Javier or me provided such. Anyway if you want to merge it through different tree it would be expected to get an ack from bypassed maintainer. Especially that the distance between you and the bypassed maintainer was ~1 meter for the most of the time :) . It is much longer distance between you and me now! Best regards, Krzysztof -- To unsubscri
Re: [PATCH 0/7] drm/exynos/hdmi: refactoring/cleanup patches
Hello!
Andrzej Hajda wrote:
> On 07/13/2015 11:04 AM, Tobias Jakobi wrote:
>> Hello,
>>
>> Andrzej Hajda wrote:
>>> Hi Tobias,
>>>
>>> On 07/12/2015 06:06 PM, Tobias Jakobi wrote:
Hello Andrzej!
Just some small comments.
It seems like linux-samsung-soc wasn't put into Cc for '[PATCH RESEND
0/6] drm/exynos: HDMI related fixes' (even though this series was),
maybe you should also forward the other series to this list.
>>> Yes, I forgot about it.
>>>
This series doesn't apply cleanly when 'drm/exynos: HDMI related fixes'
is applied. E.g. the 'powered' boolean was removed by that series, but
here in patch 2/7 ('drm/exynos/hdmi: Simplify HPD gpio handling') it's
still there.
>>> 'drm/exynos: HDMI related fixes' removes powered field from
>>> mixer driver, and powered field in the patch 2/7 is from hdmi driver.
>>> So they should not interfere and for sure they do not interfere in my local
>>> git :)
>>> Have you any warning when you tried to apply those patches.
>> yes of course, otherwise I wouldn't point this out. The specific hunks
>> just fail.
>>
>> Which is kinda obvious:
>>> @@ -186,7 +186,6 @@ struct hdmi_context {
>>> struct drm_device *drm_dev;
>>> struct drm_connectorconnector;
>>> struct drm_encoder *encoder;
>>> - boolhpd;
>>> boolpowered;
>>> booldvi_mode;
>>> struct mutexhdmi_mutex;
>> This doesn't apply when 'powered' is no longer ther.
>
> I have this field still present in my tree which is build of following
> components:
> - current exynos-drm-next,
> - drm/exynos: HDMI related fixes,
> - this patchset
>
> Could you show me exactly which patch removes this field?
>
> As I mentioned one patch removes similar field from mixer driver, but not
> from hdmi.
You're right, looks like I'm mixing up fields from mixer and hdmi. Hmm,
now I'm confused -- I did have some problems applying the patches, but
with this now ruled out I can't really recall anything else that may
have caused this.
Guess I have to repeat the steps. So until further notice, just
disregard everything I said! *g*
With best wishes,
Tobias
>
> Regards
> Andrzej
>
>
>>
>>
>>
>> With best wishes,
>> Tobias
>>
I also noticed that some of the patches ('drm/exynos/hdmi: remove
private lock code') clash with Gustavo's latest cleanup series [1]. E.g.
your patch 3/7 ('drm/exynos/hdmi: remove private lock code') touches
hdmi_commit() which was removed by Gustavo. Maybe you should coordinate
things with him?
>>> This is always problematic :) I can try to rebase my patches on Gustavo's
>>> if necessary. Gustavo, Inki what is your opinion?
>>>
>>> Regards
>>> Andrzej
>>>
With best wishes,
Tobias
[1] http://www.spinics.net/lists/linux-samsung-soc/msg45787.html
Andrzej Hajda wrote:
> Hi Inki, Joonyoung,
>
> These patches removes obsolete and old structures, to simplify further
> development. They should not change behavior of the driver.
>
> The patchset is based on exynos-drm-next plus my HDMI related fixes [1].
>
> The patchset was tested on Universal and Odroid U3.
>
> [1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/132348
>
> Regards
> Andrzej
>
>
> Andrzej Hajda (7):
> drm/exynos/hdmi: remove old platform data code
> drm/exynos/hdmi: Simplify HPD gpio handling
> drm/exynos/hdmi: remove private lock code
> drm/exynos/hdmi: add driver data pointer to private context
> drm/exynos/hdmi: remove redundant configuration fields
> drm/exynos/hdmi: remove hdmi_v13_conf struct
> drm/exynos/hdmi: remove hdmi_v14_conf struct
>
> drivers/gpu/drm/exynos/exynos_hdmi.c | 860
> ++-
> 1 file changed, 245 insertions(+), 615 deletions(-)
>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-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 06/13] irqchip: kill off set_irq_flags usage
On Sun, Jul 12, 2015 at 11:43 AM, Thomas Gleixner wrote: > On Sun, 12 Jul 2015, Rob Herring wrote: > >> set_irq_flags is ARM specific with custom flags which have genirq >> equivalents. Convert drivers to use the genirq interfaces directly, so we >> can kill off set_irq_flags. The translation of flags is as follows: >> >> IRQF_VALID -> !IRQ_NOREQUEST >> IRQF_PROBE -> !IRQ_NOPROBE >> IRQF_NOAUTOEN -> IRQ_NOAUTOEN >> >> For IRQs managed by an irqdomain, the irqdomain core code handles clearing >> and setting IRQ_NOREQUEST already, so there is no need to do this in >> .map() functions and we can simply remove the set_irq_flags calls. Some >> users also set IRQ_NOPROBE and this has been maintained although it is not > > clear IRQ_NOPROBE, right? Both set and clear really. The state of IRQ_NOPROBE is a don't care in most cases as you have outlined below. Are the cases of setting IRQ_NOPROBE really needed or simply a bunch of copy and paste? I've noticed I have a few places wrong with probe setting though, so I'll be sending a v3. >> clear that is really needed. There appears to be a great deal of blind >> copy and paste of this code. > > Looking at the irq probe users: > > drivers/input/touchscreen/ucb1400_ts.c > drivers/mfd/ucb1x00-core.c > > The probe function was added in the initial implementation of the > driver (2006), so it predates device tree. We still have lots of platforms which are not (and probably never will be) DT. Certainly, DT only irqchips should be easy to make consistent. The older stuff is harder and not frequently tested. > drivers/net/appletalk/ltpc.c > drivers/net/arcnet/com20020-isa.c > drivers/net/arcnet/com90io.c > drivers/net/arcnet/com90xx.c > > Surely not stuff you find on todays ARM systems > > drivers/net/ethernet/8390/ne.c > drivers/net/ethernet/8390/wd.c > drivers/net/ethernet/amd/lance.c > drivers/net/ethernet/amd/ni65.c > drivers/net/ethernet/amd/pcnet32.c > > Ditto > > drivers/net/ethernet/smsc/smc911x.c > drivers/net/ethernet/smsc/smc9194.c > drivers/net/ethernet/smsc/smc91x.c > > Those might still be, but on the DT based boards the probing should be > completely irrelevant Yes, these are quite common on ARM boards, and probably few if any rely on irq probing regardless of DT. > drivers/net/hamradio/dmascc.c > drivers/net/wan/cosa.c > drivers/net/wan/sbni.c > drivers/parport/parport_pc.c > > Surely not stuff you find on todays ARM systems > > drivers/pcmcia/yenta_socket.c > > Russell might still use that. > > drivers/scsi/NCR53c406a.c > drivers/scsi/sym53c416.c > drivers/tty/cyclades.c > > Surely not stuff you find on todays ARM systems > > drivers/tty/serial/8250/8250_core.c > > The irq probing is used by > > mach-imx/mach-mx31ads.c > mach-iop32x/n2100.c > > and X86 > > So in most of the irqchip drivers, this is irrelevant. Agreed, but that's a separate series I think. I'm trying not to change behavior with this series. Are you proposing I do something different with this patch? Rob -- To unsubscribe from this list: send the line "unsubscribe linux-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:irqchip: IRQCHIP_DECLARE macro is now accessible
On Tue, Jul 07, 2015 at 04:02:53PM -0400, Joel Porquet wrote:
> The IRQCHIP_DECLARE macro migrated to 'include/linux/irqchip.h', making it
> globally accessible.
>
> See commit 91e20b5040c67c51aad88cf87db4305c5bd7f79d
> ("irqchip: Move IRQCHIP_DECLARE macro to include/linux/irqchip.h").
>
> This patch adds inclusions of 'include/linux/irqchip.h' and replaces uses of
> macro OF_DECLARE_2 with IRQCHIP_DECLARE.
>
> Signed-off-by: Joel Porquet
> ---
...
> arch/arm/mach-imx/gpc.c | 7 ++-
Acked-by: Shawn Guo
How will this patch be sent to upstream?
Shawn
--
To unsubscribe from this list: send the line "unsubscribe linux-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/9 v7] Helper to abstract vma handling in media layer
On 07/13/2015 04:55 PM, Jan Kara wrote: > From: Jan Kara > > Hello, > > I'm sending the seventh version of my patch series to abstract vma handling > from the various media drivers. Since the previous version there are just > minor cleanups and fixes (see detailed changelog at the end of the email). > > After this patch set drivers have to know much less details about vmas, their > types, and locking. Also quite some code is removed from them. As a bonus > drivers get automatically VM_FAULT_RETRY handling. The primary motivation for > this series is to remove knowledge about mmap_sem locking from as many places > a > possible so that we can change it with reasonable effort. > > The core of the series is the new helper get_vaddr_frames() which is given a > virtual address and it fills in PFNs / struct page pointers (depending on VMA > type) into the provided array. If PFNs correspond to normal pages it also > grabs > references to these pages. The difference from get_user_pages() is that this > function can also deal with pfnmap, and io mappings which is what the media > drivers need. > > I have tested the patches with vivid driver so at least vb2 code got some > exposure. Conversion of other drivers was just compile-tested (for x86 so e.g. > exynos driver which is only for Samsung platform is completely untested). > > Hans, can you please pull the changes? Thanks! Scheduled for Friday or the following Monday! Thanks, Hans > > Honza > > Changes since v6: > * Fixed compilation error introduced into exynos driver > * Folded patch allowing get_vaddr_pfn() code to be selected by a config option > into previous patches > * Rebased on top of linux-media tree > > Changes since v5: > * Moved mm helper into a separate file and behind a config option > * Changed the first patch pushing mmap_sem down in videobuf2 core to avoid > possible deadlock > > Changes since v4: > * Minor cleanups and fixes pointed out by Mel and Vlasta > * Added Acked-by tags > > Changes since v3: > * Added include into mm/gup.c as it's needed for some archs > * Fixed error path for exynos driver > > Changes since v2: > * Renamed functions and structures as Mel suggested > * Other minor changes suggested by Mel > * Rebased on top of 4.1-rc2 > * Changed functions to get pointer to array of pages / pfns to perform > conversion if necessary. This fixes possible issue in the omap I may have > introduced in v2 and generally makes the API less errorprone. > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" 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
[PATCH 6/9] media: vb2: Convert vb2_vmalloc_get_userptr() to use frame vector
From: Jan Kara
Convert vb2_vmalloc_get_userptr() to use frame vector infrastructure.
When we are doing that there's no need to allocate page array and some
code can be simplified.
Acked-by: Marek Szyprowski
Tested-by: Marek Szyprowski
Signed-off-by: Jan Kara
---
drivers/media/v4l2-core/videobuf2-vmalloc.c | 92 +++--
1 file changed, 36 insertions(+), 56 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-vmalloc.c
b/drivers/media/v4l2-core/videobuf2-vmalloc.c
index 63bef959623e..ecb8f0c7f025 100644
--- a/drivers/media/v4l2-core/videobuf2-vmalloc.c
+++ b/drivers/media/v4l2-core/videobuf2-vmalloc.c
@@ -23,11 +23,9 @@
struct vb2_vmalloc_buf {
void*vaddr;
- struct page **pages;
- struct vm_area_struct *vma;
+ struct frame_vector *vec;
enum dma_data_direction dma_dir;
unsigned long size;
- unsigned intn_pages;
atomic_trefcount;
struct vb2_vmarea_handler handler;
struct dma_buf *dbuf;
@@ -76,10 +74,8 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx,
unsigned long vaddr,
enum dma_data_direction dma_dir)
{
struct vb2_vmalloc_buf *buf;
- unsigned long first, last;
- int n_pages, offset;
- struct vm_area_struct *vma;
- dma_addr_t physp;
+ struct frame_vector *vec;
+ int n_pages, offset, i;
buf = kzalloc(sizeof(*buf), GFP_KERNEL);
if (!buf)
@@ -88,53 +84,36 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx,
unsigned long vaddr,
buf->dma_dir = dma_dir;
offset = vaddr & ~PAGE_MASK;
buf->size = size;
-
- down_read(¤t->mm->mmap_sem);
- vma = find_vma(current->mm, vaddr);
- if (vma && (vma->vm_flags & VM_PFNMAP) && (vma->vm_pgoff)) {
- if (vb2_get_contig_userptr(vaddr, size, &vma, &physp))
- goto fail_pages_array_alloc;
- buf->vma = vma;
- buf->vaddr = (__force void *)ioremap_nocache(physp, size);
- if (!buf->vaddr)
- goto fail_pages_array_alloc;
+ vec = vb2_create_framevec(vaddr, size, dma_dir == DMA_FROM_DEVICE);
+ if (IS_ERR(vec))
+ goto fail_pfnvec_create;
+ buf->vec = vec;
+ n_pages = frame_vector_count(vec);
+ if (frame_vector_to_pages(vec) < 0) {
+ unsigned long *nums = frame_vector_pfns(vec);
+
+ /*
+* We cannot get page pointers for these pfns. Check memory is
+* physically contiguous and use direct mapping.
+*/
+ for (i = 1; i < n_pages; i++)
+ if (nums[i-1] + 1 != nums[i])
+ goto fail_map;
+ buf->vaddr = (__force void *)
+ ioremap_nocache(nums[0] << PAGE_SHIFT, size);
} else {
- first = vaddr >> PAGE_SHIFT;
- last = (vaddr + size - 1) >> PAGE_SHIFT;
- buf->n_pages = last - first + 1;
- buf->pages = kzalloc(buf->n_pages * sizeof(struct page *),
-GFP_KERNEL);
- if (!buf->pages)
- goto fail_pages_array_alloc;
-
- /* current->mm->mmap_sem is taken by videobuf2 core */
- n_pages = get_user_pages(current, current->mm,
-vaddr & PAGE_MASK, buf->n_pages,
-dma_dir == DMA_FROM_DEVICE,
-1, /* force */
-buf->pages, NULL);
- if (n_pages != buf->n_pages)
- goto fail_get_user_pages;
-
- buf->vaddr = vm_map_ram(buf->pages, buf->n_pages, -1,
+ buf->vaddr = vm_map_ram(frame_vector_pages(vec), n_pages, -1,
PAGE_KERNEL);
- if (!buf->vaddr)
- goto fail_get_user_pages;
}
- up_read(¤t->mm->mmap_sem);
+ if (!buf->vaddr)
+ goto fail_map;
buf->vaddr += offset;
return buf;
-fail_get_user_pages:
- pr_debug("get_user_pages requested/got: %d/%d]\n", n_pages,
-buf->n_pages);
- while (--n_pages >= 0)
- put_page(buf->pages[n_pages]);
- kfree(buf->pages);
-
-fail_pages_array_alloc:
- up_read(¤t->mm->mmap_sem);
+fail_map:
+ vb2_destroy_framevec(vec);
+fail_pfnvec_create:
kfree(buf);
return NULL;
@@ -145,20 +124,21 @@ static void vb2_vmalloc_put_userptr(void *buf_priv)
struct vb2_vmalloc_buf *buf = buf_priv;
unsigned long vaddr = (unsigned long)buf->vaddr & PAGE_MASK;
unsigned int i;
+
[PATCH 0/9 v7] Helper to abstract vma handling in media layer
From: Jan Kara Hello, I'm sending the seventh version of my patch series to abstract vma handling from the various media drivers. Since the previous version there are just minor cleanups and fixes (see detailed changelog at the end of the email). After this patch set drivers have to know much less details about vmas, their types, and locking. Also quite some code is removed from them. As a bonus drivers get automatically VM_FAULT_RETRY handling. The primary motivation for this series is to remove knowledge about mmap_sem locking from as many places a possible so that we can change it with reasonable effort. The core of the series is the new helper get_vaddr_frames() which is given a virtual address and it fills in PFNs / struct page pointers (depending on VMA type) into the provided array. If PFNs correspond to normal pages it also grabs references to these pages. The difference from get_user_pages() is that this function can also deal with pfnmap, and io mappings which is what the media drivers need. I have tested the patches with vivid driver so at least vb2 code got some exposure. Conversion of other drivers was just compile-tested (for x86 so e.g. exynos driver which is only for Samsung platform is completely untested). Hans, can you please pull the changes? Thanks! Honza Changes since v6: * Fixed compilation error introduced into exynos driver * Folded patch allowing get_vaddr_pfn() code to be selected by a config option into previous patches * Rebased on top of linux-media tree Changes since v5: * Moved mm helper into a separate file and behind a config option * Changed the first patch pushing mmap_sem down in videobuf2 core to avoid possible deadlock Changes since v4: * Minor cleanups and fixes pointed out by Mel and Vlasta * Added Acked-by tags Changes since v3: * Added include into mm/gup.c as it's needed for some archs * Fixed error path for exynos driver Changes since v2: * Renamed functions and structures as Mel suggested * Other minor changes suggested by Mel * Rebased on top of 4.1-rc2 * Changed functions to get pointer to array of pages / pfns to perform conversion if necessary. This fixes possible issue in the omap I may have introduced in v2 and generally makes the API less errorprone. -- To unsubscribe from this list: send the line "unsubscribe linux-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/9] [media] vb2: Push mmap_sem down to memops
From: Jan Kara
Currently vb2 core acquires mmap_sem just around call to
__qbuf_userptr(). However since commit f035eb4e976ef5 (videobuf2: fix
lockdep warning) it isn't necessary to acquire it so early as we no
longer have to drop queue mutex before acquiring mmap_sem. So push
acquisition of mmap_sem down into .get_userptr memop so that the
semaphore is acquired for a shorter time and it is clearer what it is
needed for.
Note that we also need mmap_sem in .put_userptr memop since that ends up
calling vb2_put_vma() which calls vma->vm_ops->close() which should be
called with mmap_sem held. However we didn't hold mmap_sem in some code
paths anyway (e.g. when called via vb2_ioctl_reqbufs() ->
__vb2_queue_free() -> vb2_dma_sg_put_userptr()) and getting mmap_sem in
put_userptr() introduces a lock inversion with queue->mmap_lock in the
above mentioned call path.
Luckily this whole locking mess will get resolved once we convert
videobuf2 core to the new mm helper which avoids the need for mmap_sem
in .put_userptr memop altogether.
Signed-off-by: Jan Kara
---
drivers/media/v4l2-core/videobuf2-core.c | 2 --
drivers/media/v4l2-core/videobuf2-dma-contig.c | 5 +
drivers/media/v4l2-core/videobuf2-dma-sg.c | 4
drivers/media/v4l2-core/videobuf2-vmalloc.c| 4 +++-
4 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 93b315459098..4df6dfc47fc8 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1675,9 +1675,7 @@ static int __buf_prepare(struct vb2_buffer *vb, const
struct v4l2_buffer *b)
ret = __qbuf_mmap(vb, b);
break;
case V4L2_MEMORY_USERPTR:
- down_read(¤t->mm->mmap_sem);
ret = __qbuf_userptr(vb, b);
- up_read(¤t->mm->mmap_sem);
break;
case V4L2_MEMORY_DMABUF:
ret = __qbuf_dmabuf(vb, b);
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 94c1e6455d36..c548ce425701 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -616,6 +616,7 @@ static void *vb2_dc_get_userptr(void *alloc_ctx, unsigned
long vaddr,
goto fail_buf;
}
+ down_read(¤t->mm->mmap_sem);
/* current->mm->mmap_sem is taken by videobuf2 core */
vma = find_vma(current->mm, vaddr);
if (!vma) {
@@ -642,6 +643,7 @@ static void *vb2_dc_get_userptr(void *alloc_ctx, unsigned
long vaddr,
if (ret) {
unsigned long pfn;
if (vb2_dc_get_user_pfn(start, n_pages, vma, &pfn) == 0) {
+ up_read(¤t->mm->mmap_sem);
buf->dma_addr = vb2_dc_pfn_to_dma(buf->dev, pfn);
buf->size = size;
kfree(pages);
@@ -651,6 +653,7 @@ static void *vb2_dc_get_userptr(void *alloc_ctx, unsigned
long vaddr,
pr_err("failed to get user pages\n");
goto fail_vma;
}
+ up_read(¤t->mm->mmap_sem);
sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
if (!sgt) {
@@ -713,10 +716,12 @@ fail_get_user_pages:
while (n_pages)
put_page(pages[--n_pages]);
+ down_read(¤t->mm->mmap_sem);
fail_vma:
vb2_put_vma(buf->vma);
fail_pages:
+ up_read(¤t->mm->mmap_sem);
kfree(pages); /* kfree is NULL-proof */
fail_buf:
diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index 7289b81bd7b7..d2cf113d1933 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -264,6 +264,7 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx,
unsigned long vaddr,
if (!buf->pages)
goto userptr_fail_alloc_pages;
+ down_read(¤t->mm->mmap_sem);
vma = find_vma(current->mm, vaddr);
if (!vma) {
dprintk(1, "no vma for address %lu\n", vaddr);
@@ -302,6 +303,7 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx,
unsigned long vaddr,
1, /* force */
buf->pages,
NULL);
+ up_read(¤t->mm->mmap_sem);
if (num_pages_from_user != buf->num_pages)
goto userptr_fail_get_user_pages;
@@ -331,8 +333,10 @@ userptr_fail_get_user_pages:
if (!vma_is_io(buf->vma))
while (--num_pages_from_user >= 0)
put_page(buf->pages[num_pages_from_user]);
+ down_read(¤t->mm->mmap_sem);
vb2_put_vma(buf->vma);
userptr_fail_find_vma:
+ up_read(¤t->mm->mmap_sem);
kfree(buf->pages);
userptr_fail_alloc_pages:
kfree(buf);
diff --git a/dr
[PATCH 3/9] media: omap_vout: Convert omap_vout_uservirt_to_phys() to use get_vaddr_pfns()
From: Jan Kara
Convert omap_vout_uservirt_to_phys() to use get_vaddr_pfns() instead of
hand made mapping of virtual address to physical address. Also the
function leaked page reference from get_user_pages() so fix that by
properly release the reference when omap_vout_buffer_release() is
called.
Signed-off-by: Jan Kara
---
drivers/media/platform/omap/Kconfig | 1 +
drivers/media/platform/omap/omap_vout.c | 67 +++--
2 files changed, 32 insertions(+), 36 deletions(-)
diff --git a/drivers/media/platform/omap/Kconfig
b/drivers/media/platform/omap/Kconfig
index dc2aaab54aef..217d613b0fe7 100644
--- a/drivers/media/platform/omap/Kconfig
+++ b/drivers/media/platform/omap/Kconfig
@@ -10,6 +10,7 @@ config VIDEO_OMAP2_VOUT
select OMAP2_DSS if HAS_IOMEM && ARCH_OMAP2PLUS
select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
select VIDEO_OMAP2_VOUT_VRFB if VIDEO_OMAP2_VOUT && OMAP2_VRFB
+ select FRAME_VECTOR
default n
---help---
V4L2 Display driver support for OMAP2/3 based boards.
diff --git a/drivers/media/platform/omap/omap_vout.c
b/drivers/media/platform/omap/omap_vout.c
index f09c5f17a42f..b0dad941f7cb 100644
--- a/drivers/media/platform/omap/omap_vout.c
+++ b/drivers/media/platform/omap/omap_vout.c
@@ -195,46 +195,34 @@ static int omap_vout_try_format(struct v4l2_pix_format
*pix)
}
/*
- * omap_vout_uservirt_to_phys: This inline function is used to convert user
- * space virtual address to physical address.
+ * omap_vout_get_userptr: Convert user space virtual address to physical
+ * address.
*/
-static unsigned long omap_vout_uservirt_to_phys(unsigned long virtp)
+static int omap_vout_get_userptr(struct videobuf_buffer *vb, u32 virtp,
+u32 *physp)
{
- unsigned long physp = 0;
- struct vm_area_struct *vma;
- struct mm_struct *mm = current->mm;
+ struct frame_vector *vec;
+ int ret;
/* For kernel direct-mapped memory, take the easy way */
- if (virtp >= PAGE_OFFSET)
- return virt_to_phys((void *) virtp);
-
- down_read(¤t->mm->mmap_sem);
- vma = find_vma(mm, virtp);
- if (vma && (vma->vm_flags & VM_IO) && vma->vm_pgoff) {
- /* this will catch, kernel-allocated, mmaped-to-usermode
- addresses */
- physp = (vma->vm_pgoff << PAGE_SHIFT) + (virtp - vma->vm_start);
- up_read(¤t->mm->mmap_sem);
- } else {
- /* otherwise, use get_user_pages() for general userland pages */
- int res, nr_pages = 1;
- struct page *pages;
+ if (virtp >= PAGE_OFFSET) {
+ *physp = virt_to_phys((void *)virtp);
+ return 0;
+ }
- res = get_user_pages(current, current->mm, virtp, nr_pages, 1,
- 0, &pages, NULL);
- up_read(¤t->mm->mmap_sem);
+ vec = frame_vector_create(1);
+ if (!vec)
+ return -ENOMEM;
- if (res == nr_pages) {
- physp = __pa(page_address(&pages[0]) +
- (virtp & ~PAGE_MASK));
- } else {
- printk(KERN_WARNING VOUT_NAME
- "get_user_pages failed\n");
- return 0;
- }
+ ret = get_vaddr_frames(virtp, 1, true, false, vec);
+ if (ret != 1) {
+ frame_vector_destroy(vec);
+ return -EINVAL;
}
+ *physp = __pfn_to_phys(frame_vector_pfns(vec)[0]);
+ vb->priv = vec;
- return physp;
+ return 0;
}
/*
@@ -784,11 +772,15 @@ static int omap_vout_buffer_prepare(struct videobuf_queue
*q,
* address of the buffer
*/
if (V4L2_MEMORY_USERPTR == vb->memory) {
+ int ret;
+
if (0 == vb->baddr)
return -EINVAL;
/* Physical address */
- vout->queued_buf_addr[vb->i] = (u8 *)
- omap_vout_uservirt_to_phys(vb->baddr);
+ ret = omap_vout_get_userptr(vb, vb->baddr,
+ (u32 *)&vout->queued_buf_addr[vb->i]);
+ if (ret < 0)
+ return ret;
} else {
unsigned long addr, dma_addr;
unsigned long size;
@@ -837,9 +829,12 @@ static void omap_vout_buffer_release(struct videobuf_queue
*q,
struct omap_vout_device *vout = q->priv_data;
vb->state = VIDEOBUF_NEEDS_INIT;
+ if (vb->memory == V4L2_MEMORY_USERPTR && vb->priv) {
+ struct frame_vector *vec = vb->priv;
- if (V4L2_MEMORY_MMAP != vout->memory)
- return;
+ put_vaddr_frames(vec);
+ frame_vector_destroy(vec);
+ }
}
/*
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-sams
[PATCH 7/9] media: vb2: Convert vb2_dc_get_userptr() to use frame vector
From: Jan Kara
Convert vb2_dc_get_userptr() to use frame vector infrastructure. When we
are doing that there's no need to allocate page array and some code can
be simplified.
Acked-by: Marek Szyprowski
Tested-by: Marek Szyprowski
Signed-off-by: Jan Kara
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 212 -
1 file changed, 34 insertions(+), 178 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index c548ce425701..2397ceb1dc6b 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -32,15 +32,13 @@ struct vb2_dc_buf {
dma_addr_t dma_addr;
enum dma_data_direction dma_dir;
struct sg_table *dma_sgt;
+ struct frame_vector *vec;
/* MMAP related */
struct vb2_vmarea_handler handler;
atomic_trefcount;
struct sg_table *sgt_base;
- /* USERPTR related */
- struct vm_area_struct *vma;
-
/* DMABUF related */
struct dma_buf_attachment *db_attach;
};
@@ -49,24 +47,6 @@ struct vb2_dc_buf {
/*scatterlist table functions*/
/*/
-
-static void vb2_dc_sgt_foreach_page(struct sg_table *sgt,
- void (*cb)(struct page *pg))
-{
- struct scatterlist *s;
- unsigned int i;
-
- for_each_sg(sgt->sgl, s, sgt->orig_nents, i) {
- struct page *page = sg_page(s);
- unsigned int n_pages = PAGE_ALIGN(s->offset + s->length)
- >> PAGE_SHIFT;
- unsigned int j;
-
- for (j = 0; j < n_pages; ++j, ++page)
- cb(page);
- }
-}
-
static unsigned long vb2_dc_get_contiguous_size(struct sg_table *sgt)
{
struct scatterlist *s;
@@ -429,92 +409,12 @@ static struct dma_buf *vb2_dc_get_dmabuf(void *buf_priv,
unsigned long flags)
/* callbacks for USERPTR buffers */
/*/
-static inline int vma_is_io(struct vm_area_struct *vma)
-{
- return !!(vma->vm_flags & (VM_IO | VM_PFNMAP));
-}
-
-static int vb2_dc_get_user_pfn(unsigned long start, int n_pages,
- struct vm_area_struct *vma, unsigned long *res)
-{
- unsigned long pfn, start_pfn, prev_pfn;
- unsigned int i;
- int ret;
-
- if (!vma_is_io(vma))
- return -EFAULT;
-
- ret = follow_pfn(vma, start, &pfn);
- if (ret)
- return ret;
-
- start_pfn = pfn;
- start += PAGE_SIZE;
-
- for (i = 1; i < n_pages; ++i, start += PAGE_SIZE) {
- prev_pfn = pfn;
- ret = follow_pfn(vma, start, &pfn);
-
- if (ret) {
- pr_err("no page for address %lu\n", start);
- return ret;
- }
- if (pfn != prev_pfn + 1)
- return -EINVAL;
- }
-
- *res = start_pfn;
- return 0;
-}
-
-static int vb2_dc_get_user_pages(unsigned long start, struct page **pages,
- int n_pages, struct vm_area_struct *vma,
- enum dma_data_direction dma_dir)
-{
- if (vma_is_io(vma)) {
- unsigned int i;
-
- for (i = 0; i < n_pages; ++i, start += PAGE_SIZE) {
- unsigned long pfn;
- int ret = follow_pfn(vma, start, &pfn);
-
- if (!pfn_valid(pfn))
- return -EINVAL;
-
- if (ret) {
- pr_err("no page for address %lu\n", start);
- return ret;
- }
- pages[i] = pfn_to_page(pfn);
- }
- } else {
- int n;
-
- n = get_user_pages(current, current->mm, start & PAGE_MASK,
- n_pages, dma_dir == DMA_FROM_DEVICE, 1, pages, NULL);
- /* negative error means that no page was pinned */
- n = max(n, 0);
- if (n != n_pages) {
- pr_err("got only %d of %d user pages\n", n, n_pages);
- while (n)
- put_page(pages[--n]);
- return -EFAULT;
- }
- }
-
- return 0;
-}
-
-static void vb2_dc_put_dirty_page(struct page *page)
-{
- set_page_dirty_lock(page);
- put_page(page);
-}
-
static void vb2_dc_put_userptr(void *buf_priv)
{
struct vb2_dc_buf *buf = buf_priv;
struct sg_table *sgt = buf->dma_sgt;
+ int i;
+ struct page **pages;
if (sgt) {
DEFINE_DMA_ATTRS(attrs);
@@ -526,13 +426,15 @@ static void vb2_dc_put_userptr(void *buf_priv)
*/
dma_unmap_sg
[PATCH 4/9] vb2: Provide helpers for mapping virtual addresses
From: Jan Kara
Provide simple helper functions to map virtual address range into an
array of pfns / pages.
Acked-by: Marek Szyprowski
Tested-by: Marek Szyprowski
Signed-off-by: Jan Kara
---
drivers/media/v4l2-core/Kconfig| 1 +
drivers/media/v4l2-core/videobuf2-memops.c | 58 ++
include/media/videobuf2-memops.h | 5 +++
3 files changed, 64 insertions(+)
diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
index b4b022933e29..82876a67f144 100644
--- a/drivers/media/v4l2-core/Kconfig
+++ b/drivers/media/v4l2-core/Kconfig
@@ -84,6 +84,7 @@ config VIDEOBUF2_CORE
config VIDEOBUF2_MEMOPS
tristate
+ select FRAME_VECTOR
config VIDEOBUF2_DMA_CONTIG
tristate
diff --git a/drivers/media/v4l2-core/videobuf2-memops.c
b/drivers/media/v4l2-core/videobuf2-memops.c
index 81c1ad8b2cf1..0ec186d41b9b 100644
--- a/drivers/media/v4l2-core/videobuf2-memops.c
+++ b/drivers/media/v4l2-core/videobuf2-memops.c
@@ -137,6 +137,64 @@ int vb2_get_contig_userptr(unsigned long vaddr, unsigned
long size,
EXPORT_SYMBOL_GPL(vb2_get_contig_userptr);
/**
+ * vb2_create_framevec() - map virtual addresses to pfns
+ * @start: Virtual user address where we start mapping
+ * @length:Length of a range to map
+ * @write: Should we map for writing into the area
+ *
+ * This function allocates and fills in a vector with pfns corresponding to
+ * virtual address range passed in arguments. If pfns have corresponding pages,
+ * page references are also grabbed to pin pages in memory. The function
+ * returns pointer to the vector on success and error pointer in case of
+ * failure. Returned vector needs to be freed via vb2_destroy_pfnvec().
+ */
+struct frame_vector *vb2_create_framevec(unsigned long start,
+unsigned long length,
+bool write)
+{
+ int ret;
+ unsigned long first, last;
+ unsigned long nr;
+ struct frame_vector *vec;
+
+ first = start >> PAGE_SHIFT;
+ last = (start + length - 1) >> PAGE_SHIFT;
+ nr = last - first + 1;
+ vec = frame_vector_create(nr);
+ if (!vec)
+ return ERR_PTR(-ENOMEM);
+ ret = get_vaddr_frames(start, nr, write, 1, vec);
+ if (ret < 0)
+ goto out_destroy;
+ /* We accept only complete set of PFNs */
+ if (ret != nr) {
+ ret = -EFAULT;
+ goto out_release;
+ }
+ return vec;
+out_release:
+ put_vaddr_frames(vec);
+out_destroy:
+ frame_vector_destroy(vec);
+ return ERR_PTR(ret);
+}
+EXPORT_SYMBOL(vb2_create_framevec);
+
+/**
+ * vb2_destroy_framevec() - release vector of mapped pfns
+ * @vec: vector of pfns / pages to release
+ *
+ * This releases references to all pages in the vector @vec (if corresponding
+ * pfns are backed by pages) and frees the passed vector.
+ */
+void vb2_destroy_framevec(struct frame_vector *vec)
+{
+ put_vaddr_frames(vec);
+ frame_vector_destroy(vec);
+}
+EXPORT_SYMBOL(vb2_destroy_framevec);
+
+/**
* vb2_common_vm_open() - increase refcount of the vma
* @vma: virtual memory region for the mapping
*
diff --git a/include/media/videobuf2-memops.h b/include/media/videobuf2-memops.h
index f05444ca8c0c..2f0564ff5f31 100644
--- a/include/media/videobuf2-memops.h
+++ b/include/media/videobuf2-memops.h
@@ -15,6 +15,7 @@
#define _MEDIA_VIDEOBUF2_MEMOPS_H
#include
+#include
/**
* vb2_vmarea_handler - common vma refcount tracking handler
@@ -36,5 +37,9 @@ int vb2_get_contig_userptr(unsigned long vaddr, unsigned long
size,
struct vm_area_struct *vb2_get_vma(struct vm_area_struct *vma);
void vb2_put_vma(struct vm_area_struct *vma);
+struct frame_vector *vb2_create_framevec(unsigned long start,
+unsigned long length,
+bool write);
+void vb2_destroy_framevec(struct frame_vector *vec);
#endif
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/9] media: vb2: Convert vb2_dma_sg_get_userptr() to use frame vector
From: Jan Kara
Acked-by: Marek Szyprowski
Tested-by: Marek Szyprowski
Signed-off-by: Jan Kara
---
drivers/media/v4l2-core/videobuf2-dma-sg.c | 95 +-
1 file changed, 15 insertions(+), 80 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index d2cf113d1933..be7bd6535c9d 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -38,6 +38,7 @@ struct vb2_dma_sg_buf {
struct device *dev;
void*vaddr;
struct page **pages;
+ struct frame_vector *vec;
int offset;
enum dma_data_direction dma_dir;
struct sg_table sg_table;
@@ -51,7 +52,6 @@ struct vb2_dma_sg_buf {
unsigned intnum_pages;
atomic_trefcount;
struct vb2_vmarea_handler handler;
- struct vm_area_struct *vma;
struct dma_buf_attachment *db_attach;
};
@@ -225,25 +225,17 @@ static void vb2_dma_sg_finish(void *buf_priv)
dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->nents, buf->dma_dir);
}
-static inline int vma_is_io(struct vm_area_struct *vma)
-{
- return !!(vma->vm_flags & (VM_IO | VM_PFNMAP));
-}
-
static void *vb2_dma_sg_get_userptr(void *alloc_ctx, unsigned long vaddr,
unsigned long size,
enum dma_data_direction dma_dir)
{
struct vb2_dma_sg_conf *conf = alloc_ctx;
struct vb2_dma_sg_buf *buf;
- unsigned long first, last;
- int num_pages_from_user;
- struct vm_area_struct *vma;
struct sg_table *sgt;
DEFINE_DMA_ATTRS(attrs);
+ struct frame_vector *vec;
dma_set_attr(DMA_ATTR_SKIP_CPU_SYNC, &attrs);
-
buf = kzalloc(sizeof *buf, GFP_KERNEL);
if (!buf)
return NULL;
@@ -254,63 +246,19 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx,
unsigned long vaddr,
buf->offset = vaddr & ~PAGE_MASK;
buf->size = size;
buf->dma_sgt = &buf->sg_table;
+ vec = vb2_create_framevec(vaddr, size, buf->dma_dir == DMA_FROM_DEVICE);
+ if (IS_ERR(vec))
+ goto userptr_fail_pfnvec;
+ buf->vec = vec;
- first = (vaddr & PAGE_MASK) >> PAGE_SHIFT;
- last = ((vaddr + size - 1) & PAGE_MASK) >> PAGE_SHIFT;
- buf->num_pages = last - first + 1;
-
- buf->pages = kzalloc(buf->num_pages * sizeof(struct page *),
-GFP_KERNEL);
- if (!buf->pages)
- goto userptr_fail_alloc_pages;
-
- down_read(¤t->mm->mmap_sem);
- vma = find_vma(current->mm, vaddr);
- if (!vma) {
- dprintk(1, "no vma for address %lu\n", vaddr);
- goto userptr_fail_find_vma;
- }
-
- if (vma->vm_end < vaddr + size) {
- dprintk(1, "vma at %lu is too small for %lu bytes\n",
- vaddr, size);
- goto userptr_fail_find_vma;
- }
-
- buf->vma = vb2_get_vma(vma);
- if (!buf->vma) {
- dprintk(1, "failed to copy vma\n");
- goto userptr_fail_find_vma;
- }
-
- if (vma_is_io(buf->vma)) {
- for (num_pages_from_user = 0;
-num_pages_from_user < buf->num_pages;
-++num_pages_from_user, vaddr += PAGE_SIZE) {
- unsigned long pfn;
-
- if (follow_pfn(vma, vaddr, &pfn)) {
- dprintk(1, "no page for address %lu\n", vaddr);
- break;
- }
- buf->pages[num_pages_from_user] = pfn_to_page(pfn);
- }
- } else
- num_pages_from_user = get_user_pages(current, current->mm,
-vaddr & PAGE_MASK,
-buf->num_pages,
-buf->dma_dir == DMA_FROM_DEVICE,
-1, /* force */
-buf->pages,
-NULL);
- up_read(¤t->mm->mmap_sem);
-
- if (num_pages_from_user != buf->num_pages)
- goto userptr_fail_get_user_pages;
+ buf->pages = frame_vector_pages(vec);
+ if (IS_ERR(buf->pages))
+ goto userptr_fail_sgtable;
+ buf->num_pages = frame_vector_count(vec);
if (sg_alloc_table_from_pages(buf->dma_sgt, buf->pages,
buf->num_pages, buf->offset, size, 0))
- goto userptr_fail_alloc_table_from_pages;
+ goto userptr_fail_sgtable;
sgt = &buf->sg_table;
/*
@@ -326,19 +274
[PATCH 9/9] drm/exynos: Convert g2d_userptr_get_dma_addr() to use get_vaddr_frames()
From: Jan Kara
Convert g2d_userptr_get_dma_addr() to pin pages using get_vaddr_frames().
This removes the knowledge about vmas and mmap_sem locking from exynos
driver. Also it fixes a problem that the function has been mapping user
provided address without holding mmap_sem.
Signed-off-by: Jan Kara
---
drivers/gpu/drm/exynos/Kconfig | 1 +
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 91 ++-
drivers/gpu/drm/exynos/exynos_drm_gem.c | 97 -
3 files changed, 30 insertions(+), 159 deletions(-)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 43003c4ad80b..b364562dc6c1 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -77,6 +77,7 @@ config DRM_EXYNOS_VIDI
config DRM_EXYNOS_G2D
bool "Exynos DRM G2D"
depends on DRM_EXYNOS && !VIDEO_SAMSUNG_S5P_G2D
+ select FRAME_VECTOR
help
Choose this option if you want to use Exynos G2D for DRM.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 81a250830808..1d8d9a508373 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -190,10 +190,8 @@ struct g2d_cmdlist_userptr {
dma_addr_t dma_addr;
unsigned long userptr;
unsigned long size;
- struct page **pages;
- unsigned intnpages;
+ struct frame_vector *vec;
struct sg_table *sgt;
- struct vm_area_struct *vma;
atomic_trefcount;
boolin_pool;
boolout_of_list;
@@ -363,6 +361,7 @@ static void g2d_userptr_put_dma_addr(struct drm_device
*drm_dev,
{
struct g2d_cmdlist_userptr *g2d_userptr =
(struct g2d_cmdlist_userptr *)obj;
+ struct page **pages;
if (!obj)
return;
@@ -382,19 +381,21 @@ out:
exynos_gem_unmap_sgt_from_dma(drm_dev, g2d_userptr->sgt,
DMA_BIDIRECTIONAL);
- exynos_gem_put_pages_to_userptr(g2d_userptr->pages,
- g2d_userptr->npages,
- g2d_userptr->vma);
+ pages = frame_vector_pages(g2d_userptr->vec);
+ if (!IS_ERR(pages)) {
+ int i;
- exynos_gem_put_vma(g2d_userptr->vma);
+ for (i = 0; i < frame_vector_count(g2d_userptr->vec); i++)
+ set_page_dirty_lock(pages[i]);
+ }
+ put_vaddr_frames(g2d_userptr->vec);
+ frame_vector_destroy(g2d_userptr->vec);
if (!g2d_userptr->out_of_list)
list_del_init(&g2d_userptr->list);
sg_free_table(g2d_userptr->sgt);
kfree(g2d_userptr->sgt);
-
- drm_free_large(g2d_userptr->pages);
kfree(g2d_userptr);
}
@@ -408,9 +409,7 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct
drm_device *drm_dev,
struct exynos_drm_g2d_private *g2d_priv = file_priv->g2d_priv;
struct g2d_cmdlist_userptr *g2d_userptr;
struct g2d_data *g2d;
- struct page **pages;
struct sg_table *sgt;
- struct vm_area_struct *vma;
unsigned long start, end;
unsigned int npages, offset;
int ret;
@@ -456,65 +455,38 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct
drm_device *drm_dev,
return ERR_PTR(-ENOMEM);
atomic_set(&g2d_userptr->refcount, 1);
+ g2d_userptr->size = size;
start = userptr & PAGE_MASK;
offset = userptr & ~PAGE_MASK;
end = PAGE_ALIGN(userptr + size);
npages = (end - start) >> PAGE_SHIFT;
- g2d_userptr->npages = npages;
-
- pages = drm_calloc_large(npages, sizeof(struct page *));
- if (!pages) {
- DRM_ERROR("failed to allocate pages.\n");
- ret = -ENOMEM;
+ g2d_userptr->vec = frame_vector_create(npages);
+ if (!g2d_userptr->vec)
goto err_free;
- }
- down_read(¤t->mm->mmap_sem);
- vma = find_vma(current->mm, userptr);
- if (!vma) {
- up_read(¤t->mm->mmap_sem);
- DRM_ERROR("failed to get vm region.\n");
+ ret = get_vaddr_frames(start, npages, true, true, g2d_userptr->vec);
+ if (ret != npages) {
+ DRM_ERROR("failed to get user pages from userptr.\n");
+ if (ret < 0)
+ goto err_destroy_framevec;
ret = -EFAULT;
- goto err_free_pages;
+ goto err_put_framevec;
}
-
- if (vma->vm_end < userptr + size) {
- up_read(¤t->mm->mmap_sem);
- DRM_ERROR("vma is too small.\n");
+ if (frame_vector_to_pages(g2d_userptr->vec) < 0) {
ret = -EFAULT;
- goto err_free_pages;
+
[PATCH 2/9] mm: Provide new get_vaddr_frames() helper
From: Jan Kara
Provide new function get_vaddr_frames(). This function maps virtual
addresses from given start and fills given array with page frame numbers of
the corresponding pages. If given start belongs to a normal vma, the function
grabs reference to each of the pages to pin them in memory. If start
belongs to VM_IO | VM_PFNMAP vma, we don't touch page structures. Caller
must make sure pfns aren't reused for anything else while he is using
them.
This function is created for various drivers to simplify handling of
their buffers.
Acked-by: Mel Gorman
Acked-by: Vlastimil Babka
Signed-off-by: Jan Kara
---
include/linux/mm.h | 44 ++
mm/Kconfig | 3 +
mm/Makefile| 1 +
mm/frame_vector.c | 231 +
4 files changed, 279 insertions(+)
create mode 100644 mm/frame_vector.c
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 2e872f92dbac..79ad29a8a60a 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
struct mempolicy;
struct anon_vma;
@@ -1198,6 +1199,49 @@ long get_user_pages_unlocked(struct task_struct *tsk,
struct mm_struct *mm,
int write, int force, struct page **pages);
int get_user_pages_fast(unsigned long start, int nr_pages, int write,
struct page **pages);
+
+/* Container for pinned pfns / pages */
+struct frame_vector {
+ unsigned int nr_allocated; /* Number of frames we have space for */
+ unsigned int nr_frames; /* Number of frames stored in ptrs array */
+ bool got_ref; /* Did we pin pages by getting page ref? */
+ bool is_pfns; /* Does array contain pages or pfns? */
+ void *ptrs[0]; /* Array of pinned pfns / pages. Use
+* pfns_vector_pages() or pfns_vector_pfns()
+* for access */
+};
+
+struct frame_vector *frame_vector_create(unsigned int nr_frames);
+void frame_vector_destroy(struct frame_vector *vec);
+int get_vaddr_frames(unsigned long start, unsigned int nr_pfns,
+bool write, bool force, struct frame_vector *vec);
+void put_vaddr_frames(struct frame_vector *vec);
+int frame_vector_to_pages(struct frame_vector *vec);
+void frame_vector_to_pfns(struct frame_vector *vec);
+
+static inline unsigned int frame_vector_count(struct frame_vector *vec)
+{
+ return vec->nr_frames;
+}
+
+static inline struct page **frame_vector_pages(struct frame_vector *vec)
+{
+ if (vec->is_pfns) {
+ int err = frame_vector_to_pages(vec);
+
+ if (err)
+ return ERR_PTR(err);
+ }
+ return (struct page **)(vec->ptrs);
+}
+
+static inline unsigned long *frame_vector_pfns(struct frame_vector *vec)
+{
+ if (!vec->is_pfns)
+ frame_vector_to_pfns(vec);
+ return (unsigned long *)(vec->ptrs);
+}
+
struct kvec;
int get_kernel_pages(const struct kvec *iov, int nr_pages, int write,
struct page **pages);
diff --git a/mm/Kconfig b/mm/Kconfig
index e79de2bd12cd..7f146dd32fc5 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -654,3 +654,6 @@ config DEFERRED_STRUCT_PAGE_INIT
when kswapd starts. This has a potential performance impact on
processes running early in the lifetime of the systemm until kswapd
finishes the initialisation.
+
+config FRAME_VECTOR
+ bool
diff --git a/mm/Makefile b/mm/Makefile
index 98c4eaeabdcb..be5d5c866305 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -78,3 +78,4 @@ obj-$(CONFIG_CMA) += cma.o
obj-$(CONFIG_MEMORY_BALLOON) += balloon_compaction.o
obj-$(CONFIG_PAGE_EXTENSION) += page_ext.o
obj-$(CONFIG_CMA_DEBUGFS) += cma_debug.o
+obj-$(CONFIG_FRAME_VECTOR) += frame_vector.o
diff --git a/mm/frame_vector.c b/mm/frame_vector.c
new file mode 100644
index ..f76b579e46f1
--- /dev/null
+++ b/mm/frame_vector.c
@@ -0,0 +1,231 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * get_vaddr_frames() - map virtual addresses to pfns
+ * @start: starting user address
+ * @nr_frames: number of pages / pfns from start to map
+ * @write: whether pages will be written to by the caller
+ * @force: whether to force write access even if user mapping is
+ * readonly. See description of the same argument of
+ get_user_pages().
+ * @vec: structure which receives pages / pfns of the addresses mapped.
+ * It should have space for at least nr_frames entries.
+ *
+ * This function maps virtual addresses from @start and fills @vec structure
+ * with page frame numbers or page pointers to corresponding pages (choice
+ * depends on the type of the vma underlying the virtual address). If @start
+ * belongs to a normal vma, the function grabs reference to each of the pages
+ * to pin them in memory. If @start belong
[PATCH 8/9] media: vb2: Remove unused functions
From: Jan Kara
Conversion to the use of pinned pfns made some functions unused. Remove
them. Also there's no need to lock mmap_sem in __buf_prepare() anymore.
Acked-by: Marek Szyprowski
Tested-by: Marek Szyprowski
Signed-off-by: Jan Kara
---
drivers/media/v4l2-core/videobuf2-memops.c | 114 -
include/media/videobuf2-memops.h | 6 --
2 files changed, 120 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-memops.c
b/drivers/media/v4l2-core/videobuf2-memops.c
index 0ec186d41b9b..48c6a49c4928 100644
--- a/drivers/media/v4l2-core/videobuf2-memops.c
+++ b/drivers/media/v4l2-core/videobuf2-memops.c
@@ -23,120 +23,6 @@
#include
/**
- * vb2_get_vma() - acquire and lock the virtual memory area
- * @vma: given virtual memory area
- *
- * This function attempts to acquire an area mapped in the userspace for
- * the duration of a hardware operation. The area is "locked" by performing
- * the same set of operation that are done when process calls fork() and
- * memory areas are duplicated.
- *
- * Returns a copy of a virtual memory region on success or NULL.
- */
-struct vm_area_struct *vb2_get_vma(struct vm_area_struct *vma)
-{
- struct vm_area_struct *vma_copy;
-
- vma_copy = kmalloc(sizeof(*vma_copy), GFP_KERNEL);
- if (vma_copy == NULL)
- return NULL;
-
- if (vma->vm_ops && vma->vm_ops->open)
- vma->vm_ops->open(vma);
-
- if (vma->vm_file)
- get_file(vma->vm_file);
-
- memcpy(vma_copy, vma, sizeof(*vma));
-
- vma_copy->vm_mm = NULL;
- vma_copy->vm_next = NULL;
- vma_copy->vm_prev = NULL;
-
- return vma_copy;
-}
-EXPORT_SYMBOL_GPL(vb2_get_vma);
-
-/**
- * vb2_put_userptr() - release a userspace virtual memory area
- * @vma: virtual memory region associated with the area to be released
- *
- * This function releases the previously acquired memory area after a hardware
- * operation.
- */
-void vb2_put_vma(struct vm_area_struct *vma)
-{
- if (!vma)
- return;
-
- if (vma->vm_ops && vma->vm_ops->close)
- vma->vm_ops->close(vma);
-
- if (vma->vm_file)
- fput(vma->vm_file);
-
- kfree(vma);
-}
-EXPORT_SYMBOL_GPL(vb2_put_vma);
-
-/**
- * vb2_get_contig_userptr() - lock physically contiguous userspace mapped
memory
- * @vaddr: starting virtual address of the area to be verified
- * @size: size of the area
- * @res_paddr: will return physical address for the given vaddr
- * @res_vma: will return locked copy of struct vm_area for the given area
- *
- * This function will go through memory area of size @size mapped at @vaddr and
- * verify that the underlying physical pages are contiguous. If they are
- * contiguous the virtual memory area is locked and a @res_vma is filled with
- * the copy and @res_pa set to the physical address of the buffer.
- *
- * Returns 0 on success.
- */
-int vb2_get_contig_userptr(unsigned long vaddr, unsigned long size,
- struct vm_area_struct **res_vma, dma_addr_t *res_pa)
-{
- struct mm_struct *mm = current->mm;
- struct vm_area_struct *vma;
- unsigned long offset, start, end;
- unsigned long this_pfn, prev_pfn;
- dma_addr_t pa = 0;
-
- start = vaddr;
- offset = start & ~PAGE_MASK;
- end = start + size;
-
- vma = find_vma(mm, start);
-
- if (vma == NULL || vma->vm_end < end)
- return -EFAULT;
-
- for (prev_pfn = 0; start < end; start += PAGE_SIZE) {
- int ret = follow_pfn(vma, start, &this_pfn);
- if (ret)
- return ret;
-
- if (prev_pfn == 0)
- pa = this_pfn << PAGE_SHIFT;
- else if (this_pfn != prev_pfn + 1)
- return -EFAULT;
-
- prev_pfn = this_pfn;
- }
-
- /*
-* Memory is contigous, lock vma and return to the caller
-*/
- *res_vma = vb2_get_vma(vma);
- if (*res_vma == NULL)
- return -ENOMEM;
-
- *res_pa = pa + offset;
- return 0;
-}
-EXPORT_SYMBOL_GPL(vb2_get_contig_userptr);
-
-/**
* vb2_create_framevec() - map virtual addresses to pfns
* @start: Virtual user address where we start mapping
* @length:Length of a range to map
diff --git a/include/media/videobuf2-memops.h b/include/media/videobuf2-memops.h
index 2f0564ff5f31..830b5239fd8b 100644
--- a/include/media/videobuf2-memops.h
+++ b/include/media/videobuf2-memops.h
@@ -31,12 +31,6 @@ struct vb2_vmarea_handler {
extern const struct vm_operations_struct vb2_common_vm_ops;
-int vb2_get_contig_userptr(unsigned long vaddr, unsigned long size,
- struct vm_area_struct **res_vma, dma_addr_t *res_pa);
-
-struct vm_area_struct *vb2_get_vma(struct vm_area_struct *vma);
-void vb2_put_vma(struct vm_area_struct *vma);
-
struct frame_vector *vb2_create_framevec
Re: [PATCH 4/6] ARM: dts: Exynos4210: add CPU OPP and regulator supply property
On Monday, July 13, 2015 01:20:41 PM Bartlomiej Zolnierkiewicz wrote: > On Monday, July 13, 2015 08:10:21 PM Krzysztof Kozlowski wrote: > > 2015-07-13 20:02 GMT+09:00 Bartlomiej Zolnierkiewicz > > : > > > > > > Hi, > > > > > > On Tuesday, June 23, 2015 09:24:40 AM Krzysztof Kozlowski wrote: > > >> On 23.06.2015 08:46, Krzysztof Kozlowski wrote: > > >> > On 23.06.2015 00:04, Michael Turquette wrote: > > >> >> Quoting Kukjin Kim (2015-06-21 18:46:26) > > >> >>> Krzysztof Kozlowski wrote: > > >> > > >> On 22.06.2015 10:38, Kukjin Kim wrote: > > >> > Krzysztof Kozlowski wrote: > > >> >> 2015-05-08 9:18 GMT+09:00 Krzysztof Kozlowski > > >> >> : > > >> >>> 2015-04-04 1:43 GMT+09:00 Bartlomiej Zolnierkiewicz > > >> >>> : > > >> From: Thomas Abraham > > >> > > >> For Exynos4210 platforms, add CPU operating points and CPU > > >> regulator supply properties for migrating from Exynos specific > > >> cpufreq driver to using generic cpufreq driver. > > >> > > >> Changes by Bartlomiej: > > >> - removed Exynos5250 and Exynos5420 support for now > > >> > > >> Cc: Kukjin Kim > > >> Cc: Doug Anderson > > >> Cc: Javier Martinez Canillas > > >> Cc: Andreas Faerber > > >> Cc: Sachin Kamat > > >> Cc: Andreas Farber > > >> Cc: Javier Martinez Canillas > > >> Signed-off-by: Thomas Abraham > > >> Signed-off-by: Bartlomiej Zolnierkiewicz > > >> > > >> >>> > > >> >>> Acked-by: Krzysztof Kozlowski > > >> >> > > >> >> Rebased and applied to my tree, I'll sent it later to Kukjin > > >> >> unless he > > >> >> picks it by himself from LKML. > > >> >> > > >> > Hi, as far as I know, this is for v4.2 not v4.1 so it will be > > >> > applied based on > > >> > v4.2-rc1 after v4.2-rc1 release. > > >> > > >> You mean it is for v4.3, not v4.2? > > >> > > >> >>> Oops, yes v4.3. > > >> >>> > > >> >>> Thanks for the correction. > > >> >> > > >> >> Kukjin & Krzysztof, > > >> >> > > >> >> I'm confused on this point. I was planning to take patches 1, 2, 3, 5 > > >> >> and 6 towards 4.2 (e.g. in the pull request that I'll send out this > > >> >> week). > > >> >> > > >> >> Is patch 4 going out for 4.2 or 4.3? > > >> > > > >> > It is quite late for sending pull request to arm-soc for 4.2. > > >> > For example SoCFPGA pull request from last week was rejected: > > >> > http://comments.gmane.org/gmane.linux.ports.arm.kernel/417980 > > >> > > >> Oh, that was wrong link. Here it is: > > >> http://www.spinics.net/lists/arm-kernel/msg425911.html > > >> > > >> > If you want to take it for 4.2 then I am fine with it but this will > > >> > cause some easy but annoying conflicts. There aren't difficult - just > > >> > most of nodes in board DTS changed their place. > > >> > > > >> > Example of resolution (target file after merge, with cpu nodes > > >> > reordered > > >> > alphabetically): > > >> > https://github.com/krzk/linux/commit/2cec3cb48abaf44848c62f1c0836b772eb4680dd > > > > > > This patch is needed for v4.2 as other changes has been already > > > merged. > > > > > > Krzysztof/Kukjin, could you please take care of it? > > > > Of course! It is already in my queue. I'll send it later to Kukjin for > > 4.3 (unless he picks it also). > > It is in your queue for v4.3 but the patch is needed for v4.2, > without it cpufreq support will not work for Exynos4210 platforms. > > > BTW for other patchsets you still need acks from Samsung clock > > maintainers. Did you poke Sylwester or Tomasz about it? > > Sylwester, please review/ack Samsung specific clock changes in > Exynos5250 cpufreq and Exynos4x12 cpufreq patch series. > > Patch series: > > * [PATCH v3 0/4] cpufreq: use generic cpufreq drivers for Exynos5250 platform > (http://lkml.org/lkml/2015/7/1/311) > > * [PATCH v2 0/7] cpufreq: use generic cpufreq drivers for Exynos4x12 platform > (http://lkml.org/lkml/2015/7/9/419) > > Samsung clock specific changes: > > * [PATCH v3 1/4] clk: samsung: exynos5250: add cpu clock configuration data > and instantiate cpu clock > (http://lkml.org/lkml/2015/7/1/313) > > * [PATCH v2 4/7] clk: samsung: exynos4x12: add cpu clock configuration data > and instantiate cpu clock > (http://lkml.org/lkml/2015/7/9/424) BTW corresponding changes for Exynos4210 has already been merged and 2 above patches are quite obvious so review should be very quick & simple. [ Unfortunately Sylwester is currently very busy with a more priority work so it may still take some time to get his ACKs. ] 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 0/10 v6] Helper to abstract vma handling in media layer
On Mon 13-07-15 10:45:25, Hans Verkuil wrote: > On 07/09/2015 02:12 PM, Hans Verkuil wrote: > > On 07/09/2015 01:48 PM, Jan Kara wrote: > >> Hello, > >> > >> Hans, did you have a chance to look at these patches? I have tested them > >> with the vivid driver but it would be good if you could run them through > >> your standard testing procedure as well. Andrew has updated the patches in > >> his tree but some ack from you would be welcome... > > > > I've planned a 'patch day' for Monday. So hopefully you'll see a pull > > request > > by then. > > OK, I'm confused. I thought the non-vb2 patches would go in for 4.2? That > didn't happen, so I guess the plan is to merge the whole lot for 4.3 via > our media tree? If that's the case, can you post a new patch series on I guess Andrew wasn't sure what to push and what not so he just chose the safe option to not push anything. > top of the master branch of the media tree? I want to make sure I use the > right patches. Also, if you do make a new patch series, then it would be > better if patch 10/10 is folded into patch 2/10. OK, I'll rebase patches on top of media tree. Honza > >> On Thu 18-06-15 16:08:30, Jan Kara wrote: > >>> Hello, > >>> > >>> I'm sending the sixth version of my patch series to abstract vma handling > >>> from > >>> the various media drivers. Since the previous version I have added a > >>> patch to > >>> move mm helpers into a separate file and behind a config option. I also > >>> changed patch pushing mmap_sem down in videobuf2 core to avoid lockdep > >>> warning > >>> and NULL dereference Hans found in his testing. I've also included small > >>> fixups Andrew was carrying. > >>> > >>> After this patch set drivers have to know much less details about vmas, > >>> their > >>> types, and locking. Also quite some code is removed from them. As a bonus > >>> drivers get automatically VM_FAULT_RETRY handling. The primary motivation > >>> for > >>> this series is to remove knowledge about mmap_sem locking from as many > >>> places a > >>> possible so that we can change it with reasonable effort. > >>> > >>> The core of the series is the new helper get_vaddr_frames() which is > >>> given a > >>> virtual address and it fills in PFNs / struct page pointers (depending on > >>> VMA > >>> type) into the provided array. If PFNs correspond to normal pages it also > >>> grabs > >>> references to these pages. The difference from get_user_pages() is that > >>> this > >>> function can also deal with pfnmap, and io mappings which is what the > >>> media > >>> drivers need. > >>> > >>> I have tested the patches with vivid driver so at least vb2 code got some > >>> exposure. Conversion of other drivers was just compile-tested (for x86 so > >>> e.g. > >>> exynos driver which is only for Samsung platform is completely untested). > >>> > >>> Andrew, can you please update the patches in mm three? Thanks! > >>> > >>> Honza > >>> > >>> Changes since v5: > >>> * Moved mm helper into a separate file and behind a config option > >>> * Changed the first patch pushing mmap_sem down in videobuf2 core to avoid > >>> possible deadlock > >>> > >>> Changes since v4: > >>> * Minor cleanups and fixes pointed out by Mel and Vlasta > >>> * Added Acked-by tags > >>> > >>> Changes since v3: > >>> * Added include into mm/gup.c as it's needed for some > >>> archs > >>> * Fixed error path for exynos driver > >>> > >>> Changes since v2: > >>> * Renamed functions and structures as Mel suggested > >>> * Other minor changes suggested by Mel > >>> * Rebased on top of 4.1-rc2 > >>> * Changed functions to get pointer to array of pages / pfns to perform > >>> conversion if necessary. This fixes possible issue in the omap I may > >>> have > >>> introduced in v2 and generally makes the API less errorprone. > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-media" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > -- Jan Kara SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] mfd: Add DT binding for Maxim MAX77802 IC
Hello Sergei,
On 07/13/2015 03:11 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 7/13/2015 10:42 AM, Javier Martinez Canillas wrote:
>
>> The MAX77802 is a chip that contains regulators, 2 32kHz clocks,
>> a RTC and an I2C interface to program the individual components.
>
>> The are already DT bindings for the regulators and clocks and
>> these reference to a bindings/mfd/max77802.txt file, that didn't
>> exist, for the details about the PMIC.
>
>> Signed-off-by: Javier Martinez Canillas
>> ---
>>
>> Documentation/devicetree/bindings/mfd/max77802.txt | 26
>> ++
>> 1 file changed, 26 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/max77802.txt
>
>> diff --git a/Documentation/devicetree/bindings/mfd/max77802.txt
>> b/Documentation/devicetree/bindings/mfd/max77802.txt
>> new file mode 100644
>> index ..875ebebbc5b0
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/max77802.txt
>> @@ -0,0 +1,26 @@
>> +Maxim MAX77802 multi-function device
>> +
>> +The Maxim MAX77802 is a power management chip (PMIC) that contains 10 high
>> +efficiency Buck regulators, 32 Low-dropout (LDO) regulators used to power
>> +up application processors and peripherals, a 2-channel 32kHz clock outputs,
>> +a Real-Time-Clock (RTC) and a I2C interface to program the individual
>> +regulators, clocks outputs and the RTC.
>> +
>> +Binding for the built-in 32k clock generator block is defined separately
>> +in the bindings/clk/maxim,max77802.txt file and binding for the regulators
>> +is defined in the bindings/regulator/max77802.txt file.
>> +
>> +Required properties:
>> +- compatible : Must be "maxim,max77686";
>> +- reg : Specifies the i2c slave address of PMIC block.
>> +- interrupts : This i2c device has an IRQ line connected to the main SoC.
>> +- interrupt-parent : The parent interrupt controller.
>> +
>> +Example:
>> +
>> +max77802@09 {
>
>Sigh, I'm tired of saying this over and over again: please don't name the
> nodes with teh chip names. The ePAPR standard says: "The name of a node
> should be somewhat generic, reflecting the function of the device and not its
> 3 precise programming model."
>
Ok, I'll change this to be pmic@ when re-spinning the patches.
> WBR, Sergei
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] mfd: Add DT binding for Maxim MAX77802 IC
Hello.
On 7/13/2015 10:42 AM, Javier Martinez Canillas wrote:
The MAX77802 is a chip that contains regulators, 2 32kHz clocks,
a RTC and an I2C interface to program the individual components.
The are already DT bindings for the regulators and clocks and
these reference to a bindings/mfd/max77802.txt file, that didn't
exist, for the details about the PMIC.
Signed-off-by: Javier Martinez Canillas
---
Documentation/devicetree/bindings/mfd/max77802.txt | 26 ++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/max77802.txt
diff --git a/Documentation/devicetree/bindings/mfd/max77802.txt
b/Documentation/devicetree/bindings/mfd/max77802.txt
new file mode 100644
index ..875ebebbc5b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/max77802.txt
@@ -0,0 +1,26 @@
+Maxim MAX77802 multi-function device
+
+The Maxim MAX77802 is a power management chip (PMIC) that contains 10 high
+efficiency Buck regulators, 32 Low-dropout (LDO) regulators used to power
+up application processors and peripherals, a 2-channel 32kHz clock outputs,
+a Real-Time-Clock (RTC) and a I2C interface to program the individual
+regulators, clocks outputs and the RTC.
+
+Binding for the built-in 32k clock generator block is defined separately
+in the bindings/clk/maxim,max77802.txt file and binding for the regulators
+is defined in the bindings/regulator/max77802.txt file.
+
+Required properties:
+- compatible : Must be "maxim,max77686";
+- reg : Specifies the i2c slave address of PMIC block.
+- interrupts : This i2c device has an IRQ line connected to the main SoC.
+- interrupt-parent : The parent interrupt controller.
+
+Example:
+
+ max77802@09 {
Sigh, I'm tired of saying this over and over again: please don't name the
nodes with teh chip names. The ePAPR standard says: "The name of a node should
be somewhat generic, reflecting the function of the device and not its 3
precise programming model."
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] ARM: EXYNOS: dts: Fixes for 4.2
Dear Kukjin, These are candidates for fixes during this RC cycle. Description below (under signed tag). Best regards, Krzysztof The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754: Linux 4.2-rc1 (2015-07-05 11:01:52 -0700) are available in the git repository at: https://github.com/krzk/linux.git tags/samsung-dt-fixes-4.2 for you to fetch changes up to a419d78a6f97f8c977fe55d5d590cd0654ecd1ee: ARM: dts: Exynos4210: add CPU OPP and regulator supply property (2015-07-13 21:16:05 +0900) Samsung DTS fixes: 1. Fix Exynos3250 MIPI DSI display and MIPI CSIS-2 camera sensor after adding support for PMU regmap in exynos-video-mipi driver (issue introduced in v4.0). 2. Bring back cpufreq for Exynos4210 after incomplete switch to cpufreq-dt driver in 4.2 merge window. The necessary DTS change for Exynos4210 cpufreq was not applied to the same tree as rest of patchset because of multiple conflicts between clk and arm-soc DTS trees. It was also too late to send it to arm-soc for 4.2. Unfortunately without the change the Exynos4210 boards loose cpufreq feature. Beata Michalska (1): ARM: dts: Update video-phy node with syscon phandle for Exynos3250 Thomas Abraham (1): ARM: dts: Exynos4210: add CPU OPP and regulator supply property arch/arm/boot/dts/exynos3250.dtsi | 2 +- arch/arm/boot/dts/exynos4210-origen.dts | 4 arch/arm/boot/dts/exynos4210-trats.dts | 4 arch/arm/boot/dts/exynos4210-universal_c210.dts | 4 arch/arm/boot/dts/exynos4210.dtsi | 12 5 files changed, 25 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line "unsubscribe linux-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: dts: Exynos4210: add CPU OPP and regulator supply property
2015-07-13 20:20 GMT+09:00 Bartlomiej Zolnierkiewicz : > On Monday, July 13, 2015 08:10:21 PM Krzysztof Kozlowski wrote: >> 2015-07-13 20:02 GMT+09:00 Bartlomiej Zolnierkiewicz >> : >> > >> > Hi, >> > >> > On Tuesday, June 23, 2015 09:24:40 AM Krzysztof Kozlowski wrote: >> >> On 23.06.2015 08:46, Krzysztof Kozlowski wrote: >> >> > On 23.06.2015 00:04, Michael Turquette wrote: >> >> >> Quoting Kukjin Kim (2015-06-21 18:46:26) >> >> >>> Krzysztof Kozlowski wrote: >> >> >> >> On 22.06.2015 10:38, Kukjin Kim wrote: >> >> > Krzysztof Kozlowski wrote: >> >> >> 2015-05-08 9:18 GMT+09:00 Krzysztof Kozlowski >> >> >> : >> >> >>> 2015-04-04 1:43 GMT+09:00 Bartlomiej Zolnierkiewicz >> >> >>> : >> >> From: Thomas Abraham >> >> >> >> For Exynos4210 platforms, add CPU operating points and CPU >> >> regulator supply properties for migrating from Exynos specific >> >> cpufreq driver to using generic cpufreq driver. >> >> >> >> Changes by Bartlomiej: >> >> - removed Exynos5250 and Exynos5420 support for now >> >> >> >> Cc: Kukjin Kim >> >> Cc: Doug Anderson >> >> Cc: Javier Martinez Canillas >> >> Cc: Andreas Faerber >> >> Cc: Sachin Kamat >> >> Cc: Andreas Farber >> >> Cc: Javier Martinez Canillas >> >> Signed-off-by: Thomas Abraham >> >> Signed-off-by: Bartlomiej Zolnierkiewicz >> >> >> >> >>> >> >> >>> Acked-by: Krzysztof Kozlowski >> >> >> >> >> >> Rebased and applied to my tree, I'll sent it later to Kukjin >> >> >> unless he >> >> >> picks it by himself from LKML. >> >> >> >> >> > Hi, as far as I know, this is for v4.2 not v4.1 so it will be >> >> > applied based on >> >> > v4.2-rc1 after v4.2-rc1 release. >> >> >> >> You mean it is for v4.3, not v4.2? >> >> >> >> >>> Oops, yes v4.3. >> >> >>> >> >> >>> Thanks for the correction. >> >> >> >> >> >> Kukjin & Krzysztof, >> >> >> >> >> >> I'm confused on this point. I was planning to take patches 1, 2, 3, 5 >> >> >> and 6 towards 4.2 (e.g. in the pull request that I'll send out this >> >> >> week). >> >> >> >> >> >> Is patch 4 going out for 4.2 or 4.3? >> >> > >> >> > It is quite late for sending pull request to arm-soc for 4.2. >> >> > For example SoCFPGA pull request from last week was rejected: >> >> > http://comments.gmane.org/gmane.linux.ports.arm.kernel/417980 >> >> >> >> Oh, that was wrong link. Here it is: >> >> http://www.spinics.net/lists/arm-kernel/msg425911.html >> >> >> >> > If you want to take it for 4.2 then I am fine with it but this will >> >> > cause some easy but annoying conflicts. There aren't difficult - just >> >> > most of nodes in board DTS changed their place. >> >> > >> >> > Example of resolution (target file after merge, with cpu nodes reordered >> >> > alphabetically): >> >> > https://github.com/krzk/linux/commit/2cec3cb48abaf44848c62f1c0836b772eb4680dd >> > >> > This patch is needed for v4.2 as other changes has been already >> > merged. >> > >> > Krzysztof/Kukjin, could you please take care of it? >> >> Of course! It is already in my queue. I'll send it later to Kukjin for >> 4.3 (unless he picks it also). > > It is in your queue for v4.3 but the patch is needed for v4.2, > without it cpufreq support will not work for Exynos4210 platforms. Hmm... it makes sense to push it during this rc-cycle to bring back crippled feature. 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 4/6] ARM: dts: Exynos4210: add CPU OPP and regulator supply property
On Monday, July 13, 2015 08:10:21 PM Krzysztof Kozlowski wrote: > 2015-07-13 20:02 GMT+09:00 Bartlomiej Zolnierkiewicz > : > > > > Hi, > > > > On Tuesday, June 23, 2015 09:24:40 AM Krzysztof Kozlowski wrote: > >> On 23.06.2015 08:46, Krzysztof Kozlowski wrote: > >> > On 23.06.2015 00:04, Michael Turquette wrote: > >> >> Quoting Kukjin Kim (2015-06-21 18:46:26) > >> >>> Krzysztof Kozlowski wrote: > >> > >> On 22.06.2015 10:38, Kukjin Kim wrote: > >> > Krzysztof Kozlowski wrote: > >> >> 2015-05-08 9:18 GMT+09:00 Krzysztof Kozlowski > >> >> : > >> >>> 2015-04-04 1:43 GMT+09:00 Bartlomiej Zolnierkiewicz > >> >>> : > >> From: Thomas Abraham > >> > >> For Exynos4210 platforms, add CPU operating points and CPU > >> regulator supply properties for migrating from Exynos specific > >> cpufreq driver to using generic cpufreq driver. > >> > >> Changes by Bartlomiej: > >> - removed Exynos5250 and Exynos5420 support for now > >> > >> Cc: Kukjin Kim > >> Cc: Doug Anderson > >> Cc: Javier Martinez Canillas > >> Cc: Andreas Faerber > >> Cc: Sachin Kamat > >> Cc: Andreas Farber > >> Cc: Javier Martinez Canillas > >> Signed-off-by: Thomas Abraham > >> Signed-off-by: Bartlomiej Zolnierkiewicz > >> > >> >>> > >> >>> Acked-by: Krzysztof Kozlowski > >> >> > >> >> Rebased and applied to my tree, I'll sent it later to Kukjin unless > >> >> he > >> >> picks it by himself from LKML. > >> >> > >> > Hi, as far as I know, this is for v4.2 not v4.1 so it will be > >> > applied based on > >> > v4.2-rc1 after v4.2-rc1 release. > >> > >> You mean it is for v4.3, not v4.2? > >> > >> >>> Oops, yes v4.3. > >> >>> > >> >>> Thanks for the correction. > >> >> > >> >> Kukjin & Krzysztof, > >> >> > >> >> I'm confused on this point. I was planning to take patches 1, 2, 3, 5 > >> >> and 6 towards 4.2 (e.g. in the pull request that I'll send out this > >> >> week). > >> >> > >> >> Is patch 4 going out for 4.2 or 4.3? > >> > > >> > It is quite late for sending pull request to arm-soc for 4.2. > >> > For example SoCFPGA pull request from last week was rejected: > >> > http://comments.gmane.org/gmane.linux.ports.arm.kernel/417980 > >> > >> Oh, that was wrong link. Here it is: > >> http://www.spinics.net/lists/arm-kernel/msg425911.html > >> > >> > If you want to take it for 4.2 then I am fine with it but this will > >> > cause some easy but annoying conflicts. There aren't difficult - just > >> > most of nodes in board DTS changed their place. > >> > > >> > Example of resolution (target file after merge, with cpu nodes reordered > >> > alphabetically): > >> > https://github.com/krzk/linux/commit/2cec3cb48abaf44848c62f1c0836b772eb4680dd > > > > This patch is needed for v4.2 as other changes has been already > > merged. > > > > Krzysztof/Kukjin, could you please take care of it? > > Of course! It is already in my queue. I'll send it later to Kukjin for > 4.3 (unless he picks it also). It is in your queue for v4.3 but the patch is needed for v4.2, without it cpufreq support will not work for Exynos4210 platforms. > BTW for other patchsets you still need acks from Samsung clock > maintainers. Did you poke Sylwester or Tomasz about it? Sylwester, please review/ack Samsung specific clock changes in Exynos5250 cpufreq and Exynos4x12 cpufreq patch series. Patch series: * [PATCH v3 0/4] cpufreq: use generic cpufreq drivers for Exynos5250 platform (http://lkml.org/lkml/2015/7/1/311) * [PATCH v2 0/7] cpufreq: use generic cpufreq drivers for Exynos4x12 platform (http://lkml.org/lkml/2015/7/9/419) Samsung clock specific changes: * [PATCH v3 1/4] clk: samsung: exynos5250: add cpu clock configuration data and instantiate cpu clock (http://lkml.org/lkml/2015/7/1/313) * [PATCH v2 4/7] clk: samsung: exynos4x12: add cpu clock configuration data and instantiate cpu clock (http://lkml.org/lkml/2015/7/9/424) 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
[PATCH] serial: samsung: Remove redundant DEBUG_LL check
Commit 84f57d9e3685 ("tty: serial/samsung: fix modular build") fixed
build issues when the driver was built as a module. One of those was
that printascii is only accessible when the driver is built-in.
But there is no need to check for defined(CONFIG_DEBUG_LL) since the
SERIAL_SAMSUNG_DEBUG Kconfig symbol already depends on DEBUG_LL.
Signed-off-by: Javier Martinez Canillas
---
drivers/tty/serial/samsung.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 67d0c213b1c7..8c963d6d9074 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -53,7 +53,6 @@
#include "samsung.h"
#ifdefined(CONFIG_SERIAL_SAMSUNG_DEBUG) && \
- defined(CONFIG_DEBUG_LL) && \
!defined(MODULE)
extern void printascii(const char *);
--
2.4.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: dts: Exynos4210: add CPU OPP and regulator supply property
2015-07-13 20:02 GMT+09:00 Bartlomiej Zolnierkiewicz : > > Hi, > > On Tuesday, June 23, 2015 09:24:40 AM Krzysztof Kozlowski wrote: >> On 23.06.2015 08:46, Krzysztof Kozlowski wrote: >> > On 23.06.2015 00:04, Michael Turquette wrote: >> >> Quoting Kukjin Kim (2015-06-21 18:46:26) >> >>> Krzysztof Kozlowski wrote: >> >> On 22.06.2015 10:38, Kukjin Kim wrote: >> > Krzysztof Kozlowski wrote: >> >> 2015-05-08 9:18 GMT+09:00 Krzysztof Kozlowski >> >> : >> >>> 2015-04-04 1:43 GMT+09:00 Bartlomiej Zolnierkiewicz >> >>> : >> From: Thomas Abraham >> >> For Exynos4210 platforms, add CPU operating points and CPU >> regulator supply properties for migrating from Exynos specific >> cpufreq driver to using generic cpufreq driver. >> >> Changes by Bartlomiej: >> - removed Exynos5250 and Exynos5420 support for now >> >> Cc: Kukjin Kim >> Cc: Doug Anderson >> Cc: Javier Martinez Canillas >> Cc: Andreas Faerber >> Cc: Sachin Kamat >> Cc: Andreas Farber >> Cc: Javier Martinez Canillas >> Signed-off-by: Thomas Abraham >> Signed-off-by: Bartlomiej Zolnierkiewicz >> >>> >> >>> Acked-by: Krzysztof Kozlowski >> >> >> >> Rebased and applied to my tree, I'll sent it later to Kukjin unless he >> >> picks it by himself from LKML. >> >> >> > Hi, as far as I know, this is for v4.2 not v4.1 so it will be applied >> > based on >> > v4.2-rc1 after v4.2-rc1 release. >> >> You mean it is for v4.3, not v4.2? >> >> >>> Oops, yes v4.3. >> >>> >> >>> Thanks for the correction. >> >> >> >> Kukjin & Krzysztof, >> >> >> >> I'm confused on this point. I was planning to take patches 1, 2, 3, 5 >> >> and 6 towards 4.2 (e.g. in the pull request that I'll send out this >> >> week). >> >> >> >> Is patch 4 going out for 4.2 or 4.3? >> > >> > It is quite late for sending pull request to arm-soc for 4.2. >> > For example SoCFPGA pull request from last week was rejected: >> > http://comments.gmane.org/gmane.linux.ports.arm.kernel/417980 >> >> Oh, that was wrong link. Here it is: >> http://www.spinics.net/lists/arm-kernel/msg425911.html >> >> > If you want to take it for 4.2 then I am fine with it but this will >> > cause some easy but annoying conflicts. There aren't difficult - just >> > most of nodes in board DTS changed their place. >> > >> > Example of resolution (target file after merge, with cpu nodes reordered >> > alphabetically): >> > https://github.com/krzk/linux/commit/2cec3cb48abaf44848c62f1c0836b772eb4680dd > > This patch is needed for v4.2 as other changes has been already > merged. > > Krzysztof/Kukjin, could you please take care of it? Of course! It is already in my queue. I'll send it later to Kukjin for 4.3 (unless he picks it also). BTW for other patchsets you still need acks from Samsung clock maintainers. Did you poke Sylwester or Tomasz about it? 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 4/6] ARM: dts: Exynos4210: add CPU OPP and regulator supply property
Hi, On Tuesday, June 23, 2015 09:24:40 AM Krzysztof Kozlowski wrote: > On 23.06.2015 08:46, Krzysztof Kozlowski wrote: > > On 23.06.2015 00:04, Michael Turquette wrote: > >> Quoting Kukjin Kim (2015-06-21 18:46:26) > >>> Krzysztof Kozlowski wrote: > > On 22.06.2015 10:38, Kukjin Kim wrote: > > Krzysztof Kozlowski wrote: > >> 2015-05-08 9:18 GMT+09:00 Krzysztof Kozlowski > >> : > >>> 2015-04-04 1:43 GMT+09:00 Bartlomiej Zolnierkiewicz > >>> : > From: Thomas Abraham > > For Exynos4210 platforms, add CPU operating points and CPU > regulator supply properties for migrating from Exynos specific > cpufreq driver to using generic cpufreq driver. > > Changes by Bartlomiej: > - removed Exynos5250 and Exynos5420 support for now > > Cc: Kukjin Kim > Cc: Doug Anderson > Cc: Javier Martinez Canillas > Cc: Andreas Faerber > Cc: Sachin Kamat > Cc: Andreas Farber > Cc: Javier Martinez Canillas > Signed-off-by: Thomas Abraham > Signed-off-by: Bartlomiej Zolnierkiewicz > >>> > >>> Acked-by: Krzysztof Kozlowski > >> > >> Rebased and applied to my tree, I'll sent it later to Kukjin unless he > >> picks it by himself from LKML. > >> > > Hi, as far as I know, this is for v4.2 not v4.1 so it will be applied > > based on > > v4.2-rc1 after v4.2-rc1 release. > > You mean it is for v4.3, not v4.2? > > >>> Oops, yes v4.3. > >>> > >>> Thanks for the correction. > >> > >> Kukjin & Krzysztof, > >> > >> I'm confused on this point. I was planning to take patches 1, 2, 3, 5 > >> and 6 towards 4.2 (e.g. in the pull request that I'll send out this > >> week). > >> > >> Is patch 4 going out for 4.2 or 4.3? > > > > It is quite late for sending pull request to arm-soc for 4.2. > > For example SoCFPGA pull request from last week was rejected: > > http://comments.gmane.org/gmane.linux.ports.arm.kernel/417980 > > Oh, that was wrong link. Here it is: > http://www.spinics.net/lists/arm-kernel/msg425911.html > > > If you want to take it for 4.2 then I am fine with it but this will > > cause some easy but annoying conflicts. There aren't difficult - just > > most of nodes in board DTS changed their place. > > > > Example of resolution (target file after merge, with cpu nodes reordered > > alphabetically): > > https://github.com/krzk/linux/commit/2cec3cb48abaf44848c62f1c0836b772eb4680dd This patch is needed for v4.2 as other changes has been already merged. Krzysztof/Kukjin, could you please take care of it? 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 0/7] drm/exynos/hdmi: refactoring/cleanup patches
On 07/13/2015 11:04 AM, Tobias Jakobi wrote:
> Hello,
>
> Andrzej Hajda wrote:
>> Hi Tobias,
>>
>> On 07/12/2015 06:06 PM, Tobias Jakobi wrote:
>>> Hello Andrzej!
>>>
>>> Just some small comments.
>>>
>>> It seems like linux-samsung-soc wasn't put into Cc for '[PATCH RESEND
>>> 0/6] drm/exynos: HDMI related fixes' (even though this series was),
>>> maybe you should also forward the other series to this list.
>> Yes, I forgot about it.
>>
>>> This series doesn't apply cleanly when 'drm/exynos: HDMI related fixes'
>>> is applied. E.g. the 'powered' boolean was removed by that series, but
>>> here in patch 2/7 ('drm/exynos/hdmi: Simplify HPD gpio handling') it's
>>> still there.
>> 'drm/exynos: HDMI related fixes' removes powered field from
>> mixer driver, and powered field in the patch 2/7 is from hdmi driver.
>> So they should not interfere and for sure they do not interfere in my local
>> git :)
>> Have you any warning when you tried to apply those patches.
> yes of course, otherwise I wouldn't point this out. The specific hunks
> just fail.
>
> Which is kinda obvious:
>> @@ -186,7 +186,6 @@ struct hdmi_context {
>> struct drm_device *drm_dev;
>> struct drm_connectorconnector;
>> struct drm_encoder *encoder;
>> -boolhpd;
>> boolpowered;
>> booldvi_mode;
>> struct mutexhdmi_mutex;
> This doesn't apply when 'powered' is no longer ther.
I have this field still present in my tree which is build of following
components:
- current exynos-drm-next,
- drm/exynos: HDMI related fixes,
- this patchset
Could you show me exactly which patch removes this field?
As I mentioned one patch removes similar field from mixer driver, but not from
hdmi.
Regards
Andrzej
>
>
>
> With best wishes,
> Tobias
>
>>> I also noticed that some of the patches ('drm/exynos/hdmi: remove
>>> private lock code') clash with Gustavo's latest cleanup series [1]. E.g.
>>> your patch 3/7 ('drm/exynos/hdmi: remove private lock code') touches
>>> hdmi_commit() which was removed by Gustavo. Maybe you should coordinate
>>> things with him?
>> This is always problematic :) I can try to rebase my patches on Gustavo's
>> if necessary. Gustavo, Inki what is your opinion?
>>
>> Regards
>> Andrzej
>>
>>>
>>> With best wishes,
>>> Tobias
>>>
>>>
>>> [1] http://www.spinics.net/lists/linux-samsung-soc/msg45787.html
>>>
>>>
>>> Andrzej Hajda wrote:
Hi Inki, Joonyoung,
These patches removes obsolete and old structures, to simplify further
development. They should not change behavior of the driver.
The patchset is based on exynos-drm-next plus my HDMI related fixes [1].
The patchset was tested on Universal and Odroid U3.
[1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/132348
Regards
Andrzej
Andrzej Hajda (7):
drm/exynos/hdmi: remove old platform data code
drm/exynos/hdmi: Simplify HPD gpio handling
drm/exynos/hdmi: remove private lock code
drm/exynos/hdmi: add driver data pointer to private context
drm/exynos/hdmi: remove redundant configuration fields
drm/exynos/hdmi: remove hdmi_v13_conf struct
drm/exynos/hdmi: remove hdmi_v14_conf struct
drivers/gpu/drm/exynos/exynos_hdmi.c | 860
++-
1 file changed, 245 insertions(+), 615 deletions(-)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-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/7] drm/exynos/hdmi: refactoring/cleanup patches
Hello,
Andrzej Hajda wrote:
> Hi Tobias,
>
> On 07/12/2015 06:06 PM, Tobias Jakobi wrote:
>> Hello Andrzej!
>>
>> Just some small comments.
>>
>> It seems like linux-samsung-soc wasn't put into Cc for '[PATCH RESEND
>> 0/6] drm/exynos: HDMI related fixes' (even though this series was),
>> maybe you should also forward the other series to this list.
>
> Yes, I forgot about it.
>
>>
>> This series doesn't apply cleanly when 'drm/exynos: HDMI related fixes'
>> is applied. E.g. the 'powered' boolean was removed by that series, but
>> here in patch 2/7 ('drm/exynos/hdmi: Simplify HPD gpio handling') it's
>> still there.
>
> 'drm/exynos: HDMI related fixes' removes powered field from
> mixer driver, and powered field in the patch 2/7 is from hdmi driver.
> So they should not interfere and for sure they do not interfere in my local
> git :)
> Have you any warning when you tried to apply those patches.
yes of course, otherwise I wouldn't point this out. The specific hunks
just fail.
Which is kinda obvious:
> @@ -186,7 +186,6 @@ struct hdmi_context {
> struct drm_device *drm_dev;
> struct drm_connectorconnector;
> struct drm_encoder *encoder;
> - boolhpd;
> boolpowered;
> booldvi_mode;
> struct mutexhdmi_mutex;
This doesn't apply when 'powered' is no longer ther.
With best wishes,
Tobias
>
>>
>> I also noticed that some of the patches ('drm/exynos/hdmi: remove
>> private lock code') clash with Gustavo's latest cleanup series [1]. E.g.
>> your patch 3/7 ('drm/exynos/hdmi: remove private lock code') touches
>> hdmi_commit() which was removed by Gustavo. Maybe you should coordinate
>> things with him?
>
> This is always problematic :) I can try to rebase my patches on Gustavo's
> if necessary. Gustavo, Inki what is your opinion?
>
> Regards
> Andrzej
>
>>
>>
>> With best wishes,
>> Tobias
>>
>>
>> [1] http://www.spinics.net/lists/linux-samsung-soc/msg45787.html
>>
>>
>> Andrzej Hajda wrote:
>>> Hi Inki, Joonyoung,
>>>
>>> These patches removes obsolete and old structures, to simplify further
>>> development. They should not change behavior of the driver.
>>>
>>> The patchset is based on exynos-drm-next plus my HDMI related fixes [1].
>>>
>>> The patchset was tested on Universal and Odroid U3.
>>>
>>> [1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/132348
>>>
>>> Regards
>>> Andrzej
>>>
>>>
>>> Andrzej Hajda (7):
>>> drm/exynos/hdmi: remove old platform data code
>>> drm/exynos/hdmi: Simplify HPD gpio handling
>>> drm/exynos/hdmi: remove private lock code
>>> drm/exynos/hdmi: add driver data pointer to private context
>>> drm/exynos/hdmi: remove redundant configuration fields
>>> drm/exynos/hdmi: remove hdmi_v13_conf struct
>>> drm/exynos/hdmi: remove hdmi_v14_conf struct
>>>
>>> drivers/gpu/drm/exynos/exynos_hdmi.c | 860
>>> ++-
>>> 1 file changed, 245 insertions(+), 615 deletions(-)
>>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-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/10 v6] Helper to abstract vma handling in media layer
On 07/09/2015 02:12 PM, Hans Verkuil wrote: > On 07/09/2015 01:48 PM, Jan Kara wrote: >> Hello, >> >> Hans, did you have a chance to look at these patches? I have tested them >> with the vivid driver but it would be good if you could run them through >> your standard testing procedure as well. Andrew has updated the patches in >> his tree but some ack from you would be welcome... > > I've planned a 'patch day' for Monday. So hopefully you'll see a pull request > by then. OK, I'm confused. I thought the non-vb2 patches would go in for 4.2? That didn't happen, so I guess the plan is to merge the whole lot for 4.3 via our media tree? If that's the case, can you post a new patch series on top of the master branch of the media tree? I want to make sure I use the right patches. Also, if you do make a new patch series, then it would be better if patch 10/10 is folded into patch 2/10. If that's not the case, then you have to let me know what I should do. Regards, Hans >> >> Honza >> On Thu 18-06-15 16:08:30, Jan Kara wrote: >>> Hello, >>> >>> I'm sending the sixth version of my patch series to abstract vma handling >>> from >>> the various media drivers. Since the previous version I have added a patch >>> to >>> move mm helpers into a separate file and behind a config option. I also >>> changed patch pushing mmap_sem down in videobuf2 core to avoid lockdep >>> warning >>> and NULL dereference Hans found in his testing. I've also included small >>> fixups Andrew was carrying. >>> >>> After this patch set drivers have to know much less details about vmas, >>> their >>> types, and locking. Also quite some code is removed from them. As a bonus >>> drivers get automatically VM_FAULT_RETRY handling. The primary motivation >>> for >>> this series is to remove knowledge about mmap_sem locking from as many >>> places a >>> possible so that we can change it with reasonable effort. >>> >>> The core of the series is the new helper get_vaddr_frames() which is given a >>> virtual address and it fills in PFNs / struct page pointers (depending on >>> VMA >>> type) into the provided array. If PFNs correspond to normal pages it also >>> grabs >>> references to these pages. The difference from get_user_pages() is that this >>> function can also deal with pfnmap, and io mappings which is what the media >>> drivers need. >>> >>> I have tested the patches with vivid driver so at least vb2 code got some >>> exposure. Conversion of other drivers was just compile-tested (for x86 so >>> e.g. >>> exynos driver which is only for Samsung platform is completely untested). >>> >>> Andrew, can you please update the patches in mm three? Thanks! >>> >>> Honza >>> >>> Changes since v5: >>> * Moved mm helper into a separate file and behind a config option >>> * Changed the first patch pushing mmap_sem down in videobuf2 core to avoid >>> possible deadlock >>> >>> Changes since v4: >>> * Minor cleanups and fixes pointed out by Mel and Vlasta >>> * Added Acked-by tags >>> >>> Changes since v3: >>> * Added include into mm/gup.c as it's needed for some >>> archs >>> * Fixed error path for exynos driver >>> >>> Changes since v2: >>> * Renamed functions and structures as Mel suggested >>> * Other minor changes suggested by Mel >>> * Rebased on top of 4.1-rc2 >>> * Changed functions to get pointer to array of pages / pfns to perform >>> conversion if necessary. This fixes possible issue in the omap I may have >>> introduced in v2 and generally makes the API less errorprone. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] mfd: max77686: Split out regulator part from the DT binding
Hello Krzysztof, On 07/13/2015 10:03 AM, Krzysztof Kozlowski wrote: > On 13.07.2015 16:42, Javier Martinez Canillas wrote: >> The Maxim MAX77686 PMIC is a multi-function device with regulators, >> clocks and a RTC. The DT bindings for the clocks are in a separate >> file but the bindings for the regulators are inside the mfd part. >> >> To make it consistent with the clocks portion of the binding and >> because is more natural to look for regulator bindings under the >> bindings/regulator sub-directory, split the regulator portion of >> the DT binding and add it as a separate file. >> >> Signed-off-by: Javier Martinez Canillas >> >> --- >> >> Documentation/devicetree/bindings/mfd/max77686.txt | 58 +- >> .../devicetree/bindings/regulator/max77686.txt | 71 >> ++ >> 2 files changed, 74 insertions(+), 55 deletions(-) >> create mode 100644 Documentation/devicetree/bindings/regulator/max77686.txt > > Actually I would prefer the opposite - merging everything into one file > (clocks, regulators -> mfd) because: > > 1. Separate files introduce some duplication (like introduction and > common part of example node). > > 2. It is easier to track the changes and update them. For example when > adding a new chipset to the driver one may forgot about updating other > files. When moving files one may forgot to update hard-coded path in > some other file. > > 3. When comparing existing DTS with documentation or when creating new > DTS for the device it is just faster to fetch everything (knowledge, > example node) from one file. > Yes, I also wondered about going the opposite way but then thought that is more natural to look for clock bindings under bindings/clock and for regulators drivers under bindings/regulator... > However I understand that such opinion may be not suited for the idea of > MFD... > ...but I don't have a strong opinion and can do the other way if folks are more fond with that single file approach. What I think is that it should be consistent, either everything is in mfd for all PMICs or everything is split. The max77686 for example has a somehow arbitrary split since the clocks are in another file but the regulators are in the same mfd binding doc. > Best regards, > Krzysztof > Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] mfd: Add DT binding for Maxim MAX77802 IC
Hello Krzysztof, Thanks a lot for the feedback. On 07/13/2015 09:53 AM, Krzysztof Kozlowski wrote: > On 13.07.2015 16:42, Javier Martinez Canillas wrote: >> The MAX77802 is a chip that contains regulators, 2 32kHz clocks, >> a RTC and an I2C interface to program the individual components. >> >> The are already DT bindings for the regulators and clocks and >> these reference to a bindings/mfd/max77802.txt file, that didn't >> exist, for the details about the PMIC. >> >> Signed-off-by: Javier Martinez Canillas >> --- >> >> Documentation/devicetree/bindings/mfd/max77802.txt | 26 >> ++ >> 1 file changed, 26 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/mfd/max77802.txt > > I wonder what happened with previous email... > http://www.spinics.net/lists/kernel/msg1784726.html > The story is that in v9 I split the series to add the max77802 clock and regulators support as different series to avoid the cross subsystem churn: [PATCH v9 0/6] Add Maxim 77802 clocks support https://lwn.net/Articles/608834/ [PATCH v9 0/2] Add Maxim 77802 regulator support https://lkml.org/lkml/2014/8/18/71 But then forgot to add the common DT binding for the PMIC in bindings/mfd... >> >> diff --git a/Documentation/devicetree/bindings/mfd/max77802.txt >> b/Documentation/devicetree/bindings/mfd/max77802.txt >> new file mode 100644 >> index ..875ebebbc5b0 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/mfd/max77802.txt >> @@ -0,0 +1,26 @@ >> +Maxim MAX77802 multi-function device >> + >> +The Maxim MAX77802 is a power management chip (PMIC) that contains 10 high >> +efficiency Buck regulators, 32 Low-dropout (LDO) regulators used to power >> +up application processors and peripherals, a 2-channel 32kHz clock outputs, >> +a Real-Time-Clock (RTC) and a I2C interface to program the individual >> +regulators, clocks outputs and the RTC. >> + >> +Binding for the built-in 32k clock generator block is defined separately >> +in the bindings/clk/maxim,max77802.txt file and binding for the regulators >> +is defined in the bindings/regulator/max77802.txt file. >> + >> +Required properties: >> +- compatible : Must be "maxim,max77686"; > > Shouldn't this be 77802? > right, thanks for pointing out this. It is a copy & paste error. I'll wait a couple of days for more feedback and re-post. > Best regards, > Krzysztof > Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-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] mfd: max77686: Split out regulator part from the DT binding
On 13.07.2015 16:42, Javier Martinez Canillas wrote:
> The Maxim MAX77686 PMIC is a multi-function device with regulators,
> clocks and a RTC. The DT bindings for the clocks are in a separate
> file but the bindings for the regulators are inside the mfd part.
>
> To make it consistent with the clocks portion of the binding and
> because is more natural to look for regulator bindings under the
> bindings/regulator sub-directory, split the regulator portion of
> the DT binding and add it as a separate file.
>
> Signed-off-by: Javier Martinez Canillas
>
> ---
>
> Documentation/devicetree/bindings/mfd/max77686.txt | 58 +-
> .../devicetree/bindings/regulator/max77686.txt | 71
> ++
> 2 files changed, 74 insertions(+), 55 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/regulator/max77686.txt
Actually I would prefer the opposite - merging everything into one file
(clocks, regulators -> mfd) because:
1. Separate files introduce some duplication (like introduction and
common part of example node).
2. It is easier to track the changes and update them. For example when
adding a new chipset to the driver one may forgot about updating other
files. When moving files one may forgot to update hard-coded path in
some other file.
3. When comparing existing DTS with documentation or when creating new
DTS for the device it is just faster to fetch everything (knowledge,
example node) from one file.
However I understand that such opinion may be not suited for the idea of
MFD...
Best regards,
Krzysztof
>
> diff --git a/Documentation/devicetree/bindings/mfd/max77686.txt
> b/Documentation/devicetree/bindings/mfd/max77686.txt
> index 8221102d3fc2..8a276dd5ea46 100644
> --- a/Documentation/devicetree/bindings/mfd/max77686.txt
> +++ b/Documentation/devicetree/bindings/mfd/max77686.txt
> @@ -8,7 +8,8 @@ client while probing.This document describes the binding for
> mfd device and
> PMIC submodule.
>
> Binding for the built-in 32k clock generator block is defined separately
> -in bindings/clk/maxim,max77686.txt file.
> +in the bindings/clk/maxim,max77686.txt file and binding for the regulators
> +is defined in the bindings/regulator/max77686.txt file.
>
> Required properties:
> - compatible : Must be "maxim,max77686";
> @@ -16,36 +17,6 @@ Required properties:
> - interrupts : This i2c device has an IRQ line connected to the main SoC.
> - interrupt-parent : The parent interrupt controller.
>
> -Optional node:
> -- voltage-regulators : The regulators of max77686 have to be instantiated
> - under subnode named "voltage-regulators" using the following format.
> -
> - regulator_name {
> - regulator-compatible = LDOn/BUCKn
> - standard regulator constraints
> - };
> - refer Documentation/devicetree/bindings/regulator/regulator.txt
> -
> - The regulator node's name should be initialized with a string
> -to get matched with their hardware counterparts as follow:
> -
> - -LDOn : for LDOs, where n can lie in range 1 to 26.
> - example: LDO1, LDO2, LDO26.
> - -BUCKn : for BUCKs, where n can lie in range 1 to 9.
> - example: BUCK1, BUCK5, BUCK9.
> -
> - Regulators which can be turned off during system suspend:
> - -LDOn : 2, 6-8, 10-12, 14-16,
> - -BUCKn : 1-4.
> - Use standard regulator bindings for it ('regulator-off-in-suspend').
> -
> - LDO20, LDO21, LDO22, BUCK8 and BUCK9 can be configured to GPIO enable
> - control. To turn this feature on this property must be added to the
> regulator
> - sub-node:
> - - maxim,ena-gpios : one GPIO specifier enable control (the gpio
> - flags are actually ignored and always
> - ACTIVE_HIGH is used)
> -
> Example:
>
> max77686@09 {
> @@ -53,27 +24,4 @@ Example:
> interrupt-parent = <&wakeup_eint>;
> interrupts = <26 0>;
> reg = <0x09>;
> -
> - voltage-regulators {
> - ldo11_reg: LDO11 {
> - regulator-name = "vdd_ldo11";
> - regulator-min-microvolt = <190>;
> - regulator-max-microvolt = <190>;
> - regulator-always-on;
> - };
> -
> - buck1_reg: BUCK1 {
> - regulator-name = "vdd_mif";
> - regulator-min-microvolt = <95>;
> - regulator-max-microvolt = <130>;
> - regulator-always-on;
> - regulator-boot-on;
> - };
> -
> - buck9_reg: BUCK9 {
> - regulator-name = "CAM_ISP_CORE_1.2V";
> - regulator-min-microvolt = <100>;
> - r
Re: [PATCH 2/3] mfd: Add DT binding for Maxim MAX77802 IC
On 13.07.2015 16:42, Javier Martinez Canillas wrote:
> The MAX77802 is a chip that contains regulators, 2 32kHz clocks,
> a RTC and an I2C interface to program the individual components.
>
> The are already DT bindings for the regulators and clocks and
> these reference to a bindings/mfd/max77802.txt file, that didn't
> exist, for the details about the PMIC.
>
> Signed-off-by: Javier Martinez Canillas
> ---
>
> Documentation/devicetree/bindings/mfd/max77802.txt | 26
> ++
> 1 file changed, 26 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/max77802.txt
I wonder what happened with previous email...
http://www.spinics.net/lists/kernel/msg1784726.html
>
> diff --git a/Documentation/devicetree/bindings/mfd/max77802.txt
> b/Documentation/devicetree/bindings/mfd/max77802.txt
> new file mode 100644
> index ..875ebebbc5b0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/max77802.txt
> @@ -0,0 +1,26 @@
> +Maxim MAX77802 multi-function device
> +
> +The Maxim MAX77802 is a power management chip (PMIC) that contains 10 high
> +efficiency Buck regulators, 32 Low-dropout (LDO) regulators used to power
> +up application processors and peripherals, a 2-channel 32kHz clock outputs,
> +a Real-Time-Clock (RTC) and a I2C interface to program the individual
> +regulators, clocks outputs and the RTC.
> +
> +Binding for the built-in 32k clock generator block is defined separately
> +in the bindings/clk/maxim,max77802.txt file and binding for the regulators
> +is defined in the bindings/regulator/max77802.txt file.
> +
> +Required properties:
> +- compatible : Must be "maxim,max77686";
Shouldn't this be 77802?
Best regards,
Krzysztof
> +- reg : Specifies the i2c slave address of PMIC block.
> +- interrupts : This i2c device has an IRQ line connected to the main SoC.
> +- interrupt-parent : The parent interrupt controller.
> +
> +Example:
> +
> + max77802@09 {
> + compatible = "maxim,max77802";
> + interrupt-parent = <&intc>;
> + interrupts = <26 0>;
> + reg = <0x09>;
> + };
>
--
To unsubscribe from this list: send the line "unsubscribe linux-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] mfd: max77686: Don't suggest in binding to use a deprecated property
On 13.07.2015 16:42, Javier Martinez Canillas wrote: > The regulator-compatible property from the regulator DT binding was > deprecated. But the max77686 DT binding doc still suggest to use it > instead of the regulator node name's which is the correct approach. > > Signed-off-by: Javier Martinez Canillas > --- > > Documentation/devicetree/bindings/mfd/max77686.txt | 11 --- > 1 file changed, 4 insertions(+), 7 deletions(-) Reviewed-by: Krzysztof Kozlowski 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
[PATCH 0/3] mfd: Improve DT binding docs for max77686 and max77802
Hello Lee, This series contains some improvements for the Device Tree bindings of the Maxim MAX77686 and MAX77802 multi-function devices. Patch #1 changes the max77686 binding to not suggest using a deprecated property of the regulator DT binding. Patch #2 adds a DT binding for the mfd portion of the max77802 that was missing. Patch #3 moves the regulator portion of the max77686 to the regulator's DT binding sub-directory since it is a better fit for this information. This third patch needs an ack from the regulator sub-system maintainer. Javier Martinez Canillas (3): mfd: max77686: Don't suggest in binding to use a deprecated property mfd: Add DT binding for Maxim MAX77802 IC mfd: max77686: Split out regulator part from the DT binding Documentation/devicetree/bindings/mfd/max77686.txt | 61 +-- Documentation/devicetree/bindings/mfd/max77802.txt | 26 .../devicetree/bindings/regulator/max77686.txt | 71 ++ 3 files changed, 100 insertions(+), 58 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/max77802.txt create mode 100644 Documentation/devicetree/bindings/regulator/max77686.txt -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] mfd: Add DT binding for Maxim MAX77802 IC
The MAX77802 is a chip that contains regulators, 2 32kHz clocks,
a RTC and an I2C interface to program the individual components.
The are already DT bindings for the regulators and clocks and
these reference to a bindings/mfd/max77802.txt file, that didn't
exist, for the details about the PMIC.
Signed-off-by: Javier Martinez Canillas
---
Documentation/devicetree/bindings/mfd/max77802.txt | 26 ++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/max77802.txt
diff --git a/Documentation/devicetree/bindings/mfd/max77802.txt
b/Documentation/devicetree/bindings/mfd/max77802.txt
new file mode 100644
index ..875ebebbc5b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/max77802.txt
@@ -0,0 +1,26 @@
+Maxim MAX77802 multi-function device
+
+The Maxim MAX77802 is a power management chip (PMIC) that contains 10 high
+efficiency Buck regulators, 32 Low-dropout (LDO) regulators used to power
+up application processors and peripherals, a 2-channel 32kHz clock outputs,
+a Real-Time-Clock (RTC) and a I2C interface to program the individual
+regulators, clocks outputs and the RTC.
+
+Binding for the built-in 32k clock generator block is defined separately
+in the bindings/clk/maxim,max77802.txt file and binding for the regulators
+is defined in the bindings/regulator/max77802.txt file.
+
+Required properties:
+- compatible : Must be "maxim,max77686";
+- reg : Specifies the i2c slave address of PMIC block.
+- interrupts : This i2c device has an IRQ line connected to the main SoC.
+- interrupt-parent : The parent interrupt controller.
+
+Example:
+
+ max77802@09 {
+ compatible = "maxim,max77802";
+ interrupt-parent = <&intc>;
+ interrupts = <26 0>;
+ reg = <0x09>;
+ };
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] mfd: max77686: Split out regulator part from the DT binding
The Maxim MAX77686 PMIC is a multi-function device with regulators,
clocks and a RTC. The DT bindings for the clocks are in a separate
file but the bindings for the regulators are inside the mfd part.
To make it consistent with the clocks portion of the binding and
because is more natural to look for regulator bindings under the
bindings/regulator sub-directory, split the regulator portion of
the DT binding and add it as a separate file.
Signed-off-by: Javier Martinez Canillas
---
Documentation/devicetree/bindings/mfd/max77686.txt | 58 +-
.../devicetree/bindings/regulator/max77686.txt | 71 ++
2 files changed, 74 insertions(+), 55 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/max77686.txt
diff --git a/Documentation/devicetree/bindings/mfd/max77686.txt
b/Documentation/devicetree/bindings/mfd/max77686.txt
index 8221102d3fc2..8a276dd5ea46 100644
--- a/Documentation/devicetree/bindings/mfd/max77686.txt
+++ b/Documentation/devicetree/bindings/mfd/max77686.txt
@@ -8,7 +8,8 @@ client while probing.This document describes the binding for
mfd device and
PMIC submodule.
Binding for the built-in 32k clock generator block is defined separately
-in bindings/clk/maxim,max77686.txt file.
+in the bindings/clk/maxim,max77686.txt file and binding for the regulators
+is defined in the bindings/regulator/max77686.txt file.
Required properties:
- compatible : Must be "maxim,max77686";
@@ -16,36 +17,6 @@ Required properties:
- interrupts : This i2c device has an IRQ line connected to the main SoC.
- interrupt-parent : The parent interrupt controller.
-Optional node:
-- voltage-regulators : The regulators of max77686 have to be instantiated
- under subnode named "voltage-regulators" using the following format.
-
- regulator_name {
- regulator-compatible = LDOn/BUCKn
- standard regulator constraints
- };
- refer Documentation/devicetree/bindings/regulator/regulator.txt
-
- The regulator node's name should be initialized with a string
-to get matched with their hardware counterparts as follow:
-
- -LDOn : for LDOs, where n can lie in range 1 to 26.
- example: LDO1, LDO2, LDO26.
- -BUCKn : for BUCKs, where n can lie in range 1 to 9.
- example: BUCK1, BUCK5, BUCK9.
-
- Regulators which can be turned off during system suspend:
- -LDOn : 2, 6-8, 10-12, 14-16,
- -BUCKn : 1-4.
- Use standard regulator bindings for it ('regulator-off-in-suspend').
-
- LDO20, LDO21, LDO22, BUCK8 and BUCK9 can be configured to GPIO enable
- control. To turn this feature on this property must be added to the regulator
- sub-node:
- - maxim,ena-gpios : one GPIO specifier enable control (the gpio
- flags are actually ignored and always
- ACTIVE_HIGH is used)
-
Example:
max77686@09 {
@@ -53,27 +24,4 @@ Example:
interrupt-parent = <&wakeup_eint>;
interrupts = <26 0>;
reg = <0x09>;
-
- voltage-regulators {
- ldo11_reg: LDO11 {
- regulator-name = "vdd_ldo11";
- regulator-min-microvolt = <190>;
- regulator-max-microvolt = <190>;
- regulator-always-on;
- };
-
- buck1_reg: BUCK1 {
- regulator-name = "vdd_mif";
- regulator-min-microvolt = <95>;
- regulator-max-microvolt = <130>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- buck9_reg: BUCK9 {
- regulator-name = "CAM_ISP_CORE_1.2V";
- regulator-min-microvolt = <100>;
- regulator-max-microvolt = <120>;
- maxim,ena-gpios = <&gpm0 3 GPIO_ACTIVE_HIGH>;
- };
- }
+ };
diff --git a/Documentation/devicetree/bindings/regulator/max77686.txt
b/Documentation/devicetree/bindings/regulator/max77686.txt
new file mode 100644
index ..04b7604c219e
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/max77686.txt
@@ -0,0 +1,71 @@
+Binding for Maxim MAX77686 regulators
+
+This is a part of the device tree bindings of MAX77686 multi-function device.
+More information can be found in bindings/mfd/max77686.txt file.
+
+The MAX77802 PMIC has 9 high-efficiency Buck and 26 Low-dropout (LDO)
+regulators that can be controlled over I2C.
+
+Following properties should be present in main device node of the MFD chip.
+
+Optional node:
+- voltage-regulators : The regulators of max77686 ha
[PATCH 1/3] mfd: max77686: Don't suggest in binding to use a deprecated property
The regulator-compatible property from the regulator DT binding was
deprecated. But the max77686 DT binding doc still suggest to use it
instead of the regulator node name's which is the correct approach.
Signed-off-by: Javier Martinez Canillas
---
Documentation/devicetree/bindings/mfd/max77686.txt | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/max77686.txt
b/Documentation/devicetree/bindings/mfd/max77686.txt
index 163bd81a4607..8221102d3fc2 100644
--- a/Documentation/devicetree/bindings/mfd/max77686.txt
+++ b/Documentation/devicetree/bindings/mfd/max77686.txt
@@ -26,7 +26,7 @@ Optional node:
};
refer Documentation/devicetree/bindings/regulator/regulator.txt
- The regulator-compatible property of regulator should initialized with string
+ The regulator node's name should be initialized with a string
to get matched with their hardware counterparts as follow:
-LDOn : for LDOs, where n can lie in range 1 to 26.
@@ -55,16 +55,14 @@ Example:
reg = <0x09>;
voltage-regulators {
- ldo11_reg {
- regulator-compatible = "LDO11";
+ ldo11_reg: LDO11 {
regulator-name = "vdd_ldo11";
regulator-min-microvolt = <190>;
regulator-max-microvolt = <190>;
regulator-always-on;
};
- buck1_reg {
- regulator-compatible = "BUCK1";
+ buck1_reg: BUCK1 {
regulator-name = "vdd_mif";
regulator-min-microvolt = <95>;
regulator-max-microvolt = <130>;
@@ -72,8 +70,7 @@ Example:
regulator-boot-on;
};
- buck9_reg {
- regulator-compatible = "BUCK9";
+ buck9_reg: BUCK9 {
regulator-name = "CAM_ISP_CORE_1.2V";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <120>;
--
2.4.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
