Re: [PATCH v7 11/44] [media] media: use entity.graph_obj.mdev instead of .parent
On 08/23/2015 10:17 PM, Mauro Carvalho Chehab wrote: > From: Javier Martinez Canillas > > The struct media_entity has a .parent field that stores a pointer > to the parent struct media_device. But recently a media_gobj was > embedded into the entities and since struct media_gojb already has > a pointer to a struct media_device in the .mdev field, the .parent > field becomes redundant and can be removed. > > This patch replaces all the usage of .parent by .graph_obj.mdev so > that field will become unused and can be removed on a later patch. > > No functional changes. > > The transformation was made using the following coccinelle spatch: > > @@ > struct media_entity *me; > @@ > > - me->parent > + me->graph_obj.mdev > > @@ > struct media_entity *link; > @@ > > - link->source->entity->parent > + link->source->entity->graph_obj.mdev > > @@ > struct exynos_video_entity *ve; > @@ > > - ve->vdev.entity.parent > + ve->vdev.entity.graph_obj.mdev > > Suggested-by: Mauro Carvalho Chehab > > Signed-off-by: Javier Martinez Canillas > Signed-off-by: Mauro Carvalho Chehab Acked-by: Hans Verkuil -- 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/7] phy: exynos-usb2: add vbus regulator support
On 25.08.2015 14:47, Marek Szyprowski wrote: > Hello, > > On 2015-08-21 14:44, Kishon Vijay Abraham I wrote: >> On Friday 21 August 2015 06:08 PM, Marek Szyprowski wrote: >>> Exynos USB2 PHY has separate power supply, which is usually provided by >>> VBUS regulator. This patch adds support for it. VBUS regulator is >>> optional, to keep compatibility with boards, which have VBUS provided >>> from some always-on power source. >>> >>> Signed-off-by: Marek Szyprowski >>> --- >>> .../devicetree/bindings/phy/samsung-phy.txt| 3 +++ >>> drivers/phy/phy-samsung-usb2.c | 25 >>> -- >>> drivers/phy/phy-samsung-usb2.h | 2 ++ >>> 3 files changed, 28 insertions(+), 2 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt >>> b/Documentation/devicetree/bindings/phy/samsung-phy.txt >>> index 60c6f2a633e0..0289d3b07853 100644 >>> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt >>> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt >>> @@ -44,6 +44,9 @@ Required properties: >>> - the "ref" clock is used to get the rate of the clock provided >>> to the >>> PHY module >>> +Optional properties: >>> +- vbus-supply: power-supply phandle for vbus power source >> how about using phy-supply? > > I wanted to make it a bit more descriptive (vbus-supply is rather self > explaining name) > and keep it in line with Exynos usb3-drd phy, which already supports > vbus-supply. > If you think that this is a bad idea, a will use phy-supply then. This is actually supply for VBUS, not for the phy. Using phy-supply would work fine and reduce the size of code... but would be rather a hacky-use of phy and it could be misleading. I don't have strong feeling about this, both ideas have its advantages. If I had to choose than I would like to use vbus-supply because of its correctness with real-world (this is a VBUS after all). 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 1/7] phy: exynos-usb2: add vbus regulator support
Hello, On 2015-08-21 14:44, Kishon Vijay Abraham I wrote: On Friday 21 August 2015 06:08 PM, Marek Szyprowski wrote: Exynos USB2 PHY has separate power supply, which is usually provided by VBUS regulator. This patch adds support for it. VBUS regulator is optional, to keep compatibility with boards, which have VBUS provided from some always-on power source. Signed-off-by: Marek Szyprowski --- .../devicetree/bindings/phy/samsung-phy.txt| 3 +++ drivers/phy/phy-samsung-usb2.c | 25 -- drivers/phy/phy-samsung-usb2.h | 2 ++ 3 files changed, 28 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt index 60c6f2a633e0..0289d3b07853 100644 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt @@ -44,6 +44,9 @@ Required properties: - the "ref" clock is used to get the rate of the clock provided to the PHY module +Optional properties: +- vbus-supply: power-supply phandle for vbus power source how about using phy-supply? I wanted to make it a bit more descriptive (vbus-supply is rather self explaining name) and keep it in line with Exynos usb3-drd phy, which already supports vbus-supply. If you think that this is a bad idea, a will use phy-supply then. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/7] Add support for Exynos SROM Controller driver
On 24.08.2015 17:02, Pankaj Dubey wrote: > This patch set adds support for Exynos SROM controller DT based driver. > Currently SROM register sets are used only during S2R, so driver > basically added for taking care of S2R. It will help us in removing > static mapping from exynos.c and other extra code handline during S2R. > > This patch set also updated exynos4 and exynos5 dtsi files for with device > node for srom, and added binding documentation for the same. > > First two patches are some minor cleanup in mach-exynos. > > Patchset v1 was posted here[1] > [1]: https://lkml.org/lkml/2015/4/29/98 > > Changes since v1: > - Rebased to latest kgene tree. > - Addressed review comments from Krzysztof Kozlowski. > - Add two new patches for minor cleanup in exynos.c and map.h > > Pankaj Dubey (7): > ARM: EXYNOS: remove unused static mapping of CMU for exynos5 > ARM: EXYNOS: code cleanup in map.h > drivers: soc: add support for exynos SROM driver > ARM: EXYNOS: Remove SROM related register settings from mach-exynos > ARM: dts: add SROM device node for exynos4 > ARM: dts: add SROM device node for exynos5 > Documentation: dt-bindings: add exynos-srom binding information One more thing: please update the existing Exynos entry in maintainers so it would cover drivers/soc/samsung. Best regards, Krzysztof > > .../bindings/arm/samsung/exynos-srom.txt | 12 ++ > arch/arm/boot/dts/exynos4.dtsi | 5 + > arch/arm/boot/dts/exynos5.dtsi | 5 + > arch/arm/mach-exynos/Kconfig | 2 + > arch/arm/mach-exynos/common.h | 2 - > arch/arm/mach-exynos/exynos.c | 22 > arch/arm/mach-exynos/include/mach/map.h| 8 -- > arch/arm/mach-exynos/regs-srom.h | 53 > arch/arm/mach-exynos/suspend.c | 20 +-- > arch/arm/plat-samsung/include/plat/map-s5p.h | 1 - > drivers/soc/Kconfig| 1 + > drivers/soc/Makefile | 1 + > drivers/soc/samsung/Kconfig| 13 ++ > drivers/soc/samsung/Makefile | 1 + > drivers/soc/samsung/exynos-srom.c | 143 > + > drivers/soc/samsung/exynos-srom.h | 51 > 16 files changed, 236 insertions(+), 104 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt > delete mode 100644 arch/arm/mach-exynos/regs-srom.h > create mode 100644 drivers/soc/samsung/Kconfig > create mode 100644 drivers/soc/samsung/Makefile > create mode 100644 drivers/soc/samsung/exynos-srom.c > create mode 100644 drivers/soc/samsung/exynos-srom.h > -- 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 7/7] Documentation: dt-bindings: add exynos-srom binding information
On 24.08.2015 17:02, Pankaj Dubey wrote: > This patch adds exynos-srom binding information for SROM Controller > driver on Exynos SoCs. > > CC: Rob Herring > CC: Mark Rutland > CC: Ian Campbell > Signed-off-by: Pankaj Dubey > --- > .../devicetree/bindings/arm/samsung/exynos-srom.txt | 12 > > 1 file changed, 12 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt 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 v2 6/7] ARM: dts: add SROM device node for exynos5
On 24.08.2015 17:02, Pankaj Dubey wrote: > Add SROM controller device node for exynos5. > > CC: Rob Herring > CC: Mark Rutland > CC: Ian Campbell > Signed-off-by: Pankaj Dubey > --- > arch/arm/boot/dts/exynos5.dtsi | 5 + > 1 file changed, 5 insertions(+) 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 v2 5/7] ARM: dts: add SROM device node for exynos4
On 24.08.2015 17:02, Pankaj Dubey wrote: > Add device node of SROM controller for exynos4. > > CC: Rob Herring > CC: Mark Rutland > CC: Ian Campbell > Signed-off-by: Pankaj Dubey > --- > arch/arm/boot/dts/exynos4.dtsi | 5 + > 1 file changed, 5 insertions(+) > 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 v2 4/7] ARM: EXYNOS: Remove SROM related register settings from mach-exynos
On 24.08.2015 17:02, Pankaj Dubey wrote: > As now we have dedicated driver for SROM controller, it will take care > of saving register banks during S2R so we can safely remove these > settings from mach-exynos. > > Signed-off-by: Pankaj Dubey > --- > arch/arm/mach-exynos/Kconfig | 2 ++ > arch/arm/mach-exynos/common.h| 2 -- > arch/arm/mach-exynos/exynos.c| 17 - > arch/arm/mach-exynos/include/mach/map.h | 3 -- > arch/arm/mach-exynos/regs-srom.h | 53 > > arch/arm/mach-exynos/suspend.c | 20 ++- > arch/arm/plat-samsung/include/plat/map-s5p.h | 1 - > 7 files changed, 4 insertions(+), 94 deletions(-) > delete mode 100644 arch/arm/mach-exynos/regs-srom.h The order of patches looks wrong. Is this fully bisectable? You are removing here support for SROM but DTS bindings are not added yet. > > diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig > index 3a10f1a..7c917ef 100644 > --- a/arch/arm/mach-exynos/Kconfig > +++ b/arch/arm/mach-exynos/Kconfig > @@ -27,6 +27,8 @@ menuconfig ARCH_EXYNOS > select SRAM > select THERMAL > select MFD_SYSCON > + select SOC_SAMSUNG > + select EXYNOS_SROM > help > Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5) > > diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h > index 1534925..1c04741 100644 > --- a/arch/arm/mach-exynos/common.h > +++ b/arch/arm/mach-exynos/common.h > @@ -108,8 +108,6 @@ IS_SAMSUNG_CPU(exynos5800, EXYNOS5800_SOC_ID, > EXYNOS5_SOC_MASK) > > #define soc_is_exynos4() (soc_is_exynos4210() || soc_is_exynos4212() || \ > soc_is_exynos4412()) > -#define soc_is_exynos5() (soc_is_exynos5250() || soc_is_exynos5410() || \ > - soc_is_exynos5420() || soc_is_exynos5800()) That wasn't here in v1. I see that it is not used any more and of_machine_is_compatible is preferred but I would prefer to leave it. In certain cases you cannot use of_machine_is_compatible (e.g. in platform_do_lowpower). Rest looks good. 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 v3 06/14] Documentation: drm/bridge: add document for analogix_dp
Hi Heiko,
在 2015/8/24 21:03, Heiko Stuebner 写道:
Hi Yakir,
Am Montag, 24. August 2015, 20:48:01 schrieb Yakir Yang:
在 08/24/2015 12:20 PM, Krzysztof Kozlowski 写道:
On 24.08.2015 11:42, Yakir Yang wrote:
Hi Krzysztof,
在 08/23/2015 07:43 PM, Krzysztof Kozlowski 写道:
2015-08-24 8:23 GMT+09:00 Rob Herring :
On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang wrote:
Analogix dp driver is split from exynos dp driver, so we just
make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
Beside update some exynos dtsi file with the latest change
according to the devicetree binding documents.
You can't just change the exynos bindings and break compatibility. Is
there some agreement with exynos folks to do this?
No, there is no agreement. This wasn't even sent to Exynos maintainers.
Sorry about this one, actually I have add Exynos maintainers in version
1 & version 2,
but lose some maintainers in version 3, I would fix it in bellow
versions.
Additionally the patchset did not look interesting to me because of
misleading subject - Documentation instead of "ARM: dts:".
Yakir, please:
1. Provide backward compatibility. Mark old properties as deprecated
but still support them.
Do you mean that I should keep the old properties declare in
exynos-dp.txt,
but just mark them as deprecated flag.
That is one of ways how to do this. However more important is that
driver should still support old bindings so such code:
- if (of_property_read_u32(dp_node, "samsung,color-space",
+ if (of_property_read_u32(dp_node, "analogix,color-space",
is probably wrong. Will the driver support old DTB in the same way as it
was supporting before the change?
Okay, I got your means. So document is not the focus, the most important
is that
driver should support the old dts prop. If so the new analogix dp driver
should keep
the "samsung,color-space", rather then just mark it with [DEPRECATED] flag.
But from your follow suggest, I think you agree to update driver code,
and just mark
old prop with deprecated flag. If so I think such code would not be wrong
- if (of_property_read_u32(dp_node, "samsung,color-space",
+ if (of_property_read_u32(dp_node, "analogix,color-space",
In a generic driver, the property should have either none, or the analogix
prefix. But DT-properties need to be backwards compatible, meaning an older
Exynos devicetree should run unmodified with a newer kernel.
So the common course of action is to mark the old one as deprecated but still
test for both, so something like:
if (of_property_read_u32(dp_node, "analogix,color-space",
&dp_video_config->color_space))
if (of_property_read_u32(dp_node, "samsung,color-space",
&dp_video_config->color_space)) {
dev_err(dev, "failed to get color-space\n");
return ERR_PTR(-EINVAL);
}
Wow, thanks a lot for your explain and code, it do help me to understand
this suggest rightly :-)
Thanks,
- Yakir
--
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 00/18] ARM: use const and __initconst for smp_operations
Hi Russell, Olof, 2015-08-25 6:44 GMT+09:00 Olof Johansson : > On Mon, Aug 24, 2015 at 2:21 PM, Russell King - ARM Linux > wrote: >> On Mon, Aug 24, 2015 at 02:12:06PM -0700, Olof Johansson wrote: >>> Easiest of all would probably be to get the sub-arch patches into one >>> release, then switch the prototypes and function definitions in the >>> next. If you switch prototypes first you'll get a bunch of warnings, >>> right? >> >> Wrong way around. :) >> >> If you change the sub-arches to declare the smp operations as const, >> and try and pass them into a function which doesn't take a const-pointer, >> you'll get a warning. The core bits need to go in first before the >> sub-arch patches. > > Ah yes, my bad. > >> I think the series has limited value - it allows us to (a) check that a >> small quantity of code doesn't write to these things, and (b) allows us >> to move the SMP operations structure from __initdata to __initconstdata. >> It's still going to end up in the init region which is read/write in any >> case, and still gets thrown away. >> >> Given where we are, I don't think we need to rush this in during the >> last week before the merge window opens, even though it's trivial. > > Agreed. So if you pick it up for 4.4, we'll get the rest for 4.5. > OK. I will put 01 and 02 to Russell's patch tracker (after waiting for a bit more comments just in case). I will do the rest later. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp
On 25.08.2015 10:33, Yakir Yang wrote:
> Hi Krzysztof,
>
> 在 2015/8/25 7:49, Krzysztof Kozlowski 写道:
>> On 24.08.2015 21:48, Yakir Yang wrote:
>>> Hi Krzysztof,
>>>
>>> 在 08/24/2015 12:20 PM, Krzysztof Kozlowski 写道:
On 24.08.2015 11:42, Yakir Yang wrote:
> Hi Krzysztof,
>
> 在 08/23/2015 07:43 PM, Krzysztof Kozlowski 写道:
>> 2015-08-24 8:23 GMT+09:00 Rob Herring :
>>> On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang
>>> wrote:
Analogix dp driver is split from exynos dp driver, so we just
make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
Beside update some exynos dtsi file with the latest change
according to the devicetree binding documents.
>>> You can't just change the exynos bindings and break
>>> compatibility. Is
>>> there some agreement with exynos folks to do this?
>> No, there is no agreement. This wasn't even sent to Exynos
>> maintainers.
> Sorry about this one, actually I have add Exynos maintainers in
> version
> 1 & version 2,
> but lose some maintainers in version 3, I would fix it in bellow
> versions.
>
>> Additionally the patchset did not look interesting to me because of
>> misleading subject - Documentation instead of "ARM: dts:".
>>
>> Yakir, please:
>> 1. Provide backward compatibility. Mark old properties as deprecated
>> but still support them.
> Do you mean that I should keep the old properties declare in
> exynos-dp.txt,
> but just mark them as deprecated flag.
That is one of ways how to do this. However more important is that
driver should still support old bindings so such code:
- if (of_property_read_u32(dp_node, "samsung,color-space",
+ if (of_property_read_u32(dp_node, "analogix,color-space",
is probably wrong. Will the driver support old DTB in the same way
as it
was supporting before the change?
>>> Okay, I got your means. So document is not the focus, the most important
>>> is that
>>> driver should support the old dts prop.
>> Right, the focus is on the driver.
>>
>>> If so the new analogix dp driver
>>> should keep
>>> the "samsung,color-space", rather then just mark it with [DEPRECATED]
>>> flag.
>> If you are replacing a binding/property then it should be marked
>> deprecated. This means that the old property is still working but new
>> users of it should not be added.
>
> Okay, so just quote Heiko's reply, such code would be need in analogix
> dp driver.
>
>if (of_property_read_u32(dp_node, "analogix,color-space",
> &dp_video_config->color_space))
>if (of_property_read_u32(dp_node, "samsung,color-space",
> &dp_video_config->color_space)) {
>
> dev_err(dev, "failed to get color-space\n");
> return ERR_PTR(-EINVAL);
> }
Yes. It does not look pretty but something like this is needed.
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 v3 06/14] Documentation: drm/bridge: add document for analogix_dp
Hi Krzysztof,
在 2015/8/25 7:49, Krzysztof Kozlowski 写道:
On 24.08.2015 21:48, Yakir Yang wrote:
Hi Krzysztof,
在 08/24/2015 12:20 PM, Krzysztof Kozlowski 写道:
On 24.08.2015 11:42, Yakir Yang wrote:
Hi Krzysztof,
在 08/23/2015 07:43 PM, Krzysztof Kozlowski 写道:
2015-08-24 8:23 GMT+09:00 Rob Herring :
On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang
wrote:
Analogix dp driver is split from exynos dp driver, so we just
make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
Beside update some exynos dtsi file with the latest change
according to the devicetree binding documents.
You can't just change the exynos bindings and break compatibility. Is
there some agreement with exynos folks to do this?
No, there is no agreement. This wasn't even sent to Exynos maintainers.
Sorry about this one, actually I have add Exynos maintainers in version
1 & version 2,
but lose some maintainers in version 3, I would fix it in bellow
versions.
Additionally the patchset did not look interesting to me because of
misleading subject - Documentation instead of "ARM: dts:".
Yakir, please:
1. Provide backward compatibility. Mark old properties as deprecated
but still support them.
Do you mean that I should keep the old properties declare in
exynos-dp.txt,
but just mark them as deprecated flag.
That is one of ways how to do this. However more important is that
driver should still support old bindings so such code:
- if (of_property_read_u32(dp_node, "samsung,color-space",
+ if (of_property_read_u32(dp_node, "analogix,color-space",
is probably wrong. Will the driver support old DTB in the same way as it
was supporting before the change?
Okay, I got your means. So document is not the focus, the most important
is that
driver should support the old dts prop.
Right, the focus is on the driver.
If so the new analogix dp driver
should keep
the "samsung,color-space", rather then just mark it with [DEPRECATED] flag.
If you are replacing a binding/property then it should be marked
deprecated. This means that the old property is still working but new
users of it should not be added.
Okay, so just quote Heiko's reply, such code would be need in analogix
dp driver.
if (of_property_read_u32(dp_node, "analogix,color-space",
&dp_video_config->color_space))
if (of_property_read_u32(dp_node, "samsung,color-space",
&dp_video_config->color_space)) {
dev_err(dev, "failed to get color-space\n");
return ERR_PTR(-EINVAL);
}
But from your follow suggest, I think you agree to update driver code,
and just mark
old prop with deprecated flag. If so I think such code would not be wrong
- if (of_property_read_u32(dp_node, "samsung,color-space",
+ if (of_property_read_u32(dp_node, "analogix,color-space",
It looks wrong because it breaks backward compatibility with existing
DTB. As I said before:
1. Provide backward compatibility. Mark old properties
as deprecated but still support them.
And actually @Rob have suggest me to remove the prefix, just use
"color-space" here.
For new bindings I don't mind. But please remember about existing users,
existing DTB and bisectability.
Let me show same examples, make
me understand your suggest rightly.
exynos-dp already contains deprecated properties. Other ways of doing
this would be:
Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
Documentation/devicetree/bindings/rtc/s3c-rtc.txt
It depends up to you. The "touchscreen" looks good because it organizes
old properties in a common section. In case of exynos-dp.txt you can add
at beginning of file information about new bindings and mark everything
deprecated.
Whoops, thanks for your remind, I prefer the "touchscreen" style.
1. "samsung,ycbcr-coeff" is abandoned in latest analogix-dp driver,
absolutely
I should not carry this to analogix-dp.txt document. But I should
keep this in
exynos-dp.txt document, and mark them with an little
"deprecated" flag.
[Documentation/devicetree/bindings/video/exynos_dp.txt]
Required properties for dp-controller:
[...]
-samsung,ycbcr-coeff (DEPRECATED):
YCbCr co-efficients for input video.
COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
Is it right ?
Yes, this is right.
2. Separate all DTS changes to a separate patch, unless bisectability
would be hurt. Anyway you should prepare it in a such way that
separation would be possible without breaking bisectability.
So I should separate this patch into two parts, one is name "Document:",
the other is "ARM: dts: ".
Yes.
Honestly, I don't understand what the "bisectability" means in this
case.
I was referring to bisectability in general. The patchset should be
fully bisectable which means that it does not introduce any issues
during "git bisect". This effectively means that at each intermediate
step (after applying eac
Re: [PATCH v2 3/7] drivers: soc: add support for exynos SROM driver
On 24.08.2015 17:02, Pankaj Dubey wrote:
> This patch adds Exynos SROM controller driver which will handle
> save restore of SROM registers during S2R.
>
> Signed-off-by: Pankaj Dubey
Hi,
Thanks for the fixes. I got some more questions. Sorry that I did not
bring up them before.
> ---
> drivers/soc/Kconfig | 1 +
> drivers/soc/Makefile | 1 +
> drivers/soc/samsung/Kconfig | 13
> drivers/soc/samsung/Makefile | 1 +
> drivers/soc/samsung/exynos-srom.c | 143
> ++
> drivers/soc/samsung/exynos-srom.h | 51 ++
> 6 files changed, 210 insertions(+)
> create mode 100644 drivers/soc/samsung/Kconfig
> create mode 100644 drivers/soc/samsung/Makefile
> create mode 100644 drivers/soc/samsung/exynos-srom.c
> create mode 100644 drivers/soc/samsung/exynos-srom.h
>
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index 96ddecb..69107c9 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -2,6 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
>
> source "drivers/soc/mediatek/Kconfig"
> source "drivers/soc/qcom/Kconfig"
> +source "drivers/soc/samsung/Kconfig"
> source "drivers/soc/sunxi/Kconfig"
> source "drivers/soc/ti/Kconfig"
> source "drivers/soc/versatile/Kconfig"
> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> index 7dc7c0d..34c4398 100644
> --- a/drivers/soc/Makefile
> +++ b/drivers/soc/Makefile
> @@ -4,6 +4,7 @@
>
> obj-$(CONFIG_ARCH_MEDIATEK) += mediatek/
> obj-$(CONFIG_ARCH_QCOM) += qcom/
> +obj-$(CONFIG_SOC_SAMSUNG)+= samsung/
> obj-$(CONFIG_ARCH_SUNXI) += sunxi/
> obj-$(CONFIG_ARCH_TEGRA) += tegra/
> obj-$(CONFIG_SOC_TI) += ti/
> diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
> new file mode 100644
> index 000..ea4bc2a
> --- /dev/null
> +++ b/drivers/soc/samsung/Kconfig
> @@ -0,0 +1,13 @@
> +#
> +# SAMSUNG SoC drivers
> +#
> +menu "Samsung SOC driver support"
> +
> +config SOC_SAMSUNG
> + bool
> +
> +config EXYNOS_SROM
> + bool
> + depends on ARM && ARCH_EXYNOS
> +
> +endmenu
> diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
> new file mode 100644
> index 000..9c554d5
> --- /dev/null
> +++ b/drivers/soc/samsung/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_EXYNOS_SROM)+= exynos-srom.o
> diff --git a/drivers/soc/samsung/exynos-srom.c
> b/drivers/soc/samsung/exynos-srom.c
> new file mode 100644
> index 000..d7c4aa7
> --- /dev/null
> +++ b/drivers/soc/samsung/exynos-srom.c
> @@ -0,0 +1,143 @@
> +/*
> + * Copyright (c) 2015 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com/
> + *
> + * EXYNOS - SROM Controller support
> + * Author: Pankaj Dubey
> + *
> + * 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.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "exynos-srom.h"
> +
> +static void __iomem *exynos_srom_base;
> +
> +static const unsigned long exynos_srom_offsets[] = {
> + /* SROM side */
> + EXYNOS_SROM_BW,
> + EXYNOS_SROM_BC0,
> + EXYNOS_SROM_BC1,
> + EXYNOS_SROM_BC2,
> + EXYNOS_SROM_BC3,
> +};
> +
> +/**
> + * struct exynos_srom_reg_dump: register dump of SROM Controller registers.
> + * @offset: srom register offset from the controller base address.
> + * @value: the value of register under the offset.
> + */
> +struct exynos_srom_reg_dump {
> + u32 offset;
> + u32 value;
> +};
> +
> +static struct exynos_srom_reg_dump *exynos_srom_regs;
> +
> +static struct exynos_srom_reg_dump *exynos_srom_alloc_reg_dump(
> + const unsigned long *rdump,
> + unsigned long nr_rdump)
> +{
> + struct exynos_srom_reg_dump *rd;
> + unsigned int i;
> +
> + rd = kcalloc(nr_rdump, sizeof(*rd), GFP_KERNEL);
> + if (!rd)
> + return NULL;
> +
> + for (i = 0; i < nr_rdump; ++i)
> + rd[i].offset = rdump[i];
> +
> + return rd;
> +}
> +
> +static const struct of_device_id of_exynos_srom_ids[] = {
> + {
> + .compatible = "samsung,exynos-srom",
> + },
> + {},
> +};
> +
> +static int exynos_srom_probe(struct platform_device *pdev)
> +{
> + struct device_node *np;
> + struct device *dev = &pdev->dev;
> +
> + np = dev->of_node;
> + exynos_srom_base = of_iomap(np, 0);
The existing file-scope "exynos_srom_base" would be overwritten for any
consecutive device bind. There shouldn't be more binds than one (there
is only one SROM on board) but still someone may create such DTB. By
mistake or by booting with some newer DTB (where for example two SROMs
would be allowed) with older kernel.
The question is should we handle such case?
E.g.
if (exynos_srom_base)
return -EINVAL; /* Doubled bind */
Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp
在 2015/8/24 22:48, Rob Herring 写道:
On Mon, Aug 24, 2015 at 7:57 AM, Russell King - ARM Linux
wrote:
On Sun, Aug 23, 2015 at 06:23:14PM -0500, Rob Herring wrote:
On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang wrote:
+ -analogix,color-depth:
+ number of bits per colour component.
+ COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
This seems pretty generic. Just use 6, 8, 10, or 12 for values. And
drop the vendor prefix.
Please think about this some more. What does "color-depth" mean? Does it
mean the number of bits per colour _component_, or does it mean the total
number of bits to represent a particular colour. It's confusing as it
stands.
Then "component-color-bpp" perhaps?
Actually this "color-bpp" should come from crtc driver, maybe should
come from
"struct drm_crtc {".
Like rockchip stuffs, analogix_dp-rockchip call an mode_config from
rockchip_drm_vop
driver and set output mode to RGB[10:10:10], then vop driver just store
the output mode
type to the private struct "vop->connecot_out_mode". do think that this
outmode should
store into crtc, not just come from DT prop.
- Yakir
--
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 2/7] ARM: EXYNOS: code cleanup in map.h
On 24.08.2015 17:02, Pankaj Dubey wrote: > Remove unused exynos5440 uart offset macro. > > Signed-off-by: Pankaj Dubey > --- > arch/arm/mach-exynos/include/mach/map.h | 4 > 1 file changed, 4 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
Re: [PATCH v2 1/7] ARM: EXYNOS: remove unused static mapping of CMU for exynos5
On 24.08.2015 17:02, Pankaj Dubey wrote: > Remove unused static mapping of exynos5 CMU and related code. > > Signed-off-by: Pankaj Dubey > --- > arch/arm/mach-exynos/exynos.c | 5 - > arch/arm/mach-exynos/include/mach/map.h | 1 - > 2 files changed, 6 deletions(-) Looks good: 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 v3 06/14] Documentation: drm/bridge: add document for analogix_dp
On 24.08.2015 21:48, Yakir Yang wrote: > Hi Krzysztof, > > 在 08/24/2015 12:20 PM, Krzysztof Kozlowski 写道: >> On 24.08.2015 11:42, Yakir Yang wrote: >>> Hi Krzysztof, >>> >>> 在 08/23/2015 07:43 PM, Krzysztof Kozlowski 写道: 2015-08-24 8:23 GMT+09:00 Rob Herring : > On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang > wrote: >> Analogix dp driver is split from exynos dp driver, so we just >> make an copy of exynos_dp.txt, and then simplify exynos_dp.txt >> >> Beside update some exynos dtsi file with the latest change >> according to the devicetree binding documents. > You can't just change the exynos bindings and break compatibility. Is > there some agreement with exynos folks to do this? No, there is no agreement. This wasn't even sent to Exynos maintainers. >>> Sorry about this one, actually I have add Exynos maintainers in version >>> 1 & version 2, >>> but lose some maintainers in version 3, I would fix it in bellow >>> versions. >>> Additionally the patchset did not look interesting to me because of misleading subject - Documentation instead of "ARM: dts:". Yakir, please: 1. Provide backward compatibility. Mark old properties as deprecated but still support them. >>> Do you mean that I should keep the old properties declare in >>> exynos-dp.txt, >>> but just mark them as deprecated flag. >> That is one of ways how to do this. However more important is that >> driver should still support old bindings so such code: >> - if (of_property_read_u32(dp_node, "samsung,color-space", >> + if (of_property_read_u32(dp_node, "analogix,color-space", >> >> is probably wrong. Will the driver support old DTB in the same way as it >> was supporting before the change? > > Okay, I got your means. So document is not the focus, the most important > is that > driver should support the old dts prop. Right, the focus is on the driver. > If so the new analogix dp driver > should keep > the "samsung,color-space", rather then just mark it with [DEPRECATED] flag. If you are replacing a binding/property then it should be marked deprecated. This means that the old property is still working but new users of it should not be added. > > But from your follow suggest, I think you agree to update driver code, > and just mark > old prop with deprecated flag. If so I think such code would not be wrong > > - if (of_property_read_u32(dp_node, "samsung,color-space", > + if (of_property_read_u32(dp_node, "analogix,color-space", It looks wrong because it breaks backward compatibility with existing DTB. As I said before: >>> 1. Provide backward compatibility. Mark old properties >>> as deprecated but still support them. > And actually @Rob have suggest me to remove the prefix, just use > "color-space" here. For new bindings I don't mind. But please remember about existing users, existing DTB and bisectability. > >> >>> Let me show same examples, make >>> me understand your suggest rightly. >> exynos-dp already contains deprecated properties. Other ways of doing >> this would be: >> Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt >> Documentation/devicetree/bindings/rtc/s3c-rtc.txt >> >> It depends up to you. The "touchscreen" looks good because it organizes >> old properties in a common section. In case of exynos-dp.txt you can add >> at beginning of file information about new bindings and mark everything >> deprecated. > > Whoops, thanks for your remind, I prefer the "touchscreen" style. > >>> 1. "samsung,ycbcr-coeff" is abandoned in latest analogix-dp driver, >>> absolutely >>> I should not carry this to analogix-dp.txt document. But I should >>> keep this in >>> exynos-dp.txt document, and mark them with an little >>> "deprecated" flag. >>> >>> [Documentation/devicetree/bindings/video/exynos_dp.txt] >>> Required properties for dp-controller: >>> [...] >>> -samsung,ycbcr-coeff (DEPRECATED): >>> YCbCr co-efficients for input video. >>> COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1 >>> >>> Is it right ? >> Yes, this is right. >> 2. Separate all DTS changes to a separate patch, unless bisectability would be hurt. Anyway you should prepare it in a such way that separation would be possible without breaking bisectability. >>> So I should separate this patch into two parts, one is name "Document:", >>> the other is "ARM: dts: ". >> Yes. >> >>> Honestly, I don't understand what the "bisectability" means in this >>> case. >> I was referring to bisectability in general. The patchset should be >> fully bisectable which means that it does not introduce any issues >> during "git bisect". This effectively means that at each intermediate >> step (after applying each patch, one by one) every existing stuff works >> the same as previously without any regression. Including booting with >> old DTB. > > Oh, thanks for your careful explain, so I guess your first comment is > talking about >
Re: [PATCH 00/18] ARM: use const and __initconst for smp_operations
On Mon, Aug 24, 2015 at 2:21 PM, Russell King - ARM Linux wrote: > On Mon, Aug 24, 2015 at 02:12:06PM -0700, Olof Johansson wrote: >> Easiest of all would probably be to get the sub-arch patches into one >> release, then switch the prototypes and function definitions in the >> next. If you switch prototypes first you'll get a bunch of warnings, >> right? > > Wrong way around. :) > > If you change the sub-arches to declare the smp operations as const, > and try and pass them into a function which doesn't take a const-pointer, > you'll get a warning. The core bits need to go in first before the > sub-arch patches. Ah yes, my bad. > I think the series has limited value - it allows us to (a) check that a > small quantity of code doesn't write to these things, and (b) allows us > to move the SMP operations structure from __initdata to __initconstdata. > It's still going to end up in the init region which is read/write in any > case, and still gets thrown away. > > Given where we are, I don't think we need to rush this in during the > last week before the merge window opens, even though it's trivial. Agreed. So if you pick it up for 4.4, we'll get the rest for 4.5. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] ARM: use const and __initconst for smp_operations
On Mon, Aug 24, 2015 at 02:12:06PM -0700, Olof Johansson wrote: > Easiest of all would probably be to get the sub-arch patches into one > release, then switch the prototypes and function definitions in the > next. If you switch prototypes first you'll get a bunch of warnings, > right? Wrong way around. :) If you change the sub-arches to declare the smp operations as const, and try and pass them into a function which doesn't take a const-pointer, you'll get a warning. The core bits need to go in first before the sub-arch patches. I think the series has limited value - it allows us to (a) check that a small quantity of code doesn't write to these things, and (b) allows us to move the SMP operations structure from __initdata to __initconstdata. It's still going to end up in the init region which is read/write in any case, and still gets thrown away. Given where we are, I don't think we need to rush this in during the last week before the merge window opens, even though it's trivial. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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 00/18] ARM: use const and __initconst for smp_operations
On Sun, Aug 23, 2015 at 9:36 PM, Masahiro Yamada wrote: > > Currently, SoC code can not add const qualifier to smp_operations > structures although they are never over-written. > > 01/18 and 02/18 add small changes to the ARM core to fix that. > The rest of this series replace "__initdata" with "const ... __initconst" > for each of SoC code. > > I split this series into per-SoC so that each sub-arch maintainer > can easily give their Acked-by. (Is this better?) When you split, chances are each sub-arch maintainer will apply instead of ack. If that's what you want, that's fine. > Russell, Olof, and Arnd: > > How should this series be applied (if it looks good)? > The first two are ARM-tree wide and looks like in the field of Russell. > The rest are highly SoC-related. Easiest of all would probably be to get the sub-arch patches into one release, then switch the prototypes and function definitions in the next. If you switch prototypes first you'll get a bunch of warnings, right? -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp
Am Montag, 24. August 2015, 09:48:27 schrieb Rob Herring: > On Mon, Aug 24, 2015 at 7:57 AM, Russell King - ARM Linux > > When we adopted the graph bindings for iMX DRM, I thought exactly at that > > time "it would be nice if this could become the standard for binding DRM > > components together" but I don't have the authority from either the DT > > perspective or the DRM perspective to mandate that. Neither does anyone > > else. That's the _real_ problem here. > > > > I've seen several DRM bindings go by which don't use the of-graph stuff, > > which means that they'll never be compatible with generic components > > which do use the of-graph stuff. > > It goes beyond bindings IMO. The use of the component framework or not > has been at the whim of driver writers as well. It is either used or > private APIs are created. I'm using components and my need for it > boils down to passing the struct drm_device pointer to the encoder. > Other components like panels and bridges have different ways to attach > to the DRM driver. but that is then simply implementation specific. Panels and bridges can very well be part of and created from an of_graph description without needing to be a (linux-)component - see patch 7. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp
On Mon, Aug 24, 2015 at 7:57 AM, Russell King - ARM Linux wrote: > On Sun, Aug 23, 2015 at 06:23:14PM -0500, Rob Herring wrote: >> On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang wrote: >> > + -analogix,color-depth: >> > + number of bits per colour component. >> > + COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = >> > 3 >> >> This seems pretty generic. Just use 6, 8, 10, or 12 for values. And >> drop the vendor prefix. > > Please think about this some more. What does "color-depth" mean? Does it > mean the number of bits per colour _component_, or does it mean the total > number of bits to represent a particular colour. It's confusing as it > stands. Then "component-color-bpp" perhaps? > >> > +Optional properties for dp-controller: >> > + -analogix,hpd-gpio: >> > + Hotplug detect GPIO. >> > + Indicates which GPIO should be used for hotplug >> > + detection >> >> We should align with "hpd-gpios" used by HDMI connector binding. Or do >> we need a DP connector binding that this should be defined in? >> Probably so. >> >> The DRM related bindings are such a cluster f*ck with everyone picking >> their own way to do things. Just grep hpd in bindings for starters. >> That is just the tip. > > I'm not surprised one iota that DRM bindings are a mess. There's no one > overlooking the adoption of DRM bindings, so surprise surprise, everyone > does their own thing. This is exactly what happens every time in that > scenario. It's not a new problem. True. > When we adopted the graph bindings for iMX DRM, I thought exactly at that > time "it would be nice if this could become the standard for binding DRM > components together" but I don't have the authority from either the DT > perspective or the DRM perspective to mandate that. Neither does anyone > else. That's the _real_ problem here. > > I've seen several DRM bindings go by which don't use the of-graph stuff, > which means that they'll never be compatible with generic components > which do use the of-graph stuff. It goes beyond bindings IMO. The use of the component framework or not has been at the whim of driver writers as well. It is either used or private APIs are created. I'm using components and my need for it boils down to passing the struct drm_device pointer to the encoder. Other components like panels and bridges have different ways to attach to the DRM driver. > Like you say, it's a mess, but it's a mess of our own making, because no > one has the authority to regulate this. Certainly, and I will take some blame here. We deferred a lot of binding review to subsystem maintainers with the directive to ask for help when needed. The latter has not happened. We need to improve the situation here before we end up with a bigger mess. The momentum to use DRM on Android is growing, so the problem is only going to get worse if we do nothing. 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
[PATCH 14/14] exynos/fimg2d: remove g2d_context from public header
All functions from the public API only operation on
struct g2d_context*, so this shouldn't break too much.
Make the context private since we don't want the
user to modify its content directly. Also remove
the defines that were only used for fields of
g2d_context.
Signed-off-by: Tobias Jakobi
---
exynos/exynos_fimg2d.c | 15 +++
exynos/exynos_fimg2d.h | 14 +-
2 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index 91df441..00019e9 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -44,6 +44,21 @@
#define MSG_PREFIX "exynos/fimg2d: "
+#define G2D_MAX_CMD_NR 64
+#define G2D_MAX_GEM_CMD_NR 64
+#define G2D_MAX_CMD_LIST_NR64
+
+struct g2d_context {
+ int fd;
+ unsigned intmajor;
+ unsigned intminor;
+ struct drm_exynos_g2d_cmd cmd[G2D_MAX_CMD_NR];
+ struct drm_exynos_g2d_cmd cmd_buf[G2D_MAX_GEM_CMD_NR];
+ unsigned intcmd_nr;
+ unsigned intcmd_buf_nr;
+ unsigned intcmdlist_nr;
+};
+
enum g2d_base_addr_reg {
g2d_dst = 0,
g2d_src
diff --git a/exynos/exynos_fimg2d.h b/exynos/exynos_fimg2d.h
index 9db0c88..4aa1568 100644
--- a/exynos/exynos_fimg2d.h
+++ b/exynos/exynos_fimg2d.h
@@ -13,9 +13,6 @@
#ifndef _FIMG2D_H_
#define _FIMG2D_H_
-#define G2D_MAX_CMD_NR 64
-#define G2D_MAX_GEM_CMD_NR 64
-#define G2D_MAX_CMD_LIST_NR64
#define G2D_PLANE_MAX_NR 2
enum e_g2d_color_mode {
@@ -289,16 +286,7 @@ struct g2d_image {
void*mapped_ptr[G2D_PLANE_MAX_NR];
};
-struct g2d_context {
- int fd;
- unsigned intmajor;
- unsigned intminor;
- struct drm_exynos_g2d_cmd cmd[G2D_MAX_CMD_NR];
- struct drm_exynos_g2d_cmd cmd_buf[G2D_MAX_GEM_CMD_NR];
- unsigned intcmd_nr;
- unsigned intcmd_buf_nr;
- unsigned intcmdlist_nr;
-};
+struct g2d_context;
struct g2d_context *g2d_init(int fd);
void g2d_fini(struct g2d_context *ctx);
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/14] exynos/fimg2d: simplify base address submission in g2d_scale_and_blend()
Use g2d_add_base_addr() for source and destination base
address just like all other calls.
Signed-off-by: Tobias Jakobi
---
exynos/exynos_fimg2d.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index 4a88e0c..85b2317 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -672,12 +672,7 @@ g2d_scale_and_blend(struct g2d_context *ctx, struct
g2d_image *src,
g2d_add_cmd(ctx, DST_SELECT_REG, G2D_SELECT_MODE_NORMAL);
g2d_add_cmd(ctx, DST_COLOR_MODE_REG, dst->color_mode);
- if (dst->buf_type == G2D_IMGBUF_USERPTR)
- g2d_add_cmd(ctx, DST_BASE_ADDR_REG | G2D_BUF_USERPTR,
- (unsigned long)&dst->user_ptr[0]);
- else
- g2d_add_cmd(ctx, DST_BASE_ADDR_REG, dst->bo[0]);
-
+ g2d_add_base_addr(ctx, dst, g2d_dst);
g2d_add_cmd(ctx, DST_STRIDE_REG, dst->stride);
g2d_add_cmd(ctx, SRC_SELECT_REG, src->select_mode);
@@ -685,12 +680,7 @@ g2d_scale_and_blend(struct g2d_context *ctx, struct
g2d_image *src,
switch (src->select_mode) {
case G2D_SELECT_MODE_NORMAL:
- if (src->buf_type == G2D_IMGBUF_USERPTR)
- g2d_add_cmd(ctx, SRC_BASE_ADDR_REG | G2D_BUF_USERPTR,
- (unsigned long)&src->user_ptr[0]);
- else
- g2d_add_cmd(ctx, SRC_BASE_ADDR_REG, src->bo[0]);
-
+ g2d_add_base_addr(ctx, src, g2d_src);
g2d_add_cmd(ctx, SRC_STRIDE_REG, src->stride);
break;
case G2D_SELECT_MODE_FGCOLOR:
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/14] exynos/fimg2d: check buffer space in g2d_scale_and_blend()
Apply the same transformation as in g2d_blend().
Signed-off-by: Tobias Jakobi
---
exynos/exynos_fimg2d.c | 67 +-
1 file changed, 39 insertions(+), 28 deletions(-)
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index 5acccf8..4274a94 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -745,9 +745,47 @@ g2d_scale_and_blend(struct g2d_context *ctx, struct
g2d_image *src,
union g2d_point_val pt;
union g2d_bitblt_cmd_val bitblt;
union g2d_blend_func_val blend;
- unsigned int scale;
+ unsigned int scale, gem_space;
unsigned int scale_x, scale_y;
+ if (src_w == dst_w && src_h == dst_h)
+ scale = 0;
+ else {
+ scale = 1;
+ scale_x = g2d_get_scaling(src_w, dst_w);
+ scale_y = g2d_get_scaling(src_h, dst_h);
+ }
+
+ if (src_x + src_w > src->width)
+ src_w = src->width - src_x;
+ if (src_y + src_h > src->height)
+ src_h = src->height - src_y;
+
+ if (dst_x + dst_w > dst->width)
+ dst_w = dst->width - dst_x;
+ if (dst_y + dst_h > dst->height)
+ dst_h = dst->height - dst_y;
+
+ if (src_w <= 0 || src_h <= 0 || dst_w <= 0 || dst_h <= 0) {
+ fprintf(stderr, "invalid width or height.\n");
+ return -EINVAL;
+ }
+
+ if (g2d_validate_select_mode(src->select_mode)) {
+ fprintf(stderr , "invalid select mode for source.\n");
+ return -EINVAL;
+ }
+
+ if (g2d_validate_blending_op(op)) {
+ fprintf(stderr , "unsupported blending operation.\n");
+ return -EINVAL;
+ }
+
+ gem_space = src->select_mode == G2D_SELECT_MODE_NORMAL ? 2 : 1;
+
+ if (g2d_check_space(ctx, 12 + scale * 3, gem_space))
+ return -ENOSPC;
+
bitblt.val = 0;
blend.val = 0;
@@ -774,33 +812,6 @@ g2d_scale_and_blend(struct g2d_context *ctx, struct
g2d_image *src,
case G2D_SELECT_MODE_BGCOLOR:
g2d_add_cmd(ctx, BG_COLOR_REG, src->color);
break;
- default:
- fprintf(stderr , "failed to set src.\n");
- return -EINVAL;
- }
-
- if (src_w == dst_w && src_h == dst_h)
- scale = 0;
- else {
- scale = 1;
- scale_x = g2d_get_scaling(src_w, dst_w);
- scale_y = g2d_get_scaling(src_h, dst_h);
- }
-
- if (src_x + src_w > src->width)
- src_w = src->width - src_x;
- if (src_y + src_h > src->height)
- src_h = src->height - src_y;
-
- if (dst_x + dst_w > dst->width)
- dst_w = dst->width - dst_x;
- if (dst_y + dst_h > dst->height)
- dst_h = dst->height - dst_y;
-
- if (src_w <= 0 || src_h <= 0 || dst_w <= 0 || dst_h <= 0) {
- fprintf(stderr, "invalid width or height.\n");
- g2d_reset(ctx);
- return -EINVAL;
}
if (scale) {
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/14] exynos/fimg2d: remove superfluous initialization of g2d_point_val
The g2d_point_val union consists of two coordinates of 16 bits. Whenever this union is used though, both coordinates are explicitly set. Hence prior initialization is unnecessary. Signed-off-by: Tobias Jakobi --- exynos/exynos_fimg2d.c | 19 --- 1 file changed, 19 deletions(-) diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c index d708e91..acde645 100644 --- a/exynos/exynos_fimg2d.c +++ b/exynos/exynos_fimg2d.c @@ -371,15 +371,12 @@ g2d_solid_fill(struct g2d_context *ctx, struct g2d_image *img, if (y + h > img->height) h = img->height - y; - pt.val = 0; pt.data.x = x; pt.data.y = y; g2d_add_cmd(ctx, DST_LEFT_TOP_REG, pt.val); - pt.val = 0; pt.data.x = x + w; pt.data.y = y + h; - g2d_add_cmd(ctx, DST_RIGHT_BOTTOM_REG, pt.val); g2d_add_cmd(ctx, SF_COLOR_REG, img->color); @@ -451,20 +448,16 @@ g2d_copy(struct g2d_context *ctx, struct g2d_image *src, g2d_add_base_addr(ctx, src, g2d_src); g2d_add_cmd(ctx, SRC_STRIDE_REG, src->stride); - pt.val = 0; pt.data.x = src_x; pt.data.y = src_y; g2d_add_cmd(ctx, SRC_LEFT_TOP_REG, pt.val); - pt.val = 0; pt.data.x = src_x + w; pt.data.y = src_y + h; g2d_add_cmd(ctx, SRC_RIGHT_BOTTOM_REG, pt.val); - pt.val = 0; pt.data.x = dst_x; pt.data.y = dst_y; g2d_add_cmd(ctx, DST_LEFT_TOP_REG, pt.val); - pt.val = 0; pt.data.x = dst_x + w; pt.data.y = dst_y + h; g2d_add_cmd(ctx, DST_RIGHT_BOTTOM_REG, pt.val); @@ -572,20 +565,16 @@ g2d_copy_with_scale(struct g2d_context *ctx, struct g2d_image *src, g2d_add_cmd(ctx, SRC_YSCALE_REG, scale_y); } - pt.val = 0; pt.data.x = src_x; pt.data.y = src_y; g2d_add_cmd(ctx, SRC_LEFT_TOP_REG, pt.val); - pt.val = 0; pt.data.x = src_x + src_w; pt.data.y = src_y + src_h; g2d_add_cmd(ctx, SRC_RIGHT_BOTTOM_REG, pt.val); - pt.val = 0; pt.data.x = dst_x; pt.data.y = dst_y; g2d_add_cmd(ctx, DST_LEFT_TOP_REG, pt.val); - pt.val = 0; pt.data.x = dst_x + dst_w; pt.data.y = dst_y + dst_h; g2d_add_cmd(ctx, DST_RIGHT_BOTTOM_REG, pt.val); @@ -691,20 +680,16 @@ g2d_blend(struct g2d_context *ctx, struct g2d_image *src, g2d_add_cmd(ctx, BITBLT_COMMAND_REG, bitblt.val); g2d_add_cmd(ctx, BLEND_FUNCTION_REG, blend.val); - pt.val = 0; pt.data.x = src_x; pt.data.y = src_y; g2d_add_cmd(ctx, SRC_LEFT_TOP_REG, pt.val); - pt.val = 0; pt.data.x = src_x + w; pt.data.y = src_y + h; g2d_add_cmd(ctx, SRC_RIGHT_BOTTOM_REG, pt.val); - pt.val = 0; pt.data.x = dst_x; pt.data.y = dst_y; g2d_add_cmd(ctx, DST_LEFT_TOP_REG, pt.val); - pt.val = 0; pt.data.x = dst_x + w; pt.data.y = dst_y + h; g2d_add_cmd(ctx, DST_RIGHT_BOTTOM_REG, pt.val); @@ -820,20 +805,16 @@ g2d_scale_and_blend(struct g2d_context *ctx, struct g2d_image *src, g2d_add_cmd(ctx, BITBLT_COMMAND_REG, bitblt.val); g2d_add_cmd(ctx, BLEND_FUNCTION_REG, blend.val); - pt.val = 0; pt.data.x = src_x; pt.data.y = src_y; g2d_add_cmd(ctx, SRC_LEFT_TOP_REG, pt.val); - pt.val = 0; pt.data.x = src_x + src_w; pt.data.y = src_y + src_h; g2d_add_cmd(ctx, SRC_RIGHT_BOTTOM_REG, pt.val); - pt.val = 0; pt.data.x = dst_x; pt.data.y = dst_y; g2d_add_cmd(ctx, DST_LEFT_TOP_REG, pt.val); - pt.val = 0; pt.data.x = dst_x + dst_w; pt.data.y = dst_y + dst_h; g2d_add_cmd(ctx, DST_RIGHT_BOTTOM_REG, pt.val); -- 2.0.5 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/14] exynos/fimg2d: remove default case from g2d_get_blend_op()
We now validate the blending mode via g2d_validate_mode() prior to feeding it to g2d_get_blend_op(). Signed-off-by: Tobias Jakobi --- exynos/exynos_fimg2d.c | 5 - 1 file changed, 5 deletions(-) diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c index 4274a94..d708e91 100644 --- a/exynos/exynos_fimg2d.c +++ b/exynos/exynos_fimg2d.c @@ -91,11 +91,6 @@ static unsigned int g2d_get_blend_op(enum e_g2d_op op) SET_BF(val, G2D_COEFF_MODE_SRC_ALPHA, 0, 0, 0, G2D_COEFF_MODE_SRC_ALPHA, 1, 0, 0); break; - default: - fprintf(stderr, "Not support operation(%d).\n", op); - SET_BF(val, G2D_COEFF_MODE_ONE, 0, 0, 0, G2D_COEFF_MODE_ZERO, - 0, 0, 0); - break; } return val.val; -- 2.0.5 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/14] exynos/fimg2d: make g2d_add_cmd() less heavy
The function currently checks for each added command
if an overflow of the corresponding command buffers
occurs, but none of the callers ever checks the
return value.
Since all callers are now converted to use
g2d_check_space() simplify the function.
(1) The overflow checks become asserts, so they're only
active for debug builds. This is fine since
g2d_add_cmd() is not part of the public API.
(2) Switch the return value to void.
(3) Explicitly state that the caller has to check
buffer space before calling g2d_add_cmd().
Signed-off-by: Tobias Jakobi
---
exynos/exynos_fimg2d.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index acde645..ad44998 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
@@ -163,8 +164,11 @@ static unsigned int g2d_validate_blending_op(
* @ctx: a pointer to g2d_context structure.
* @cmd: command data.
* @value: value data.
+ *
+ * The caller has to make sure that the commands buffers have enough space
+ * left to hold the command. Use g2d_check_space() to ensure this.
*/
-static int g2d_add_cmd(struct g2d_context *ctx, unsigned long cmd,
+static void g2d_add_cmd(struct g2d_context *ctx, unsigned long cmd,
unsigned long value)
{
switch (cmd & ~(G2D_BUF_USERPTR)) {
@@ -174,28 +178,20 @@ static int g2d_add_cmd(struct g2d_context *ctx, unsigned
long cmd,
case DST_PLANE2_BASE_ADDR_REG:
case PAT_BASE_ADDR_REG:
case MASK_BASE_ADDR_REG:
- if (ctx->cmd_buf_nr >= G2D_MAX_GEM_CMD_NR) {
- fprintf(stderr, "Overflow cmd_gem size.\n");
- return -EINVAL;
- }
+ assert(ctx->cmd_buf_nr < G2D_MAX_GEM_CMD_NR);
ctx->cmd_buf[ctx->cmd_buf_nr].offset = cmd;
ctx->cmd_buf[ctx->cmd_buf_nr].data = value;
ctx->cmd_buf_nr++;
break;
default:
- if (ctx->cmd_nr >= G2D_MAX_CMD_NR) {
- fprintf(stderr, "Overflow cmd size.\n");
- return -EINVAL;
- }
+ assert(ctx->cmd_nr < G2D_MAX_CMD_NR);
ctx->cmd[ctx->cmd_nr].offset = cmd;
ctx->cmd[ctx->cmd_nr].data = value;
ctx->cmd_nr++;
break;
}
-
- return 0;
}
/*
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/14] exynos/fimg2d: add message prefix
Add a prefix to the messages printed to the console via
printf() and fprintf() so that one can easily see where
the message comes from.
Signed-off-by: Tobias Jakobi
---
exynos/exynos_fimg2d.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index ad44998..91df441 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -42,6 +42,8 @@
#define MIN(a, b) ((a) < (b) ? (a) : (b))
+#define MSG_PREFIX "exynos/fimg2d: "
+
enum g2d_base_addr_reg {
g2d_dst = 0,
g2d_src
@@ -246,7 +248,7 @@ static int g2d_flush(struct g2d_context *ctx)
return 0;
if (ctx->cmdlist_nr >= G2D_MAX_CMD_LIST_NR) {
- fprintf(stderr, "Overflow cmdlist.\n");
+ fprintf(stderr, MSG_PREFIX "command list overflow.\n");
return -EINVAL;
}
@@ -262,7 +264,7 @@ static int g2d_flush(struct g2d_context *ctx)
ret = drmIoctl(ctx->fd, DRM_IOCTL_EXYNOS_G2D_SET_CMDLIST, &cmdlist);
if (ret < 0) {
- fprintf(stderr, "failed to set cmdlist.\n");
+ fprintf(stderr, MSG_PREFIX "failed to set cmdlist.\n");
return ret;
}
@@ -284,7 +286,7 @@ struct g2d_context *g2d_init(int fd)
ctx = calloc(1, sizeof(*ctx));
if (!ctx) {
- fprintf(stderr, "failed to allocate context.\n");
+ fprintf(stderr, MSG_PREFIX "failed to allocate context.\n");
return NULL;
}
@@ -292,7 +294,7 @@ struct g2d_context *g2d_init(int fd)
ret = drmIoctl(fd, DRM_IOCTL_EXYNOS_G2D_GET_VER, &ver);
if (ret < 0) {
- fprintf(stderr, "failed to get version.\n");
+ fprintf(stderr, MSG_PREFIX "failed to get version.\n");
free(ctx);
return NULL;
}
@@ -300,7 +302,7 @@ struct g2d_context *g2d_init(int fd)
ctx->major = ver.major;
ctx->minor = ver.minor;
- printf("g2d version(%d.%d).\n", ctx->major, ctx->minor);
+ printf(MSG_PREFIX "G2D version (%d.%d).\n", ctx->major, ctx->minor);
return ctx;
}
@@ -326,7 +328,7 @@ int g2d_exec(struct g2d_context *ctx)
ret = drmIoctl(ctx->fd, DRM_IOCTL_EXYNOS_G2D_EXEC, &exec);
if (ret < 0) {
- fprintf(stderr, "failed to execute.\n");
+ fprintf(stderr, MSG_PREFIX "failed to execute.\n");
return ret;
}
@@ -427,7 +429,7 @@ g2d_copy(struct g2d_context *ctx, struct g2d_image *src,
h = MIN(src_h, dst_h);
if (w <= 0 || h <= 0) {
- fprintf(stderr, "invalid width or height.\n");
+ fprintf(stderr, MSG_PREFIX "invalid width or height.\n");
return -EINVAL;
}
@@ -523,7 +525,7 @@ g2d_copy_with_scale(struct g2d_context *ctx, struct
g2d_image *src,
dst_h = dst->height - dst_y;
if (src_w <= 0 || src_h <= 0 || dst_w <= 0 || dst_h <= 0) {
- fprintf(stderr, "invalid width or height.\n");
+ fprintf(stderr, MSG_PREFIX "invalid width or height.\n");
return -EINVAL;
}
@@ -624,17 +626,17 @@ g2d_blend(struct g2d_context *ctx, struct g2d_image *src,
h = MIN(src_h, dst_h);
if (w <= 0 || h <= 0) {
- fprintf(stderr, "invalid width or height.\n");
+ fprintf(stderr, MSG_PREFIX "invalid width or height.\n");
return -EINVAL;
}
if (g2d_validate_select_mode(src->select_mode)) {
- fprintf(stderr , "invalid select mode for source.\n");
+ fprintf(stderr , MSG_PREFIX "invalid select mode for
source.\n");
return -EINVAL;
}
if (g2d_validate_blending_op(op)) {
- fprintf(stderr , "unsupported blending operation.\n");
+ fprintf(stderr , MSG_PREFIX "unsupported blending
operation.\n");
return -EINVAL;
}
@@ -743,17 +745,17 @@ g2d_scale_and_blend(struct g2d_context *ctx, struct
g2d_image *src,
dst_h = dst->height - dst_y;
if (src_w <= 0 || src_h <= 0 || dst_w <= 0 || dst_h <= 0) {
- fprintf(stderr, "invalid width or height.\n");
+ fprintf(stderr, MSG_PREFIX "invalid width or height.\n");
return -EINVAL;
}
if (g2d_validate_select_mode(src->select_mode)) {
- fprintf(stderr , "invalid select mode for source.\n");
+ fprintf(stderr , MSG_PREFIX "invalid select mode for
source.\n");
return -EINVAL;
}
if (g2d_validate_blending_op(op)) {
- fprintf(stderr , "unsupported blending operation.\n");
+ fprintf(stderr , MSG_PREFIX "unsupported blending
operation.\n");
return -EINVAL;
}
--
2.0.5
--
To unsubscribe from this list: send the line "unsu
[PATCH 06/14] exynos/fimg2d: check buffer space in g2d_copy_with_scale()
Parameter validation goes to the top. Repeat mode is
checked first to make computation of space easier.
Signed-off-by: Tobias Jakobi
---
exynos/exynos_fimg2d.c | 53 --
1 file changed, 30 insertions(+), 23 deletions(-)
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index 185aa80..2e04f4a 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -467,23 +467,12 @@ g2d_copy_with_scale(struct g2d_context *ctx, struct
g2d_image *src,
{
union g2d_rop4_val rop4;
union g2d_point_val pt;
- unsigned int scale;
+ unsigned int scale, repeat_pad;
unsigned int scale_x, scale_y;
- g2d_add_cmd(ctx, DST_SELECT_REG, G2D_SELECT_MODE_BGCOLOR);
- g2d_add_cmd(ctx, DST_COLOR_MODE_REG, dst->color_mode);
- g2d_add_base_addr(ctx, dst, g2d_dst);
- g2d_add_cmd(ctx, DST_STRIDE_REG, dst->stride);
-
- g2d_add_cmd(ctx, SRC_SELECT_REG, G2D_SELECT_MODE_NORMAL);
- g2d_add_cmd(ctx, SRC_COLOR_MODE_REG, src->color_mode);
-
- g2d_add_cmd(ctx, SRC_REPEAT_MODE_REG, src->repeat_mode);
- if (src->repeat_mode == G2D_REPEAT_MODE_PAD)
- g2d_add_cmd(ctx, SRC_PAD_VALUE_REG, dst->color);
-
- g2d_add_base_addr(ctx, src, g2d_src);
- g2d_add_cmd(ctx, SRC_STRIDE_REG, src->stride);
+ /* Sanitize this parameter to facilitate space computation below. */
+ if (negative)
+ negative = 1;
if (src_w == dst_w && src_h == dst_h)
scale = 0;
@@ -493,6 +482,8 @@ g2d_copy_with_scale(struct g2d_context *ctx, struct
g2d_image *src,
scale_y = g2d_get_scaling(src_h, dst_h);
}
+ repeat_pad = src->repeat_mode == G2D_REPEAT_MODE_PAD ? 1 : 0;
+
if (src_x + src_w > src->width)
src_w = src->width - src_x;
if (src_y + src_h > src->height)
@@ -505,21 +496,37 @@ g2d_copy_with_scale(struct g2d_context *ctx, struct
g2d_image *src,
if (src_w <= 0 || src_h <= 0 || dst_w <= 0 || dst_h <= 0) {
fprintf(stderr, "invalid width or height.\n");
- g2d_reset(ctx);
return -EINVAL;
}
+ if (g2d_check_space(ctx, 12 + scale * 3 + negative + repeat_pad, 2))
+ return -ENOSPC;
+
+ g2d_add_cmd(ctx, DST_SELECT_REG, G2D_SELECT_MODE_BGCOLOR);
+ g2d_add_cmd(ctx, DST_COLOR_MODE_REG, dst->color_mode);
+ g2d_add_base_addr(ctx, dst, g2d_dst);
+ g2d_add_cmd(ctx, DST_STRIDE_REG, dst->stride);
+
+ g2d_add_cmd(ctx, SRC_SELECT_REG, G2D_SELECT_MODE_NORMAL);
+ g2d_add_cmd(ctx, SRC_COLOR_MODE_REG, src->color_mode);
+
+ g2d_add_cmd(ctx, SRC_REPEAT_MODE_REG, src->repeat_mode);
+ if (repeat_pad)
+ g2d_add_cmd(ctx, SRC_PAD_VALUE_REG, dst->color);
+
+ g2d_add_base_addr(ctx, src, g2d_src);
+ g2d_add_cmd(ctx, SRC_STRIDE_REG, src->stride);
+
+ rop4.val = 0;
+ rop4.data.unmasked_rop3 = G2D_ROP3_SRC;
+
if (negative) {
g2d_add_cmd(ctx, BG_COLOR_REG, 0x00FF);
- rop4.val = 0;
- rop4.data.unmasked_rop3 = G2D_ROP3_SRC^G2D_ROP3_DST;
- g2d_add_cmd(ctx, ROP4_REG, rop4.val);
- } else {
- rop4.val = 0;
- rop4.data.unmasked_rop3 = G2D_ROP3_SRC;
- g2d_add_cmd(ctx, ROP4_REG, rop4.val);
+ rop4.data.unmasked_rop3 ^= G2D_ROP3_DST;
}
+ g2d_add_cmd(ctx, ROP4_REG, rop4.val);
+
if (scale) {
g2d_add_cmd(ctx, SRC_SCALE_CTRL_REG, G2D_SCALE_MODE_BILINEAR);
g2d_add_cmd(ctx, SRC_XSCALE_REG, scale_x);
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/14] exynos/fimg2d: check buffer space in g2d_blend()
Move parameter validation to the top and also validate
the select mode of the source image and the requested
blending operation before starting command submission.
Signed-off-by: Tobias Jakobi
---
exynos/exynos_fimg2d.c | 66 +-
1 file changed, 39 insertions(+), 27 deletions(-)
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index 781aff5..5acccf8 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -623,7 +623,45 @@ g2d_blend(struct g2d_context *ctx, struct g2d_image *src,
union g2d_point_val pt;
union g2d_bitblt_cmd_val bitblt;
union g2d_blend_func_val blend;
- unsigned int src_w = 0, src_h = 0, dst_w = 0, dst_h = 0;
+ unsigned int gem_space;
+ unsigned int src_w, src_h, dst_w, dst_h;
+
+ src_w = w;
+ src_h = h;
+ if (src_x + w > src->width)
+ src_w = src->width - src_x;
+ if (src_y + h > src->height)
+ src_h = src->height - src_y;
+
+ dst_w = w;
+ dst_h = h;
+ if (dst_x + w > dst->width)
+ dst_w = dst->width - dst_x;
+ if (dst_y + h > dst->height)
+ dst_h = dst->height - dst_y;
+
+ w = MIN(src_w, dst_w);
+ h = MIN(src_h, dst_h);
+
+ if (w <= 0 || h <= 0) {
+ fprintf(stderr, "invalid width or height.\n");
+ return -EINVAL;
+ }
+
+ if (g2d_validate_select_mode(src->select_mode)) {
+ fprintf(stderr , "invalid select mode for source.\n");
+ return -EINVAL;
+ }
+
+ if (g2d_validate_blending_op(op)) {
+ fprintf(stderr , "unsupported blending operation.\n");
+ return -EINVAL;
+ }
+
+ gem_space = src->select_mode == G2D_SELECT_MODE_NORMAL ? 2 : 1;
+
+ if (g2d_check_space(ctx, 12, gem_space))
+ return -ENOSPC;
bitblt.val = 0;
blend.val = 0;
@@ -651,32 +689,6 @@ g2d_blend(struct g2d_context *ctx, struct g2d_image *src,
case G2D_SELECT_MODE_BGCOLOR:
g2d_add_cmd(ctx, BG_COLOR_REG, src->color);
break;
- default:
- fprintf(stderr , "failed to set src.\n");
- return -EINVAL;
- }
-
- src_w = w;
- src_h = h;
- if (src_x + w > src->width)
- src_w = src->width - src_x;
- if (src_y + h > src->height)
- src_h = src->height - src_y;
-
- dst_w = w;
- dst_h = h;
- if (dst_x + w > dst->width)
- dst_w = dst->width - dst_x;
- if (dst_y + h > dst->height)
- dst_h = dst->height - dst_y;
-
- w = MIN(src_w, dst_w);
- h = MIN(src_h, dst_h);
-
- if (w <= 0 || h <= 0) {
- fprintf(stderr, "invalid width or height.\n");
- g2d_reset(ctx);
- return -EINVAL;
}
bitblt.data.alpha_blend_mode = G2D_ALPHA_BLEND_MODE_ENABLE;
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/14] exynos/fimg2d: check buffer space in g2d_copy()
Move the parameter validation before buffer space checking
so that we can exit early if it fails.
Also don't reset the G2D context anymore in this situation
(since the buffers are not partially submitted).
Signed-off-by: Tobias Jakobi
---
exynos/exynos_fimg2d.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index 9b7bcce..185aa80 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -375,17 +375,7 @@ g2d_copy(struct g2d_context *ctx, struct g2d_image *src,
{
union g2d_rop4_val rop4;
union g2d_point_val pt;
- unsigned int src_w = 0, src_h = 0, dst_w = 0, dst_h = 0;
-
- g2d_add_cmd(ctx, DST_SELECT_REG, G2D_SELECT_MODE_BGCOLOR);
- g2d_add_cmd(ctx, DST_COLOR_MODE_REG, dst->color_mode);
- g2d_add_base_addr(ctx, dst, g2d_dst);
- g2d_add_cmd(ctx, DST_STRIDE_REG, dst->stride);
-
- g2d_add_cmd(ctx, SRC_SELECT_REG, G2D_SELECT_MODE_NORMAL);
- g2d_add_cmd(ctx, SRC_COLOR_MODE_REG, src->color_mode);
- g2d_add_base_addr(ctx, src, g2d_src);
- g2d_add_cmd(ctx, SRC_STRIDE_REG, src->stride);
+ unsigned int src_w, src_h, dst_w, dst_h;
src_w = w;
src_h = h;
@@ -406,10 +396,22 @@ g2d_copy(struct g2d_context *ctx, struct g2d_image *src,
if (w <= 0 || h <= 0) {
fprintf(stderr, "invalid width or height.\n");
- g2d_reset(ctx);
return -EINVAL;
}
+ if (g2d_check_space(ctx, 11, 2))
+ return -ENOSPC;
+
+ g2d_add_cmd(ctx, DST_SELECT_REG, G2D_SELECT_MODE_BGCOLOR);
+ g2d_add_cmd(ctx, DST_COLOR_MODE_REG, dst->color_mode);
+ g2d_add_base_addr(ctx, dst, g2d_dst);
+ g2d_add_cmd(ctx, DST_STRIDE_REG, dst->stride);
+
+ g2d_add_cmd(ctx, SRC_SELECT_REG, G2D_SELECT_MODE_NORMAL);
+ g2d_add_cmd(ctx, SRC_COLOR_MODE_REG, src->color_mode);
+ g2d_add_base_addr(ctx, src, g2d_src);
+ g2d_add_cmd(ctx, SRC_STRIDE_REG, src->stride);
+
pt.val = 0;
pt.data.x = src_x;
pt.data.y = src_y;
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/14] exynos/fimg2d: add g2d_validate_xyz() functions
The G2D headers define a number of modes through enums
(like e.g. color, select, repeat, etc.).
This introduces g2d_validate_select_mode() and
g2d_validate_blending_op() which validate a
select mode or blending operation respectively.
Signed-off-by: Tobias Jakobi
---
exynos/exynos_fimg2d.c | 44
1 file changed, 44 insertions(+)
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index 2e04f4a..781aff5 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -119,6 +119,50 @@ static unsigned int g2d_check_space(const struct
g2d_context *ctx,
}
/*
+ * g2d_validate_select_mode - validate select mode.
+ *
+ * @mode: the mode to validate
+ */
+static unsigned int g2d_validate_select_mode(
+ enum e_g2d_select_mode mode)
+{
+ switch (mode) {
+ case G2D_SELECT_MODE_NORMAL:
+ case G2D_SELECT_MODE_FGCOLOR:
+ case G2D_SELECT_MODE_BGCOLOR:
+ return 0;
+ }
+
+ return 1;
+}
+
+/*
+ * g2d_validate_blending_op - validate blending operation.
+ *
+ * @operation: the operation to validate
+ */
+static unsigned int g2d_validate_blending_op(
+ enum e_g2d_op operation)
+{
+ switch (operation) {
+ case G2D_OP_CLEAR:
+ case G2D_OP_SRC:
+ case G2D_OP_DST:
+ case G2D_OP_OVER:
+ case G2D_OP_INTERPOLATE:
+ case G2D_OP_DISJOINT_CLEAR:
+ case G2D_OP_DISJOINT_SRC:
+ case G2D_OP_DISJOINT_DST:
+ case G2D_OP_CONJOINT_CLEAR:
+ case G2D_OP_CONJOINT_SRC:
+ case G2D_OP_CONJOINT_DST:
+ return 0;
+ }
+
+ return 1;
+}
+
+/*
* g2d_add_cmd - set given command and value to user side command buffer.
*
* @ctx: a pointer to g2d_context structure.
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/14] exynos/fimg2d: check buffer space in g2d_solid_fill()
The amount of commands (regular and GEM) doesn't depend on the input here. Signed-off-by: Tobias Jakobi --- exynos/exynos_fimg2d.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c index 1ae8adf..9b7bcce 100644 --- a/exynos/exynos_fimg2d.c +++ b/exynos/exynos_fimg2d.c @@ -319,6 +319,9 @@ g2d_solid_fill(struct g2d_context *ctx, struct g2d_image *img, union g2d_bitblt_cmd_val bitblt; union g2d_point_val pt; + if (g2d_check_space(ctx, 7, 1)) + return -ENOSPC; + g2d_add_cmd(ctx, DST_SELECT_REG, G2D_SELECT_MODE_NORMAL); g2d_add_cmd(ctx, DST_COLOR_MODE_REG, img->color_mode); g2d_add_base_addr(ctx, img, g2d_dst); -- 2.0.5 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/14] exynos/fimg2d: add g2d_check_space()
This is going to be used to check if the command buffers have
enough space left prior to actual submission of the commands.
Signed-off-by: Tobias Jakobi
---
exynos/exynos_fimg2d.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index 85b2317..1ae8adf 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -102,6 +102,23 @@ static unsigned int g2d_get_blend_op(enum e_g2d_op op)
}
/*
+ * g2d_check_space - check if command buffers have enough space left.
+ *
+ * @ctx: a pointer to g2d_context structure.
+ * @num_cmds: number of (regular) commands.
+ * @num_gem_cmds: number of GEM commands.
+ */
+static unsigned int g2d_check_space(const struct g2d_context *ctx,
+ unsigned int num_cmds, unsigned int num_gem_cmds)
+{
+ if (ctx->cmd_nr + num_cmds >= G2D_MAX_CMD_NR ||
+ ctx->cmd_buf_nr + num_gem_cmds >= G2D_MAX_GEM_CMD_NR)
+ return 1;
+ else
+ return 0;
+}
+
+/*
* g2d_add_cmd - set given command and value to user side command buffer.
*
* @ctx: a pointer to g2d_context structure.
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/14] drm/exynos: rewrite fimg2d error handling
Hello, during the discussion about the last patchset touching the fimg2d code, it became apparent that the error handling for the command submission is currently unsatisfactory. This series rewrites the handling. All functions that submit command buffers now first check if enough space is available and only then proceed to build the command buffers. In particular the command buffer is no longer left in a half-finished state, since parameters passed to the functions are now validated before command submission. For this some validation functions are introduced. This should also increase performance if the bottleneck is the submission part, since adding commands to the buffer is now more lightweight. Last but not least some prefix was added to messages printed by fprintf and printf, and the G2D context struct was moved out of the public header. Please review and let me know if I can improve anything! With best wishes, Tobias Tobias Jakobi (14): exynos/fimg2d: fix empty buffer handling in g2d_flush() exynos/fimg2d: simplify base address submission in g2d_scale_and_blend() exynos/fimg2d: add g2d_check_space() exynos/fimg2d: check buffer space in g2d_solid_fill() exynos/fimg2d: check buffer space in g2d_copy() exynos/fimg2d: check buffer space in g2d_copy_with_scale() exynos/fimg2d: add g2d_validate_xyz() functions exynos/fimg2d: check buffer space in g2d_blend() exynos/fimg2d: check buffer space in g2d_scale_and_blend() exynos/fimg2d: remove default case from g2d_get_blend_op() exynos/fimg2d: remove superfluous initialization of g2d_point_val exynos/fimg2d: make g2d_add_cmd() less heavy exynos/fimg2d: add message prefix exynos/fimg2d: remove g2d_context from public header exynos/exynos_fimg2d.c | 367 + exynos/exynos_fimg2d.h | 14 +- 2 files changed, 222 insertions(+), 159 deletions(-) -- 2.0.5 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/14] exynos/fimg2d: fix empty buffer handling in g2d_flush()
Empty command buffers are no error, we just don't have
anything to do for flushing then.
Signed-off-by: Tobias Jakobi
---
exynos/exynos_fimg2d.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index 24a06d0..4a88e0c 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -191,7 +191,7 @@ static int g2d_flush(struct g2d_context *ctx)
struct drm_exynos_g2d_set_cmdlist cmdlist = {0};
if (ctx->cmd_nr == 0 && ctx->cmd_buf_nr == 0)
- return -1;
+ return 0;
if (ctx->cmdlist_nr >= G2D_MAX_CMD_LIST_NR) {
fprintf(stderr, "Overflow cmdlist.\n");
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp
Hi Yakir,
Am Montag, 24. August 2015, 20:48:01 schrieb Yakir Yang:
> 在 08/24/2015 12:20 PM, Krzysztof Kozlowski 写道:
> > On 24.08.2015 11:42, Yakir Yang wrote:
> >> Hi Krzysztof,
> >>
> >> 在 08/23/2015 07:43 PM, Krzysztof Kozlowski 写道:
> >>> 2015-08-24 8:23 GMT+09:00 Rob Herring :
> On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang wrote:
> > Analogix dp driver is split from exynos dp driver, so we just
> > make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
> >
> > Beside update some exynos dtsi file with the latest change
> > according to the devicetree binding documents.
>
> You can't just change the exynos bindings and break compatibility. Is
> there some agreement with exynos folks to do this?
> >>>
> >>> No, there is no agreement. This wasn't even sent to Exynos maintainers.
> >>
> >> Sorry about this one, actually I have add Exynos maintainers in version
> >> 1 & version 2,
> >> but lose some maintainers in version 3, I would fix it in bellow
> >> versions.
> >>
> >>> Additionally the patchset did not look interesting to me because of
> >>> misleading subject - Documentation instead of "ARM: dts:".
> >>>
> >>> Yakir, please:
> >>> 1. Provide backward compatibility. Mark old properties as deprecated
> >>> but still support them.
> >>
> >> Do you mean that I should keep the old properties declare in
> >> exynos-dp.txt,
> >> but just mark them as deprecated flag.
> >
> > That is one of ways how to do this. However more important is that
> > driver should still support old bindings so such code:
> > - if (of_property_read_u32(dp_node, "samsung,color-space",
> > + if (of_property_read_u32(dp_node, "analogix,color-space",
> >
> > is probably wrong. Will the driver support old DTB in the same way as it
> > was supporting before the change?
>
> Okay, I got your means. So document is not the focus, the most important
> is that
> driver should support the old dts prop. If so the new analogix dp driver
> should keep
> the "samsung,color-space", rather then just mark it with [DEPRECATED] flag.
>
> But from your follow suggest, I think you agree to update driver code,
> and just mark
> old prop with deprecated flag. If so I think such code would not be wrong
>
> - if (of_property_read_u32(dp_node, "samsung,color-space",
> + if (of_property_read_u32(dp_node, "analogix,color-space",
In a generic driver, the property should have either none, or the analogix
prefix. But DT-properties need to be backwards compatible, meaning an older
Exynos devicetree should run unmodified with a newer kernel.
So the common course of action is to mark the old one as deprecated but still
test for both, so something like:
if (of_property_read_u32(dp_node, "analogix,color-space",
&dp_video_config->color_space))
if (of_property_read_u32(dp_node, "samsung,color-space",
&dp_video_config->color_space)) {
dev_err(dev, "failed to get color-space\n");
return ERR_PTR(-EINVAL);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp
On Sun, Aug 23, 2015 at 06:23:14PM -0500, Rob Herring wrote: > On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang wrote: > > + -analogix,color-depth: > > + number of bits per colour component. > > + COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3 > > This seems pretty generic. Just use 6, 8, 10, or 12 for values. And > drop the vendor prefix. Please think about this some more. What does "color-depth" mean? Does it mean the number of bits per colour _component_, or does it mean the total number of bits to represent a particular colour. It's confusing as it stands. > > +Optional properties for dp-controller: > > + -analogix,hpd-gpio: > > + Hotplug detect GPIO. > > + Indicates which GPIO should be used for hotplug > > + detection > > We should align with "hpd-gpios" used by HDMI connector binding. Or do > we need a DP connector binding that this should be defined in? > Probably so. > > The DRM related bindings are such a cluster f*ck with everyone picking > their own way to do things. Just grep hpd in bindings for starters. > That is just the tip. I'm not surprised one iota that DRM bindings are a mess. There's no one overlooking the adoption of DRM bindings, so surprise surprise, everyone does their own thing. This is exactly what happens every time in that scenario. It's not a new problem. When we adopted the graph bindings for iMX DRM, I thought exactly at that time "it would be nice if this could become the standard for binding DRM components together" but I don't have the authority from either the DT perspective or the DRM perspective to mandate that. Neither does anyone else. That's the _real_ problem here. I've seen several DRM bindings go by which don't use the of-graph stuff, which means that they'll never be compatible with generic components which do use the of-graph stuff. Like you say, it's a mess, but it's a mess of our own making, because no one has the authority to regulate this. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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 03/11] drm/exynos: add prepare and cleanup phases for planes
On 2015년 08월 16일 01:26, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> .prepare_plane() and .cleanup_plane() allows to perform extra operations
> before and after the update of planes. For FIMD for example this will
> be used to enable disable the shadow protection bit.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 19 +++
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 ++
> 2 files changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index 5a19e16..3a89fc9 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -72,15 +72,34 @@ exynos_drm_crtc_mode_set_nofb(struct drm_crtc *crtc)
> static void exynos_crtc_atomic_begin(struct drm_crtc *crtc)
> {
> struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
> + struct drm_plane *plane;
>
> if (crtc->state->event) {
> WARN_ON(drm_crtc_vblank_get(crtc) != 0);
> exynos_crtc->event = crtc->state->event;
> }
> +
> + drm_atomic_crtc_for_each_plane(plane, crtc) {
> + struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
> +
> + if (exynos_crtc->ops->prepare_plane)
> + exynos_crtc->ops->prepare_plane(exynos_crtc,
> + exynos_plane);
There is no any reason to use prepare_plane/cleanup_plane callback
names. How about using atomic_begin/atomic_flush callback names instead
for consistency between framework and device drivers?
Thanks,
Inki Dae
> + }
> }
>
> static void exynos_crtc_atomic_flush(struct drm_crtc *crtc)
> {
> + struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
> + struct drm_plane *plane;
> +
> + drm_atomic_crtc_for_each_plane(plane, crtc) {
> + struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
> +
> + if (exynos_crtc->ops->cleanup_plane)
> + exynos_crtc->ops->cleanup_plane(exynos_crtc,
> + exynos_plane);
> + }
> }
>
> static struct drm_crtc_helper_funcs exynos_crtc_helper_funcs = {
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index a993aac..9f2b5c9 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -87,6 +87,8 @@ struct exynos_drm_plane {
> * @disable_vblank: specific driver callback for disabling vblank interrupt.
> * @wait_for_vblank: wait for vblank interrupt to make sure that
> * hardware overlay is updated.
> + * @prepare_plane: prepare a window to receive a update
> + * @cleanup_plane: mark the end of a window update
> * @update_plane: apply hardware specific overlay data to registers.
> * @disable_plane: disable hardware specific overlay.
> * @te_handler: trigger to transfer video image at the tearing effect
> @@ -107,10 +109,14 @@ struct exynos_drm_crtc_ops {
> int (*enable_vblank)(struct exynos_drm_crtc *crtc);
> void (*disable_vblank)(struct exynos_drm_crtc *crtc);
> void (*wait_for_vblank)(struct exynos_drm_crtc *crtc);
> + void (*prepare_plane)(struct exynos_drm_crtc *crtc,
> + struct exynos_drm_plane *plane);
> void (*update_plane)(struct exynos_drm_crtc *crtc,
>struct exynos_drm_plane *plane);
> void (*disable_plane)(struct exynos_drm_crtc *crtc,
> struct exynos_drm_plane *plane);
> + void (*cleanup_plane)(struct exynos_drm_crtc *crtc,
> + struct exynos_drm_plane *plane);
> void (*te_handler)(struct exynos_drm_crtc *crtc);
> void (*clock_enable)(struct exynos_drm_crtc *crtc, bool enable);
> };
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp
Hi Jingoo, 在 08/24/2015 03:40 PM, Jingoo Han 写道: On 2015. 8. 24., at AM 9:43, Krzysztof Kozlowski wrote: 2015-08-24 8:23 GMT+09:00 Rob Herring : On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang wrote: Analogix dp driver is split from exynos dp driver, so we just make an copy of exynos_dp.txt, and then simplify exynos_dp.txt Beside update some exynos dtsi file with the latest change according to the devicetree binding documents. You can't just change the exynos bindings and break compatibility. Is there some agreement with exynos folks to do this? No, there is no agreement. This wasn't even sent to Exynos maintainers. Additionally the patchset did not look interesting to me because of misleading subject - Documentation instead of "ARM: dts:". Yakir, please: 1. Provide backward compatibility. Mark old properties as deprecated but still support them. 2. Separate all DTS changes to a separate patch, unless bisectability would be hurt. Anyway you should prepare it in a such way that separation would be possible without breaking bisectability. 3. Use proper subject for the patch changing DTS. This is not documentation change! 4. Please use script get_maintainers to obtain list of valid maintainers and CC-them with at least cover letter and patches requiring their attention. To Yakir Yang, Please be careful when you CC people. I don't find the reason why you CC'ed the following people. Of course, they look to be one of the talented developers. However, they look to be unrelated to your patchset. Takashi Iwai Vincent Palatin Fabio Estevam Philipp Zabel Yeah, actually I just got those people from patman tools. Thanks for your remind, I would pay more attention in next version :-) Also, please add Exynos Architecture maintainers to CC list. I don't understand why you removed them from CC list. Kukjin Kim Krzysztof Kozlowski Without their Ack, you will not change the codes of ARM Exynos Architecture. Wow, thanks a lot, it's a serious mistaken ;) Thanks, - Yakir Best regards, Jingoo Han Best regards, Krzysztof Signed-off-by: Yakir Yang --- Changes in v3: - Take Heiko suggest, add devicetree binding documents. - Take Thierry Reding suggest, remove sync pol & colorimetry properies from the new analogix dp driver devicetree binding. - Update the exist exynos dtsi file with the latest DP DT properies. Changes in v2: None .../devicetree/bindings/drm/bridge/analogix_dp.txt | 70 ++ .../devicetree/bindings/video/exynos_dp.txt| 50 ++-- arch/arm/boot/dts/exynos5250-arndale.dts | 10 ++-- arch/arm/boot/dts/exynos5250-smdk5250.dts | 10 ++-- arch/arm/boot/dts/exynos5250-snow.dts | 12 ++-- arch/arm/boot/dts/exynos5250-spring.dts| 12 ++-- arch/arm/boot/dts/exynos5420-peach-pit.dts | 12 ++-- arch/arm/boot/dts/exynos5420-smdk5420.dts | 10 ++-- arch/arm/boot/dts/exynos5800-peach-pi.dts | 12 ++-- 9 files changed, 119 insertions(+), 79 deletions(-) create mode 100644 Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt diff --git a/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt new file mode 100644 index 000..6127018 --- /dev/null +++ b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt @@ -0,0 +1,70 @@ +Analogix Display Port bridge bindings + +Required properties for dp-controller: + -compatible: + platform specific such as: +* "samsung,exynos5-dp" +* "rockchip,rk3288-dp" + -reg: + physical base address of the controller and length + of memory mapped region. + -interrupts: + interrupt combiner values. + -clocks: + from common clock binding: handle to dp clock. + -clock-names: + from common clock binding: Shall be "dp". + -interrupt-parent: + phandle to Interrupt combiner node. + -phys: + from general PHY binding: the phandle for the PHY device. + -phy-names: + from general PHY binding: Should be "dp". + -analogix,color-space: + input video data format. + COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2 + -analogix,color-depth: + number of bits per colour component. + COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3 This seems pretty generic. Just use 6, 8, 10, or 12 for values. And drop the vendor prefix. + -analogix,link-rate: + max link rate supported by the eDP controller. + LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A, + LINK_RATE_5_40GBPS = 0x14 Same here. I'd rather see something like "link-rate-mbps" and use the actual rate. + -analogix,lane-count: + max number of lanes supported by the eD
Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp
Hi Krzysztof, 在 08/24/2015 12:20 PM, Krzysztof Kozlowski 写道: On 24.08.2015 11:42, Yakir Yang wrote: Hi Krzysztof, 在 08/23/2015 07:43 PM, Krzysztof Kozlowski 写道: 2015-08-24 8:23 GMT+09:00 Rob Herring : On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang wrote: Analogix dp driver is split from exynos dp driver, so we just make an copy of exynos_dp.txt, and then simplify exynos_dp.txt Beside update some exynos dtsi file with the latest change according to the devicetree binding documents. You can't just change the exynos bindings and break compatibility. Is there some agreement with exynos folks to do this? No, there is no agreement. This wasn't even sent to Exynos maintainers. Sorry about this one, actually I have add Exynos maintainers in version 1 & version 2, but lose some maintainers in version 3, I would fix it in bellow versions. Additionally the patchset did not look interesting to me because of misleading subject - Documentation instead of "ARM: dts:". Yakir, please: 1. Provide backward compatibility. Mark old properties as deprecated but still support them. Do you mean that I should keep the old properties declare in exynos-dp.txt, but just mark them as deprecated flag. That is one of ways how to do this. However more important is that driver should still support old bindings so such code: - if (of_property_read_u32(dp_node, "samsung,color-space", + if (of_property_read_u32(dp_node, "analogix,color-space", is probably wrong. Will the driver support old DTB in the same way as it was supporting before the change? Okay, I got your means. So document is not the focus, the most important is that driver should support the old dts prop. If so the new analogix dp driver should keep the "samsung,color-space", rather then just mark it with [DEPRECATED] flag. But from your follow suggest, I think you agree to update driver code, and just mark old prop with deprecated flag. If so I think such code would not be wrong - if (of_property_read_u32(dp_node, "samsung,color-space", + if (of_property_read_u32(dp_node, "analogix,color-space", And actually @Rob have suggest me to remove the prefix, just use "color-space" here. Let me show same examples, make me understand your suggest rightly. exynos-dp already contains deprecated properties. Other ways of doing this would be: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt Documentation/devicetree/bindings/rtc/s3c-rtc.txt It depends up to you. The "touchscreen" looks good because it organizes old properties in a common section. In case of exynos-dp.txt you can add at beginning of file information about new bindings and mark everything deprecated. Whoops, thanks for your remind, I prefer the "touchscreen" style. 1. "samsung,ycbcr-coeff" is abandoned in latest analogix-dp driver, absolutely I should not carry this to analogix-dp.txt document. But I should keep this in exynos-dp.txt document, and mark them with an little "deprecated" flag. [Documentation/devicetree/bindings/video/exynos_dp.txt] Required properties for dp-controller: [...] -samsung,ycbcr-coeff (DEPRECATED): YCbCr co-efficients for input video. COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1 Is it right ? Yes, this is right. 2. Separate all DTS changes to a separate patch, unless bisectability would be hurt. Anyway you should prepare it in a such way that separation would be possible without breaking bisectability. So I should separate this patch into two parts, one is name "Document:", the other is "ARM: dts: ". Yes. Honestly, I don't understand what the "bisectability" means in this case. I was referring to bisectability in general. The patchset should be fully bisectable which means that it does not introduce any issues during "git bisect". This effectively means that at each intermediate step (after applying each patch, one by one) every existing stuff works the same as previously without any regression. Including booting with old DTB. Oh, thanks for your careful explain, so I guess your first comment is talking about the "bisectability" that if I only apply the 01 - 05 patches, kernel could not bootup normally, cause driver need "analogix,color-space" but DTB only have "samsung,color-space". 3. Use proper subject for the patch changing DTS. This is not documentation change! Hmm... when I separate this patch into two parts, I though I can keep "Documentation" proper subject in this patch, and the other is the "ARM: dts" proper subject. Am I right ? Yes, you're right. 4. Please use script get_maintainers to obtain list of valid maintainers and CC-them with at least cover letter and patches requiring their attention. Yeah, thanks. Sure. Now I found older versions of the patchset but previously there were no changes to the bindings. Again the prefix in subject is important to easily filter out and find necessary emails. BTW, I like the patchset because I like in general works
Re: [PATCH v4 3/4] mfd: Add DT binding for Maxim MAX77802 IC
On Mon, 24 Aug 2015, 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
> Reviewed-by: Krzysztof Kozlowski
>
> ---
>
> Changes in v4:
> - Reword section about max77802 clock and regulator DT binding docs.
> Suggested by Lee Jones.
> - Align max77802 mfd required properties. Suggested by Lee Jones.
>
> Changes in v3:
> - Add Krzysztof Kozlowski Reviewed-by tag to patch #3.
> - Capitalise all acronyms. Suggested by Lee Jones.
> - Use relative path to refer other bindings. Suggested by Lee Jones.
> - Use IRQ_TYPE_NONE instead of 0 in example. Suggested by Lee Jones.
>
> Changes in v2:
> - Use the correct "maxim,max77802" compatible string.
> Suggested by Krzysztof Kozlowski
> - Use a pmic generic node name for the max77802 node example.
> Suggested by Sergei Shtylyov.
>
> Documentation/devicetree/bindings/mfd/max77802.txt | 26
> ++
> 1 file changed, 26 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/max77802.txt
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/max77802.txt
> b/Documentation/devicetree/bindings/mfd/max77802.txt
> new file mode 100644
> index ..51fc1a60caa5
> --- /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 IC (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.
> +
> +Bindings for the built-in 32k clock generator block and
> +regulators are defined in ../clk/maxim,max77802.txt and
> +../regulator/max77802.txt respectively.
> +
> +Required properties:
> +- compatible : Must be "maxim,max77802"
> +- reg: Specifies the I2C slave address of PMIC block.
> +- interrupts : I2C device IRQ line connected to the main SoC.
> +- interrupt-parent : The parent interrupt controller.
> +
> +Example:
> +
> + max77802: pmic@09 {
> + compatible = "maxim,max77802";
> + interrupt-parent = <&intc>;
> + interrupts = <26 IRQ_TYPE_NONE>;
> + reg = <0x09>;
> + };
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/4] mfd: max77686: Split out regulator part from the DT binding
On Mon, 24 Aug 2015, 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
> Reviewed-by: Krzysztof Kozlowski
> Acked-by: Lee Jones
>
> ---
>
> Changes in v4: None
> Changes in v3:
> - Add Krzysztof Kozlowski Reviewed-by tag to patch #4.
> - Add Lee Jones Acked-by tag to patch #4.
>
> Changes in v2:
> - Use a generic name for the max77686 node in the regulator example.
>
> Documentation/devicetree/bindings/mfd/max77686.txt | 60 ++
> .../devicetree/bindings/regulator/max77686.txt | 71
> ++
> 2 files changed, 75 insertions(+), 56 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/regulator/max77686.txt
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/max77686.txt
> b/Documentation/devicetree/bindings/mfd/max77686.txt
> index d2ed3c20a5c3..741e76688cf2 100644
> --- a/Documentation/devicetree/bindings/mfd/max77686.txt
> +++ b/Documentation/devicetree/bindings/mfd/max77686.txt
> @@ -7,8 +7,9 @@ different i2c slave address,presently for which we are
> statically creating i2c
> 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.
> +Bindings for the built-in 32k clock generator block and
> +regulators are defined in ../clk/maxim,max77686.txt and
> +../regulator/max77686.txt respectively.
>
> 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: pmic@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.t
Re: [PATCH v4 1/4] mfd: max77686: Don't suggest in binding to use a deprecated property
On Mon, 24 Aug 2015, 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
> Reviewed-by: Krzysztof Kozlowski
> Acked-by: Lee Jones
>
> ---
>
> Changes in v4:
> - Add Lee Jones Acked-by tag to patch #1.
>
> Changes in v3: None
> Changes in v2:
> - Add Krzysztof Kozlowski Reviewed-by tag to patch #1.
>
> Documentation/devicetree/bindings/mfd/max77686.txt | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
Applied, thanks.
> 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>;
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/4] mfd: max77686: Use a generic name for the PMIC node in the example
On Mon, 24 Aug 2015, Javier Martinez Canillas wrote:
> The ePAPR standard says that: "the name of a node should be somewhat
> generic, reflecting the function of the device and not its precise
> programming model."
>
> So, change the max77686 binding document example to use a generic
> node name instead of using the chip's name.
>
> Suggested-by: Sergei Shtylyov
> Signed-off-by: Javier Martinez Canillas
> Acked-by: Lee Jones
>
> ---
>
> Changes in v4:
> - Add Lee Jones Acked-by tag to patch #2.
>
> Changes in v3:
> - Fix typo in ePAPR document name. Suggested by Sergei Shtylyov
>
> Changes in v2: None
>
> Documentation/devicetree/bindings/mfd/max77686.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/max77686.txt
> b/Documentation/devicetree/bindings/mfd/max77686.txt
> index 8221102d3fc2..d2ed3c20a5c3 100644
> --- a/Documentation/devicetree/bindings/mfd/max77686.txt
> +++ b/Documentation/devicetree/bindings/mfd/max77686.txt
> @@ -48,7 +48,7 @@ to get matched with their hardware counterparts as follow:
>
> Example:
>
> - max77686@09 {
> + max77686: pmic@09 {
> compatible = "maxim,max77686";
> interrupt-parent = <&wakeup_eint>;
> interrupts = <26 0>;
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/4] clk: samsung: exynos7: Correct nr_clk_ids for fsys0
This patch correct the nr_clk_ids for fsys0 block
which is wrongly set to TOP1 clk numbers.
This also adjust the a gate clock order.
Signed-off-by: Alim Akhtar
---
drivers/clk/samsung/clk-exynos7.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos7.c
b/drivers/clk/samsung/clk-exynos7.c
index d6c4548..2799568 100644
--- a/drivers/clk/samsung/clk-exynos7.c
+++ b/drivers/clk/samsung/clk-exynos7.c
@@ -849,13 +849,13 @@ static struct samsung_mux_clock fsys0_mux_clks[]
__initdata = {
};
static struct samsung_gate_clock fsys0_gate_clks[] __initdata = {
- GATE(ACLK_AXIUS_USBDRD30X_FSYS0X, "aclk_axius_usbdrd30x_fsys0x",
- "mout_aclk_fsys0_200_user",
- ENABLE_ACLK_FSYS00, 19, 0, 0),
GATE(ACLK_PDMA1, "aclk_pdma1", "mout_aclk_fsys0_200_user",
ENABLE_ACLK_FSYS00, 3, 0, 0),
GATE(ACLK_PDMA0, "aclk_pdma0", "mout_aclk_fsys0_200_user",
ENABLE_ACLK_FSYS00, 4, 0, 0),
+ GATE(ACLK_AXIUS_USBDRD30X_FSYS0X, "aclk_axius_usbdrd30x_fsys0x",
+ "mout_aclk_fsys0_200_user",
+ ENABLE_ACLK_FSYS00, 19, 0, 0),
GATE(ACLK_USBDRD300, "aclk_usbdrd300", "mout_aclk_fsys0_200_user",
ENABLE_ACLK_FSYS01, 29, 0, 0),
@@ -887,7 +887,7 @@ static struct samsung_cmu_info fsys0_cmu_info __initdata = {
.nr_mux_clks= ARRAY_SIZE(fsys0_mux_clks),
.gate_clks = fsys0_gate_clks,
.nr_gate_clks = ARRAY_SIZE(fsys0_gate_clks),
- .nr_clk_ids = TOP1_NR_CLK,
+ .nr_clk_ids = FSYS0_NR_CLK,
.clk_regs = fsys0_clk_regs,
.nr_clk_regs= ARRAY_SIZE(fsys0_clk_regs),
};
--
1.7.10.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 4/4] clk: samsung: exynos7: correct nr_clk_ids for fsys1
nr_clk_ids for FSYS1 block is wrongly set as TOP1 block,
this patch correct the same.
Signed-off-by: Alim Akhtar
---
drivers/clk/samsung/clk-exynos7.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/samsung/clk-exynos7.c
b/drivers/clk/samsung/clk-exynos7.c
index 2799568..0d7bb7c 100644
--- a/drivers/clk/samsung/clk-exynos7.c
+++ b/drivers/clk/samsung/clk-exynos7.c
@@ -938,7 +938,7 @@ static struct samsung_cmu_info fsys1_cmu_info __initdata = {
.nr_mux_clks= ARRAY_SIZE(fsys1_mux_clks),
.gate_clks = fsys1_gate_clks,
.nr_gate_clks = ARRAY_SIZE(fsys1_gate_clks),
- .nr_clk_ids = TOP1_NR_CLK,
+ .nr_clk_ids = FSYS1_NR_CLK,
.clk_regs = fsys1_clk_regs,
.nr_clk_regs= ARRAY_SIZE(fsys1_clk_regs),
};
--
1.7.10.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 0/4] Improvements on exynos7 clock
This patch series are minor improvement over the current exynos7 clock file. This fix some bugs and update the clock bits as per latest user manual. This serise is tested on exynos7-espresso board. Alim Akhtar (4): clk: samsung: exynos7: Update CMU TOPC block clock clk: samsung: exynos7: Update CMU TOP1 block clk: samsung: exynos7: Correct nr_clk_ids for fsys0 clk: samsung: exynos7: correct nr_clk_ids for fsys1 drivers/clk/samsung/clk-exynos7.c | 49 + 1 file changed, 28 insertions(+), 21 deletions(-) -- 1.7.10.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 2/4] clk: samsung: exynos7: Update CMU TOP1 block
This updates CMU TOP1 block clock as per latest UM.
Signed-off-by: Alim Akhtar
---
drivers/clk/samsung/clk-exynos7.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos7.c
b/drivers/clk/samsung/clk-exynos7.c
index cbf1bd2..d6c4548 100644
--- a/drivers/clk/samsung/clk-exynos7.c
+++ b/drivers/clk/samsung/clk-exynos7.c
@@ -368,12 +368,15 @@ CLK_OF_DECLARE(exynos7_clk_top0,
"samsung,exynos7-clock-top0",
#define MUX_SEL_TOP13 0x020C
#define MUX_SEL_TOP1_FSYS0 0x0224
#define MUX_SEL_TOP1_FSYS1 0x0228
+#define MUX_SEL_TOP1_FSYS110x022C
#define DIV_TOP13 0x060C
#define DIV_TOP1_FSYS0 0x0624
#define DIV_TOP1_FSYS1 0x0628
+#define DIV_TOP1_FSYS110x062C
#define ENABLE_ACLK_TOP13 0x080C
#define ENABLE_SCLK_TOP1_FSYS0 0x0A24
#define ENABLE_SCLK_TOP1_FSYS1 0x0A28
+#define ENABLE_SCLK_TOP1_FSYS110x0A2C
/* List of parent clocks for Muxes in CMU_TOP1 */
PNAME(mout_top1_bus0_pll_p)= { "fin_pll", "dout_sclk_bus0_pll" };
@@ -400,12 +403,15 @@ static unsigned long top1_clk_regs[] __initdata = {
MUX_SEL_TOP13,
MUX_SEL_TOP1_FSYS0,
MUX_SEL_TOP1_FSYS1,
+ MUX_SEL_TOP1_FSYS11,
DIV_TOP13,
DIV_TOP1_FSYS0,
DIV_TOP1_FSYS1,
+ DIV_TOP1_FSYS11,
ENABLE_ACLK_TOP13,
ENABLE_SCLK_TOP1_FSYS0,
ENABLE_SCLK_TOP1_FSYS1,
+ ENABLE_SCLK_TOP1_FSYS11,
};
static struct samsung_mux_clock top1_mux_clks[] __initdata = {
@@ -428,12 +434,12 @@ static struct samsung_mux_clock top1_mux_clks[]
__initdata = {
MUX(0, "mout_aclk_fsys1_200", mout_top1_group1, MUX_SEL_TOP13, 24, 2),
MUX(0, "mout_aclk_fsys0_200", mout_top1_group1, MUX_SEL_TOP13, 28, 2),
- MUX(0, "mout_sclk_mmc2", mout_top1_group1, MUX_SEL_TOP1_FSYS0, 24, 2),
+ MUX(0, "mout_sclk_mmc2", mout_top1_group1, MUX_SEL_TOP1_FSYS0, 16, 2),
MUX(0, "mout_sclk_usbdrd300", mout_top1_group1,
MUX_SEL_TOP1_FSYS0, 28, 2),
- MUX(0, "mout_sclk_mmc1", mout_top1_group1, MUX_SEL_TOP1_FSYS1, 24, 2),
- MUX(0, "mout_sclk_mmc0", mout_top1_group1, MUX_SEL_TOP1_FSYS1, 28, 2),
+ MUX(0, "mout_sclk_mmc1", mout_top1_group1, MUX_SEL_TOP1_FSYS11, 0, 2),
+ MUX(0, "mout_sclk_mmc0", mout_top1_group1, MUX_SEL_TOP1_FSYS11, 12, 2),
};
static struct samsung_div_clock top1_div_clks[] __initdata = {
@@ -443,26 +449,26 @@ static struct samsung_div_clock top1_div_clks[]
__initdata = {
DIV_TOP13, 28, 4),
DIV(DOUT_SCLK_MMC2, "dout_sclk_mmc2", "mout_sclk_mmc2",
- DIV_TOP1_FSYS0, 24, 4),
+ DIV_TOP1_FSYS0, 16, 10),
DIV(0, "dout_sclk_usbdrd300", "mout_sclk_usbdrd300",
DIV_TOP1_FSYS0, 28, 4),
DIV(DOUT_SCLK_MMC1, "dout_sclk_mmc1", "mout_sclk_mmc1",
- DIV_TOP1_FSYS1, 24, 4),
+ DIV_TOP1_FSYS11, 0, 10),
DIV(DOUT_SCLK_MMC0, "dout_sclk_mmc0", "mout_sclk_mmc0",
- DIV_TOP1_FSYS1, 28, 4),
+ DIV_TOP1_FSYS11, 12, 10),
};
static struct samsung_gate_clock top1_gate_clks[] __initdata = {
GATE(CLK_SCLK_MMC2, "sclk_mmc2", "dout_sclk_mmc2",
- ENABLE_SCLK_TOP1_FSYS0, 24, CLK_SET_RATE_PARENT, 0),
+ ENABLE_SCLK_TOP1_FSYS0, 16, CLK_SET_RATE_PARENT, 0),
GATE(0, "sclk_usbdrd300", "dout_sclk_usbdrd300",
ENABLE_SCLK_TOP1_FSYS0, 28, 0, 0),
GATE(CLK_SCLK_MMC1, "sclk_mmc1", "dout_sclk_mmc1",
- ENABLE_SCLK_TOP1_FSYS1, 24, CLK_SET_RATE_PARENT, 0),
+ ENABLE_SCLK_TOP1_FSYS11, 0, CLK_SET_RATE_PARENT, 0),
GATE(CLK_SCLK_MMC0, "sclk_mmc0", "dout_sclk_mmc0",
- ENABLE_SCLK_TOP1_FSYS1, 28, CLK_SET_RATE_PARENT, 0),
+ ENABLE_SCLK_TOP1_FSYS11, 12, CLK_SET_RATE_PARENT, 0),
};
static struct samsung_fixed_factor_clock top1_fixed_factor_clks[] __initdata =
{
--
1.7.10.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 1/4] clk: samsung: exynos7: Update CMU TOPC block clock
This patch fixes some of the bit field and
update the TOPC block clock as per the latest UM.
Signed-off-by: Alim Akhtar
---
drivers/clk/samsung/clk-exynos7.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos7.c
b/drivers/clk/samsung/clk-exynos7.c
index 03d36e8..cbf1bd2 100644
--- a/drivers/clk/samsung/clk-exynos7.c
+++ b/drivers/clk/samsung/clk-exynos7.c
@@ -87,6 +87,7 @@ static unsigned long topc_clk_regs[] __initdata = {
DIV_TOPC0,
DIV_TOPC1,
DIV_TOPC3,
+ ENABLE_ACLK_TOPC1,
};
static struct samsung_mux_clock topc_mux_clks[] __initdata = {
@@ -104,9 +105,9 @@ static struct samsung_mux_clock topc_mux_clks[] __initdata
= {
MUX(0, "mout_sclk_mfc_pll_cmuc", mout_sclk_mfc_pll_cmuc_p,
MUX_SEL_TOPC0, 28, 1),
+ MUX(0, "mout_aud_pll_ctrl", mout_aud_pll_ctrl_p, MUX_SEL_TOPC1, 0, 1),
MUX(0, "mout_sclk_bus0_pll_out", mout_sclk_bus0_pll_out_p,
MUX_SEL_TOPC1, 16, 1),
- MUX(0, "mout_aud_pll_ctrl", mout_aud_pll_ctrl_p, MUX_SEL_TOPC1, 0, 1),
MUX(0, "mout_aclk_ccore_133", mout_topc_group2, MUX_SEL_TOPC2, 4, 2),
@@ -116,7 +117,7 @@ static struct samsung_mux_clock topc_mux_clks[] __initdata
= {
static struct samsung_div_clock topc_div_clks[] __initdata = {
DIV(DOUT_ACLK_CCORE_133, "dout_aclk_ccore_133", "mout_aclk_ccore_133",
- DIV_TOPC0, 4, 4),
+ DIV_TOPC0, 4, 5),
DIV(DOUT_ACLK_MSCL_532, "dout_aclk_mscl_532", "mout_aclk_mscl_532",
DIV_TOPC1, 20, 4),
@@ -124,15 +125,15 @@ static struct samsung_div_clock topc_div_clks[]
__initdata = {
DIV_TOPC1, 24, 4),
DIV(DOUT_SCLK_BUS0_PLL, "dout_sclk_bus0_pll", "mout_sclk_bus0_pll_out",
- DIV_TOPC3, 0, 3),
+ DIV_TOPC3, 0, 4),
DIV(DOUT_SCLK_BUS1_PLL, "dout_sclk_bus1_pll", "mout_bus1_pll_ctrl",
- DIV_TOPC3, 8, 3),
+ DIV_TOPC3, 8, 4),
DIV(DOUT_SCLK_CC_PLL, "dout_sclk_cc_pll", "mout_cc_pll_ctrl",
- DIV_TOPC3, 12, 3),
+ DIV_TOPC3, 12, 4),
DIV(DOUT_SCLK_MFC_PLL, "dout_sclk_mfc_pll", "mout_mfc_pll_ctrl",
- DIV_TOPC3, 16, 3),
+ DIV_TOPC3, 16, 4),
DIV(DOUT_SCLK_AUD_PLL, "dout_sclk_aud_pll", "mout_aud_pll_ctrl",
- DIV_TOPC3, 28, 3),
+ DIV_TOPC3, 28, 4),
};
static struct samsung_pll_rate_table pll1460x_24mhz_tbl[] __initdata = {
--
1.7.10.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 v4 4/4] 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
Reviewed-by: Krzysztof Kozlowski
Acked-by: Lee Jones
---
Changes in v4: None
Changes in v3:
- Add Krzysztof Kozlowski Reviewed-by tag to patch #4.
- Add Lee Jones Acked-by tag to patch #4.
Changes in v2:
- Use a generic name for the max77686 node in the regulator example.
Documentation/devicetree/bindings/mfd/max77686.txt | 60 ++
.../devicetree/bindings/regulator/max77686.txt | 71 ++
2 files changed, 75 insertions(+), 56 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 d2ed3c20a5c3..741e76688cf2 100644
--- a/Documentation/devicetree/bindings/mfd/max77686.txt
+++ b/Documentation/devicetree/bindings/mfd/max77686.txt
@@ -7,8 +7,9 @@ different i2c slave address,presently for which we are
statically creating i2c
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.
+Bindings for the built-in 32k clock generator block and
+regulators are defined in ../clk/maxim,max77686.txt and
+../regulator/max77686.txt respectively.
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: pmic@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 ..0dded64d89d3
--- /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 tr
[PATCH v4 3/4] 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
Reviewed-by: Krzysztof Kozlowski
---
Changes in v4:
- Reword section about max77802 clock and regulator DT binding docs.
Suggested by Lee Jones.
- Align max77802 mfd required properties. Suggested by Lee Jones.
Changes in v3:
- Add Krzysztof Kozlowski Reviewed-by tag to patch #3.
- Capitalise all acronyms. Suggested by Lee Jones.
- Use relative path to refer other bindings. Suggested by Lee Jones.
- Use IRQ_TYPE_NONE instead of 0 in example. Suggested by Lee Jones.
Changes in v2:
- Use the correct "maxim,max77802" compatible string.
Suggested by Krzysztof Kozlowski
- Use a pmic generic node name for the max77802 node example.
Suggested by Sergei Shtylyov.
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 ..51fc1a60caa5
--- /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 IC (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.
+
+Bindings for the built-in 32k clock generator block and
+regulators are defined in ../clk/maxim,max77802.txt and
+../regulator/max77802.txt respectively.
+
+Required properties:
+- compatible : Must be "maxim,max77802"
+- reg : Specifies the I2C slave address of PMIC block.
+- interrupts : I2C device IRQ line connected to the main SoC.
+- interrupt-parent : The parent interrupt controller.
+
+Example:
+
+ max77802: pmic@09 {
+ compatible = "maxim,max77802";
+ interrupt-parent = <&intc>;
+ interrupts = <26 IRQ_TYPE_NONE>;
+ 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 v4 2/4] mfd: max77686: Use a generic name for the PMIC node in the example
The ePAPR standard says that: "the name of a node should be somewhat
generic, reflecting the function of the device and not its precise
programming model."
So, change the max77686 binding document example to use a generic
node name instead of using the chip's name.
Suggested-by: Sergei Shtylyov
Signed-off-by: Javier Martinez Canillas
Acked-by: Lee Jones
---
Changes in v4:
- Add Lee Jones Acked-by tag to patch #2.
Changes in v3:
- Fix typo in ePAPR document name. Suggested by Sergei Shtylyov
Changes in v2: None
Documentation/devicetree/bindings/mfd/max77686.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/max77686.txt
b/Documentation/devicetree/bindings/mfd/max77686.txt
index 8221102d3fc2..d2ed3c20a5c3 100644
--- a/Documentation/devicetree/bindings/mfd/max77686.txt
+++ b/Documentation/devicetree/bindings/mfd/max77686.txt
@@ -48,7 +48,7 @@ to get matched with their hardware counterparts as follow:
Example:
- max77686@09 {
+ max77686: pmic@09 {
compatible = "maxim,max77686";
interrupt-parent = <&wakeup_eint>;
interrupts = <26 0>;
--
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 v4 1/4] 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
Reviewed-by: Krzysztof Kozlowski
Acked-by: Lee Jones
---
Changes in v4:
- Add Lee Jones Acked-by tag to patch #1.
Changes in v3: None
Changes in v2:
- Add Krzysztof Kozlowski Reviewed-by tag to patch #1.
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
[PATCH v4 0/4] mfd: Improve DT binding docs for max77686 and max77802
Hello, This series contains some improvements for the Device Tree bindings of the Maxim MAX77686 and MAX77802 multi-function devices. This is the fourth version of the series that addresses issues pointed out by Lee Jones in v3. Patch #1 changes the max77686 binding to not suggest using a deprecated property of the regulator DT binding. Patch #2 changes the max77686 example to use a generic node name instead of the chip's name. Patch #3 adds a DT binding for the mfd portion of the max77802 that was missing. Patch #4 moves the regulator portion of the max77686 to the regulator's DT binding sub-directory since it is a better fit for this information. Patch #4 needs to be acked by Mark Brown to get it through the mfd tree. Changes in v4: - Add Lee Jones Acked-by tag to patch #1. - Add Lee Jones Acked-by tag to patch #2. - Reword section about max77802 clock and regulator DT binding docs. Suggested by Lee Jones. - Align max77802 mfd required properties. Suggested by Lee Jones. Changes in v3: - Fix typo in ePAPR document name. Suggested by Sergei Shtylyov - Add Krzysztof Kozlowski Reviewed-by tag to patch #3. - Capitalise all acronyms. Suggested by Lee Jones. - Use relative path to refer other bindings. Suggested by Lee Jones. - Use IRQ_TYPE_NONE instead of 0 in example. Suggested by Lee Jones. - Add Krzysztof Kozlowski Reviewed-by tag to patch #4. - Add Lee Jones Acked-by tag to patch #4. Changes in v2: - Add Krzysztof Kozlowski Reviewed-by tag to patch #1. - Use the correct "maxim,max77802" compatible string. Suggested by Krzysztof Kozlowski - Use a pmic generic node name for the max77802 node example. Suggested by Sergei Shtylyov. - Use a generic name for the max77686 node in the regulator example. Javier Martinez Canillas (4): mfd: max77686: Don't suggest in binding to use a deprecated property mfd: max77686: Use a generic name for the PMIC node in the example mfd: Add DT binding for Maxim MAX77802 IC mfd: max77686: Split out regulator part from the DT binding Documentation/devicetree/bindings/mfd/max77686.txt | 65 ++-- Documentation/devicetree/bindings/mfd/max77802.txt | 26 .../devicetree/bindings/regulator/max77686.txt | 71 ++ 3 files changed, 102 insertions(+), 60 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 v2 6/7] ARM: dts: add SROM device node for exynos5
Add SROM controller device node for exynos5.
CC: Rob Herring
CC: Mark Rutland
CC: Ian Campbell
Signed-off-by: Pankaj Dubey
---
arch/arm/boot/dts/exynos5.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index 110dbd4..b5d3437 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -30,6 +30,11 @@
reg = <0x1000 0x100>;
};
+ sromc@1225 {
+ compatible = "samsung,exynos-srom";
+ reg = <0x1225 0x10>;
+ };
+
combiner: interrupt-controller@1044 {
compatible = "samsung,exynos4210-combiner";
#interrupt-cells = <2>;
--
2.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 7/7] Documentation: dt-bindings: add exynos-srom binding information
This patch adds exynos-srom binding information for SROM Controller
driver on Exynos SoCs.
CC: Rob Herring
CC: Mark Rutland
CC: Ian Campbell
Signed-off-by: Pankaj Dubey
---
.../devicetree/bindings/arm/samsung/exynos-srom.txt | 12
1 file changed, 12 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
new file mode 100644
index 000..33886d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
@@ -0,0 +1,12 @@
+SAMSUNG Exynos SoCs SROM Controller driver.
+
+Required properties:
+- compatible : Should contain "samsung,exynos-srom".
+
+- reg: offset and length of the register set
+
+Example:
+ sromc@1257 {
+ compatible = "samsung,exynos-srom";
+ reg = <0x1257 0x10>;
+ };
--
2.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/7] ARM: dts: add SROM device node for exynos4
Add device node of SROM controller for exynos4.
CC: Rob Herring
CC: Mark Rutland
CC: Ian Campbell
Signed-off-by: Pankaj Dubey
---
arch/arm/boot/dts/exynos4.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 98c0a36..b0732d7 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -76,6 +76,11 @@
reg = <0x1000 0x100>;
};
+ sromc@1257 {
+ compatible = "samsung,exynos-srom";
+ reg = <0x1257 0x10>;
+ };
+
mipi_phy: video-phy@10020710 {
compatible = "samsung,s5pv210-mipi-video-phy";
#phy-cells = <1>;
--
2.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/7] drivers: soc: add support for exynos SROM driver
This patch adds Exynos SROM controller driver which will handle
save restore of SROM registers during S2R.
Signed-off-by: Pankaj Dubey
---
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/samsung/Kconfig | 13
drivers/soc/samsung/Makefile | 1 +
drivers/soc/samsung/exynos-srom.c | 143 ++
drivers/soc/samsung/exynos-srom.h | 51 ++
6 files changed, 210 insertions(+)
create mode 100644 drivers/soc/samsung/Kconfig
create mode 100644 drivers/soc/samsung/Makefile
create mode 100644 drivers/soc/samsung/exynos-srom.c
create mode 100644 drivers/soc/samsung/exynos-srom.h
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index 96ddecb..69107c9 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -2,6 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
source "drivers/soc/mediatek/Kconfig"
source "drivers/soc/qcom/Kconfig"
+source "drivers/soc/samsung/Kconfig"
source "drivers/soc/sunxi/Kconfig"
source "drivers/soc/ti/Kconfig"
source "drivers/soc/versatile/Kconfig"
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 7dc7c0d..34c4398 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -4,6 +4,7 @@
obj-$(CONFIG_ARCH_MEDIATEK)+= mediatek/
obj-$(CONFIG_ARCH_QCOM)+= qcom/
+obj-$(CONFIG_SOC_SAMSUNG) += samsung/
obj-$(CONFIG_ARCH_SUNXI) += sunxi/
obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_SOC_TI) += ti/
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
new file mode 100644
index 000..ea4bc2a
--- /dev/null
+++ b/drivers/soc/samsung/Kconfig
@@ -0,0 +1,13 @@
+#
+# SAMSUNG SoC drivers
+#
+menu "Samsung SOC driver support"
+
+config SOC_SAMSUNG
+ bool
+
+config EXYNOS_SROM
+ bool
+ depends on ARM && ARCH_EXYNOS
+
+endmenu
diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
new file mode 100644
index 000..9c554d5
--- /dev/null
+++ b/drivers/soc/samsung/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_EXYNOS_SROM) += exynos-srom.o
diff --git a/drivers/soc/samsung/exynos-srom.c
b/drivers/soc/samsung/exynos-srom.c
new file mode 100644
index 000..d7c4aa7
--- /dev/null
+++ b/drivers/soc/samsung/exynos-srom.c
@@ -0,0 +1,143 @@
+/*
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * EXYNOS - SROM Controller support
+ * Author: Pankaj Dubey
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "exynos-srom.h"
+
+static void __iomem *exynos_srom_base;
+
+static const unsigned long exynos_srom_offsets[] = {
+ /* SROM side */
+ EXYNOS_SROM_BW,
+ EXYNOS_SROM_BC0,
+ EXYNOS_SROM_BC1,
+ EXYNOS_SROM_BC2,
+ EXYNOS_SROM_BC3,
+};
+
+/**
+ * struct exynos_srom_reg_dump: register dump of SROM Controller registers.
+ * @offset: srom register offset from the controller base address.
+ * @value: the value of register under the offset.
+ */
+struct exynos_srom_reg_dump {
+ u32 offset;
+ u32 value;
+};
+
+static struct exynos_srom_reg_dump *exynos_srom_regs;
+
+static struct exynos_srom_reg_dump *exynos_srom_alloc_reg_dump(
+ const unsigned long *rdump,
+ unsigned long nr_rdump)
+{
+ struct exynos_srom_reg_dump *rd;
+ unsigned int i;
+
+ rd = kcalloc(nr_rdump, sizeof(*rd), GFP_KERNEL);
+ if (!rd)
+ return NULL;
+
+ for (i = 0; i < nr_rdump; ++i)
+ rd[i].offset = rdump[i];
+
+ return rd;
+}
+
+static const struct of_device_id of_exynos_srom_ids[] = {
+ {
+ .compatible = "samsung,exynos-srom",
+ },
+ {},
+};
+
+static int exynos_srom_probe(struct platform_device *pdev)
+{
+ struct device_node *np;
+ struct device *dev = &pdev->dev;
+
+ np = dev->of_node;
+ exynos_srom_base = of_iomap(np, 0);
+
+ if (!exynos_srom_base) {
+ pr_err("iomap of exynos srom controller failed\n");
+ return -ENOMEM;
+ }
+
+ exynos_srom_regs = exynos_srom_alloc_reg_dump(exynos_srom_offsets,
+ sizeof(exynos_srom_offsets));
+
+ if (!exynos_srom_regs) {
+ iounmap(exynos_srom_regs);
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static void exynos_srom_save(void __iomem *base,
+ struct exynos_srom_reg_dump *rd,
+ unsigned int num_regs)
+{
+ for (; num_regs > 0; --num_regs, ++rd)
+ rd->value = readl(base + rd->offset);
+
+}
+
+static void exynos_srom_restore(void __iomem *base,
+
[PATCH v2 4/7] ARM: EXYNOS: Remove SROM related register settings from mach-exynos
As now we have dedicated driver for SROM controller, it will take care
of saving register banks during S2R so we can safely remove these
settings from mach-exynos.
Signed-off-by: Pankaj Dubey
---
arch/arm/mach-exynos/Kconfig | 2 ++
arch/arm/mach-exynos/common.h| 2 --
arch/arm/mach-exynos/exynos.c| 17 -
arch/arm/mach-exynos/include/mach/map.h | 3 --
arch/arm/mach-exynos/regs-srom.h | 53
arch/arm/mach-exynos/suspend.c | 20 ++-
arch/arm/plat-samsung/include/plat/map-s5p.h | 1 -
7 files changed, 4 insertions(+), 94 deletions(-)
delete mode 100644 arch/arm/mach-exynos/regs-srom.h
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 3a10f1a..7c917ef 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -27,6 +27,8 @@ menuconfig ARCH_EXYNOS
select SRAM
select THERMAL
select MFD_SYSCON
+ select SOC_SAMSUNG
+ select EXYNOS_SROM
help
Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 1534925..1c04741 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -108,8 +108,6 @@ IS_SAMSUNG_CPU(exynos5800, EXYNOS5800_SOC_ID,
EXYNOS5_SOC_MASK)
#define soc_is_exynos4() (soc_is_exynos4210() || soc_is_exynos4212() || \
soc_is_exynos4412())
-#define soc_is_exynos5() (soc_is_exynos5250() || soc_is_exynos5410() || \
- soc_is_exynos5420() || soc_is_exynos5800())
extern u32 cp15_save_diag;
extern u32 cp15_save_power;
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 524aa6f..4ffb90e 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -37,11 +37,6 @@ void __iomem *pmu_base_addr;
static struct map_desc exynos4_iodesc[] __initdata = {
{
- .virtual= (unsigned long)S5P_VA_SROMC,
- .pfn= __phys_to_pfn(EXYNOS4_PA_SROMC),
- .length = SZ_4K,
- .type = MT_DEVICE,
- }, {
.virtual= (unsigned long)S5P_VA_CMU,
.pfn= __phys_to_pfn(EXYNOS4_PA_CMU),
.length = SZ_128K,
@@ -64,15 +59,6 @@ static struct map_desc exynos4_iodesc[] __initdata = {
},
};
-static struct map_desc exynos5_iodesc[] __initdata = {
- {
- .virtual= (unsigned long)S5P_VA_SROMC,
- .pfn= __phys_to_pfn(EXYNOS5_PA_SROMC),
- .length = SZ_4K,
- .type = MT_DEVICE,
- },
-};
-
static struct platform_device exynos_cpuidle = {
.name = "exynos_cpuidle",
#ifdef CONFIG_ARM_EXYNOS_CPUIDLE
@@ -144,9 +130,6 @@ static void __init exynos_map_io(void)
{
if (soc_is_exynos4())
iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
-
- if (soc_is_exynos5())
- iotable_init(exynos5_iodesc, ARRAY_SIZE(exynos5_iodesc));
}
static void __init exynos_init_io(void)
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index 86d8085..351e839 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -32,7 +32,4 @@
#define EXYNOS4_PA_COREPERI0x1050
#define EXYNOS4_PA_L2CC0x10502000
-#define EXYNOS4_PA_SROMC 0x1257
-#define EXYNOS5_PA_SROMC 0x1225
-
#endif /* __ASM_ARCH_MAP_H */
diff --git a/arch/arm/mach-exynos/regs-srom.h b/arch/arm/mach-exynos/regs-srom.h
deleted file mode 100644
index 5c4d442..000
--- a/arch/arm/mach-exynos/regs-srom.h
+++ /dev/null
@@ -1,53 +0,0 @@
-/*
- * Copyright (c) 2010 Samsung Electronics Co., Ltd.
- * http://www.samsung.com
- *
- * S5P SROMC register definitions
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-#ifndef __PLAT_SAMSUNG_REGS_SROM_H
-#define __PLAT_SAMSUNG_REGS_SROM_H __FILE__
-
-#include
-
-#define S5P_SROMREG(x) (S5P_VA_SROMC + (x))
-
-#define S5P_SROM_BWS5P_SROMREG(0x0)
-#define S5P_SROM_BC0 S5P_SROMREG(0x4)
-#define S5P_SROM_BC1 S5P_SROMREG(0x8)
-#define S5P_SROM_BC2 S5P_SROMREG(0xc)
-#define S5P_SROM_BC3 S5P_SROMREG(0x10)
-#define S5P_SROM_BC4 S5P_SROMREG(0x14)
-#define S5P_SROM_BC5 S5P_SROMREG(0x18)
-
-/* one register BW holds 4 x 4-bit packed settings for NCS0 - NCS3 */
-
-#define S5P_SROM_BW__DATAWIDTH__SHIFT 0
-#define S5P_SROM_BW__ADDRMODE__SHIFT 1
-#define S5P_SROM_BW__WAITENABLE__SHIFT 2
-#define S5P
[PATCH v2 2/7] ARM: EXYNOS: code cleanup in map.h
Remove unused exynos5440 uart offset macro. Signed-off-by: Pankaj Dubey --- arch/arm/mach-exynos/include/mach/map.h | 4 1 file changed, 4 deletions(-) diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h index a2acba3..86d8085 100644 --- a/arch/arm/mach-exynos/include/mach/map.h +++ b/arch/arm/mach-exynos/include/mach/map.h @@ -35,8 +35,4 @@ #define EXYNOS4_PA_SROMC 0x1257 #define EXYNOS5_PA_SROMC 0x1225 -/* Compatibility UART */ - -#define EXYNOS5440_PA_UART00x000B - #endif /* __ASM_ARCH_MAP_H */ -- 2.4.5 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/7] Add support for Exynos SROM Controller driver
This patch set adds support for Exynos SROM controller DT based driver. Currently SROM register sets are used only during S2R, so driver basically added for taking care of S2R. It will help us in removing static mapping from exynos.c and other extra code handline during S2R. This patch set also updated exynos4 and exynos5 dtsi files for with device node for srom, and added binding documentation for the same. First two patches are some minor cleanup in mach-exynos. Patchset v1 was posted here[1] [1]: https://lkml.org/lkml/2015/4/29/98 Changes since v1: - Rebased to latest kgene tree. - Addressed review comments from Krzysztof Kozlowski. - Add two new patches for minor cleanup in exynos.c and map.h Pankaj Dubey (7): ARM: EXYNOS: remove unused static mapping of CMU for exynos5 ARM: EXYNOS: code cleanup in map.h drivers: soc: add support for exynos SROM driver ARM: EXYNOS: Remove SROM related register settings from mach-exynos ARM: dts: add SROM device node for exynos4 ARM: dts: add SROM device node for exynos5 Documentation: dt-bindings: add exynos-srom binding information .../bindings/arm/samsung/exynos-srom.txt | 12 ++ arch/arm/boot/dts/exynos4.dtsi | 5 + arch/arm/boot/dts/exynos5.dtsi | 5 + arch/arm/mach-exynos/Kconfig | 2 + arch/arm/mach-exynos/common.h | 2 - arch/arm/mach-exynos/exynos.c | 22 arch/arm/mach-exynos/include/mach/map.h| 8 -- arch/arm/mach-exynos/regs-srom.h | 53 arch/arm/mach-exynos/suspend.c | 20 +-- arch/arm/plat-samsung/include/plat/map-s5p.h | 1 - drivers/soc/Kconfig| 1 + drivers/soc/Makefile | 1 + drivers/soc/samsung/Kconfig| 13 ++ drivers/soc/samsung/Makefile | 1 + drivers/soc/samsung/exynos-srom.c | 143 + drivers/soc/samsung/exynos-srom.h | 51 16 files changed, 236 insertions(+), 104 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt delete mode 100644 arch/arm/mach-exynos/regs-srom.h create mode 100644 drivers/soc/samsung/Kconfig create mode 100644 drivers/soc/samsung/Makefile create mode 100644 drivers/soc/samsung/exynos-srom.c create mode 100644 drivers/soc/samsung/exynos-srom.h -- 2.4.5 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/7] ARM: EXYNOS: remove unused static mapping of CMU for exynos5
Remove unused static mapping of exynos5 CMU and related code.
Signed-off-by: Pankaj Dubey
---
arch/arm/mach-exynos/exynos.c | 5 -
arch/arm/mach-exynos/include/mach/map.h | 1 -
2 files changed, 6 deletions(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 1c47aee..524aa6f 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -70,11 +70,6 @@ static struct map_desc exynos5_iodesc[] __initdata = {
.pfn= __phys_to_pfn(EXYNOS5_PA_SROMC),
.length = SZ_4K,
.type = MT_DEVICE,
- }, {
- .virtual= (unsigned long)S5P_VA_CMU,
- .pfn= __phys_to_pfn(EXYNOS5_PA_CMU),
- .length = 144 * SZ_1K,
- .type = MT_DEVICE,
},
};
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index de3ae59..a2acba3 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -25,7 +25,6 @@
#define EXYNOS_PA_CHIPID 0x1000
#define EXYNOS4_PA_CMU 0x1003
-#define EXYNOS5_PA_CMU 0x1001
#define EXYNOS4_PA_DMC00x1040
#define EXYNOS4_PA_DMC10x1041
--
2.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp
On 2015. 8. 24., at AM 9:43, Krzysztof Kozlowski wrote: > > 2015-08-24 8:23 GMT+09:00 Rob Herring : >>> On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang wrote: >>> Analogix dp driver is split from exynos dp driver, so we just >>> make an copy of exynos_dp.txt, and then simplify exynos_dp.txt >>> >>> Beside update some exynos dtsi file with the latest change >>> according to the devicetree binding documents. >> >> You can't just change the exynos bindings and break compatibility. Is >> there some agreement with exynos folks to do this? > > No, there is no agreement. This wasn't even sent to Exynos maintainers. > Additionally the patchset did not look interesting to me because of > misleading subject - Documentation instead of "ARM: dts:". > > Yakir, please: > 1. Provide backward compatibility. Mark old properties as deprecated > but still support them. > 2. Separate all DTS changes to a separate patch, unless bisectability > would be hurt. Anyway you should prepare it in a such way that > separation would be possible without breaking bisectability. > 3. Use proper subject for the patch changing DTS. This is not > documentation change! > 4. Please use script get_maintainers to obtain list of valid > maintainers and CC-them with at least cover letter and patches > requiring their attention. To Yakir Yang, Please be careful when you CC people. I don't find the reason why you CC'ed the following people. Of course, they look to be one of the talented developers. However, they look to be unrelated to your patchset. Takashi Iwai Vincent Palatin Fabio Estevam Philipp Zabel Also, please add Exynos Architecture maintainers to CC list. I don't understand why you removed them from CC list. Kukjin Kim Krzysztof Kozlowski Without their Ack, you will not change the codes of ARM Exynos Architecture. Best regards, Jingoo Han > > Best regards, > Krzysztof > > >> >> >>> Signed-off-by: Yakir Yang >>> --- >>> Changes in v3: >>> - Take Heiko suggest, add devicetree binding documents. >>> - Take Thierry Reding suggest, remove sync pol & colorimetry properies >>> from the new analogix dp driver devicetree binding. >>> - Update the exist exynos dtsi file with the latest DP DT properies. >>> >>> Changes in v2: None >>> >>> .../devicetree/bindings/drm/bridge/analogix_dp.txt | 70 >>> ++ >>> .../devicetree/bindings/video/exynos_dp.txt| 50 ++-- >>> arch/arm/boot/dts/exynos5250-arndale.dts | 10 ++-- >>> arch/arm/boot/dts/exynos5250-smdk5250.dts | 10 ++-- >>> arch/arm/boot/dts/exynos5250-snow.dts | 12 ++-- >>> arch/arm/boot/dts/exynos5250-spring.dts| 12 ++-- >>> arch/arm/boot/dts/exynos5420-peach-pit.dts | 12 ++-- >>> arch/arm/boot/dts/exynos5420-smdk5420.dts | 10 ++-- >>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 12 ++-- >>> 9 files changed, 119 insertions(+), 79 deletions(-) >>> create mode 100644 >>> Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt >>> >>> diff --git a/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt >>> b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt >>> new file mode 100644 >>> index 000..6127018 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt >>> @@ -0,0 +1,70 @@ >>> +Analogix Display Port bridge bindings >>> + >>> +Required properties for dp-controller: >>> + -compatible: >>> + platform specific such as: >>> +* "samsung,exynos5-dp" >>> +* "rockchip,rk3288-dp" >>> + -reg: >>> + physical base address of the controller and length >>> + of memory mapped region. >>> + -interrupts: >>> + interrupt combiner values. >>> + -clocks: >>> + from common clock binding: handle to dp clock. >>> + -clock-names: >>> + from common clock binding: Shall be "dp". >>> + -interrupt-parent: >>> + phandle to Interrupt combiner node. >>> + -phys: >>> + from general PHY binding: the phandle for the PHY device. >>> + -phy-names: >>> + from general PHY binding: Should be "dp". >>> + -analogix,color-space: >>> + input video data format. >>> + COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = >>> 2 >>> + -analogix,color-depth: >>> + number of bits per colour component. >>> + COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3 >> >> This seems pretty generic. Just use 6, 8, 10, or 12 for values. And >> drop the vendor prefix. >> >>> + -analogix,link-rate: >>> + max link rate supported by the eDP controller. >>> + LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A, >>> + LINK_RATE_5_40GBPS = 0x14 >> >> Same here. I'd rather see something like "link-rate-mbps" and use the
Re: [PATCH v2] rtc: s5m: fix to update ctrl register
On 21/08/2015 at 18:43:41 +0900, Joonyoung Shim wrote : > According to datasheet, the S2MPS13X and S2MPS14X should update write > buffer via setting WUDR bit to high after ctrl register is written. > > If not, ALARM interrupt of rtc-s5m doesn't happen first time when i use > tools/testing/selftests/timers/rtctest.c test program and hour format is > used to 12 hour mode in Odroid-XU3 board. > > One more issue is the RTC doesn't keep time on Odroid-XU3 board when i > turn on board after power off even if RTC battery is connected. It can > be solved as setting WUDR & RUDR bits to high at the same time after > RTC_CTRL register is written. It's same with condition of only writing > ALARM registers, so this is for only S2MPS14 and we should set WUDR & > A_UDR bits to high on S2MPS13. > > I can't find any reasonable description about this like fix from > datasheet, but can find similar codes from rtc driver source of > hardkernel kernel and vender kernel. > > Signed-off-by: Joonyoung Shim > Cc: # v3.16 > --- > Changelog for v2: > - update commit description and code to fix time keeping problem > - update the stable tag with the kernel version > > drivers/rtc/rtc-s5m.c | 10 ++ > 1 file changed, 10 insertions(+) > Applied, thanks. I fixed the small typo. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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 07/18] ARM: EXYNOS: use const and __initconst for smp_operations
On 24.08.2015 13:36, Masahiro Yamada wrote: > The smp_operations structure is not over-written, so add const > qualifier and replace __initdata with __initconst. > > Signed-off-by: Masahiro Yamada > --- > > arch/arm/mach-exynos/common.h | 2 +- > arch/arm/mach-exynos/platsmp.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) Acked-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 0/7] Exynos4412-based Trats2 USB gadget (DWC2) fixes
On 21.08.2015 21:38, Marek Szyprowski wrote:
> Dear All,
>
> Since v3.19 s3c-hsotg (DWC2) USB controller stopped working on
> Exynos4412-based Trats2 platform. However on Odroid-U3 (which is also
> Exynos4412-based) it worked fine all the time. After long investigation
> it turned out that this was caused by 2 independent issues.
>
> First issue was caused by patch 7eec1266751bd3a25e35ce88686634c768fedc24
> ("ARM: dts: Add Maxim 77693 PMIC to exynos4412-trats2") added support
> for Maxim 77693 regulators, but without defining consumers for them.
> This causes regulator core to disable them. However SAFEOUT1 regulator
> provides power supply to VBUS signal, which also power some USB phy
> related parts of Exynos SoC core. This has been fixed by patches 1-3,
> which adds support for VBUS regulator, defines them in DTS for all
> Exynos platforms and changes probe sequence of the drivers to ensure no
> deferred probe occurs (USB gadget subsystem doesn't support deferred
> probe yet).
>
> Second issue is related to DWC2 driver rewrite and host/gadget/dual-role
> integration code. DWC2 module on some platforms needs three additional
> hardware resources: phy, clock and power supply. All of them must be
> enabled/activated to properly initialize and operate. This was initially
> handled in s3c-hsotg driver, which has been converted to 'gadget' part
> of dwc2 driver. Unfortunately, not all of this code got moved to common
> platform code, what resulted in accessing DWC2 registers without
> enabling power supply regulators and clock. This caused initialization
> failure on Exynos4412-based Trats2. Odroid U3 board worked fine, because
> power supplies used by DWC2 module are marked there as 'always-on',
> because they are also used by other modules (USB hub) and clock was
> shared with USB2 PHY, so it was already enabled. This initialization
> issue has been fixed by the last patch. While preparing it I've also
> fixed a few minor issues found in nearby code (patches 4-6).
>
> I would like to get those patches merged separately to respective
> subsystem trees:
> patch 1: phy subsystem tree
> patch 2: Samsung Exynos tree
> patch 3: regulator subsystem tree
> patch 4-7: USB gadget subsystem tree
>
> Patches have been prepared on top of linux-next from 20150821.
Entire patchset tested on Trats2 board:
Tested-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: CPUIdle for Exynos5422 Odroid-XU3/XU4 boards.
Hi all, On 08/21/2015 09:21 AM, Javier Martinez Canillas wrote: [Adding Przemyslaw Marczak who was working on porting Odroid BL1/BL2/SPL] This work is currently on hold, but the mainline spl support will not solve early-boot issues caused by cpu running in a non-secure state. But I think, that still some hacking is possible, and will continue a research on it later, when I finish some more important tasks. Best regards, -- Przemyslaw Marczak Samsung R&D Institute Poland Samsung Electronics p.marc...@samsung.com Hello, On 08/21/2015 05:59 AM, Krzysztof Kozlowski wrote: On 21.08.2015 12:41, Anand Moon wrote: Hi Krzysztof, On 21 August 2015 at 06:25, Krzysztof Kozlowski wrote: On 21.08.2015 03:15, Anand Moon wrote: Hi Daniel, On 20 August 2015 at 21:40, Daniel Lezcano wrote: On 08/20/2015 12:54 PM, Anand Moon wrote: Hello Krzysztof/Kukjim, CPUIdle seen to be not working for Exynos5422 Odroid boards. Is their any way this feature will be implemented in the future. Yeah a good willing to fix the bl1. More than one year asking for that ! nooo way !! Your answer is at the end of http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html Thanks for the explanation. I was just referring following the source code. https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y/arch/arm/mach-exynos/cpuidle-exynos5422.c It seem that cpufreq and cpuidle go hand in hand. Bartlomiej was working on cpufreq for Exynos542x: http://lkml.iu.edu/hypermail/linux/kernel/1504.2/03139.html It would be nice to have also cpuidle and suspend features working on Exynos542x family but this depends on firmware. Some time ago I struggled with suspend on Arndale Octa (Exynos5420) and I failed. I think the firmware is the issue here. There were a lot of Suspend-to-RAM bug fixes lately mostly related to critical clocks being gated. It would be nice to give a try on recent kernels and see if is still not working. Actually I am not sure what is your question Anand. You are asking if someone plans to do this? Yes I am asking are their plans to implement cpufreq and cpuidle simultaneously. There are no obstacles for implementing them simultaneously so the question is rather who plans to do the cpuidle driver for Exynos542x? I If the firmware is in a good shape (unfortunately as mentioned by Daniel, the one in the Odroids are not) then the generic ARM big.LITTLE CPUidle driver (CONFIG_ARM_BIG_LITTLE_CPUIDLE) should work. It is at least working for me on the Exynos5800 based Peach Pi Chromebook: $ cat /sys/devices/system/cpu/cpuidle/current_driver big_idle $ cat /sys/devices/system/cpu/cpu0/cpuidle/state*/name WFI C1 $ cat /sys/devices/system/cpu/cpu0/cpuidle/state*/usage 7745 10578 don't... at least in nearby future. If I had some spare time then probably I would try to make suspend working. Suspend-to-RAM is at least working on the Exynos5420 and Exynos5800 Chromebooks. As you mentioned it may depend on the firmware so that does not hold true for all the Exynos5420/5422/5800 boards but it would be good to know what is the causing S2R to fail. Best regards, Krzysztof Best regards, -- 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
