Re: [PATCH 0/4] Drop drivers for Exynos4415
Hi Krzk, 2017. 1. 14. PM 8:36 Krzysztof Kozlowski <k...@kernel.org> wrote: > Hi, > > Support for Exynos4415 is being removed because: > 1. There are no upstream users, > 2. There are no known downstream users, > 3. Except compile testing, you cannot build working kernel > for Exynos4415 anymore. > > Patches are rebased on current next and are independent. > Please pick up as you wish. > > Best regards, > Krzysztof Agreed, Acked-by: Kukjin Kim <kg...@kernel.org> k-gene > > Krzysztof Kozlowski (4): > ARM: EXYNOS: Remove Exynos4415 driver (SoC not supported anymore) > clk: samsung: Remove Exynos4415 driver (SoC not supported anymore) > pinctrl: samsung: Remove support for Exynos4415 (SoC not supported >anymore) > drm: exynos: Remove support for Exynos4415 (SoC not supported anymore) > > .../devicetree/bindings/clock/exynos4415-clock.txt | 38 - > .../bindings/display/exynos/exynos_dsim.txt|1 - > .../bindings/display/exynos/samsung-fimd.txt |1 - > arch/arm/mach-exynos/Kconfig |5 - > arch/arm/mach-exynos/exynos.c |1 - > arch/arm/mach-exynos/suspend.c |1 - > drivers/clk/samsung/Makefile |1 - > drivers/clk/samsung/clk-exynos4415.c | 1022 > drivers/gpu/drm/exynos/exynos_drm_dsi.c| 15 +- > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 18 +- > drivers/pinctrl/samsung/pinctrl-exynos.c | 75 -- > drivers/pinctrl/samsung/pinctrl-samsung.c |2 - > drivers/pinctrl/samsung/pinctrl-samsung.h |1 - > include/dt-bindings/clock/exynos4415.h | 360 --- > 14 files changed, 3 insertions(+), 1538 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/clock/exynos4415-clock.txt > delete mode 100644 drivers/clk/samsung/clk-exynos4415.c > delete mode 100644 include/dt-bindings/clock/exynos4415.h > > -- > 2.9.3 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] ARM: dts: exynos4412-trats2: set display clock correctly
On 05/20/15 09:12, Krzysztof Kozlowski wrote:
> 2015-02-07 19:49 GMT+09:00 Inki Dae :
>> This patch sets display clock correctly.
>>
>> If Display clock isn't set correctly then you would find below messages
>> and Display controller doesn't work correctly since a patch[1]
>>
>>exynos-drm: No connectors reported connected with modes
>>[drm] Cannot find any crtc or sizes - going 1024x768
>>
>> [1] commit abc0b1447d49 ("drm: Perform basic sanity checks on probed modes")
>
> Reviewed-by: Krzysztof Kozlowski
> Tested-by: Krzysztof Kozlowski
>
> Tested on Trats2 board.
>
> Dear Kukjin,
>
> Could you pull it to current fixes branch (this RC cycle)? The patch
> fixes display on Trats2 board. Without it (since abc0b1447d49) it
> won't be properly set up and device boots with blank screen and
> mentioned error message in logs.
>
> I think this actually is a candidate for stable backporting (4.0+)
> because it fixes important functionality of device:
>
> Fixes: abc0b1447d49 ("drm: Perform basic sanity checks on probed modes")
> Cc:
>
Thanks, applied, and will be sent out in a day for v4.1-rc.
- Kukjin
[PATCH v2 RESEND 0/4] Fix power domains handling on exynos542x
On 03/12/15 22:37, Andrzej Hajda wrote: > Hi Kukjin, > Hi, > This is resend of my patchset with added (Reviewed|Tested)-by tags and > removed RFC > prefix. > > Exynos chipsets since 542x have asynchronous bridges connecting different IPs. > These bridges should be operational during power domain switching, ie > associated > clocks cannot be gated. > This patchset adds binding to provide such clocks per power domain and adds > code > which enables them during domain on/off operation. > > This patchset fixes power domain issues with disp1 domain and HDMI (some of > them) > on Odroid XU3: > - disp1 power domain can be turned off, > - no more "imprecise external abort" faults. > > The patchset is based on samsung-fixes-dt tag from kgene/linux-samsung. > > It was successfully tested on OdroidXU3. > Thanks, applied whole this series. - Kukjin > Andrzej Hajda (4): > arm/exynos: add asynchronous bridge clock bindings > arm/exynos/pm_domains: add support for async-bridge clocks > ARM: dts: exynos5420: add async-bridge clocks to disp1 power domain > ARM: dts: exynos5420: add async-bridge clocks to gsc power domain > > .../bindings/arm/exynos/power_domain.txt | 3 +++ > arch/arm/boot/dts/exynos5420.dtsi | 8 +-- > arch/arm/mach-exynos/pm_domains.c | 27 > ++ > 3 files changed, 32 insertions(+), 6 deletions(-)
[PATCH V9 13/14] ARM: dts: snow: represent the connection between bridge and panel using videoport and endpoints
On 01/27/15 13:27, Ajay kumar wrote: > Hi Kukjin, > Hi, [...] >> >> I'm fine on the DT changes in this series, shall I take 13/14 and 14/14 in >> Samsung tree? > Yes, please take these patches. > Done, thanks. - Kukjin
[PATCH v5 0/9] Enable HDMI support on Exynos platforms
On 02/04/15 09:09, Joonyoung Shim wrote: > Hi, > Hi, > On 02/03/2015 12:58 PM, Kukjin Kim wrote: >> Marek Szyprowski wrote: >>> >>> Hi all, >>> >>> This is yet another update on patchset, which enables HDMI support for >>> Exynos based platforms. >>> >>> Beside DTS changes, this patchset adds parent domain support for Exynos >>> PM domains and add support for 'hdmi' clock directly to Exynos DRM mixer >>> driver. >>> >>> The patchset is based on samsung/for-next branch and 'PM / Domains: >>> Export of_genpd_get_from_provider function' patch merged as commit >>> 7496fcbe8a643097efc061160e1c3b65ee2fa350 to v3.19-rc4. >>> >>> Regards >>> Marek Szyprowski >>> >>> >>> Changelog: >>> >>> v5: >>> - fixed error value for clk_get() in mixer patch >>> - rebased onto samsung/for-next branch >>> >>> v4: (http://www.spinics.net/lists/linux-samsung-soc/msg41375.html) >>> - added patches, which add 'hdmi' clock handling to mixed block, this >>> finally solves the initialization related issues, thanks for Tobias >>> Jakobi for testing >>> - added acks/reviewed/tested by tags >>> >>> v3: (http://www.spinics.net/lists/linux-samsung-soc/msg41020.html) >>> - added a note on defining subdomains to generic PM domain binding >>> documentation (requested by Ulf Hansson) >>> >>> v2: (http://www.spinics.net/lists/linux-samsung-soc/msg40980.html) >>> - rewrote subdomains patch according to suggestions from Geert >>> Uytterhoeven and Amit Daniel Kachhap. >>> >>> v1 resend: (http://www.spinics.net/lists/linux-samsung-soc/msg39428.html) >>> - added handling of generic 'power-domains' binding in subdomains >>> >>> v1: (http://www.spinics.net/lists/linux-samsung-soc/msg38914.html) >>> - resolved power domain on/off issue with 'clk: samsung: exynos4: set >>> parent of mixer gate clock to hdmi' patch >>> >>> v0: (http://www.spinics.net/lists/linux-samsung-soc/msg33498.html) >>> - first attempt, used 'always on' power domains hack >>> >>> >>> Patch summary: >>> >>> >>> *** BLURB HERE *** >>> >>> Andrzej Hajda (1): >>> ARM: dts: exynos5250: add display power domain >>> >>> Marek Szyprowski (7): >>> PM / Domains: Add a note about power domain subdomains >>> ARM: Exynos: add support for sub-power domains >>> ARM: dts: exynos4: add hdmi related nodes >>> ARM: dts: exynos4: add dependency between TV and LCD0 power domains >>> ARM: dts: exynos4412-odroid: enable hdmi support >>> ARM: dts: Exynos: add 'hdmi' clock to mixer nodes >>> drm/exynos: add support for 'hdmi' clock >>> >>> Tomasz Stanislawski (1): >>> ARM: dts: exynos4210-universal_c210: enable hdmi support >>> >>> .../bindings/arm/exynos/power_domain.txt | 2 + >>> .../devicetree/bindings/power/power_domain.txt | 29 +++ >>> .../devicetree/bindings/video/exynos_mixer.txt | 1 + >>> arch/arm/boot/dts/exynos4.dtsi | 41 >>> arch/arm/boot/dts/exynos4210-universal_c210.dts| 57 >>> ++ >>> arch/arm/boot/dts/exynos4210.dtsi | 8 +++ >>> arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 44 + >>> arch/arm/boot/dts/exynos4x12.dtsi | 11 + >>> arch/arm/boot/dts/exynos5250.dtsi | 15 +- >>> arch/arm/boot/dts/exynos5420.dtsi | 5 +- >>> arch/arm/mach-exynos/pm_domains.c | 28 +++ >>> drivers/gpu/drm/exynos/exynos_mixer.c | 9 >>> 12 files changed, 246 insertions(+), 4 deletions(-) >>> >>> -- >> I have no objection on this series, but just wondering my tree should be fine >> without 9/9 drm patch and it will be handled for 3.20? >> >> I'll take 1 to 8 patches once drm patch is landed for 3.20. >> > > I also hope this patchset merged, > > Inki, could you follow up exynos drm part of this patchset? > I checked and I'll apply 1 to 8 patches in samsung tree. Thanks, Kukjin
[PATCH v5 0/9] Enable HDMI support on Exynos platforms
Marek Szyprowski wrote: > > Hi all, > > This is yet another update on patchset, which enables HDMI support for > Exynos based platforms. > > Beside DTS changes, this patchset adds parent domain support for Exynos > PM domains and add support for 'hdmi' clock directly to Exynos DRM mixer > driver. > > The patchset is based on samsung/for-next branch and 'PM / Domains: > Export of_genpd_get_from_provider function' patch merged as commit > 7496fcbe8a643097efc061160e1c3b65ee2fa350 to v3.19-rc4. > > Regards > Marek Szyprowski > > > Changelog: > > v5: > - fixed error value for clk_get() in mixer patch > - rebased onto samsung/for-next branch > > v4: (http://www.spinics.net/lists/linux-samsung-soc/msg41375.html) > - added patches, which add 'hdmi' clock handling to mixed block, this > finally solves the initialization related issues, thanks for Tobias > Jakobi for testing > - added acks/reviewed/tested by tags > > v3: (http://www.spinics.net/lists/linux-samsung-soc/msg41020.html) > - added a note on defining subdomains to generic PM domain binding > documentation (requested by Ulf Hansson) > > v2: (http://www.spinics.net/lists/linux-samsung-soc/msg40980.html) > - rewrote subdomains patch according to suggestions from Geert > Uytterhoeven and Amit Daniel Kachhap. > > v1 resend: (http://www.spinics.net/lists/linux-samsung-soc/msg39428.html) > - added handling of generic 'power-domains' binding in subdomains > > v1: (http://www.spinics.net/lists/linux-samsung-soc/msg38914.html) > - resolved power domain on/off issue with 'clk: samsung: exynos4: set > parent of mixer gate clock to hdmi' patch > > v0: (http://www.spinics.net/lists/linux-samsung-soc/msg33498.html) > - first attempt, used 'always on' power domains hack > > > Patch summary: > > > *** BLURB HERE *** > > Andrzej Hajda (1): > ARM: dts: exynos5250: add display power domain > > Marek Szyprowski (7): > PM / Domains: Add a note about power domain subdomains > ARM: Exynos: add support for sub-power domains > ARM: dts: exynos4: add hdmi related nodes > ARM: dts: exynos4: add dependency between TV and LCD0 power domains > ARM: dts: exynos4412-odroid: enable hdmi support > ARM: dts: Exynos: add 'hdmi' clock to mixer nodes > drm/exynos: add support for 'hdmi' clock > > Tomasz Stanislawski (1): > ARM: dts: exynos4210-universal_c210: enable hdmi support > > .../bindings/arm/exynos/power_domain.txt | 2 + > .../devicetree/bindings/power/power_domain.txt | 29 +++ > .../devicetree/bindings/video/exynos_mixer.txt | 1 + > arch/arm/boot/dts/exynos4.dtsi | 41 > arch/arm/boot/dts/exynos4210-universal_c210.dts| 57 > ++ > arch/arm/boot/dts/exynos4210.dtsi | 8 +++ > arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 44 + > arch/arm/boot/dts/exynos4x12.dtsi | 11 + > arch/arm/boot/dts/exynos5250.dtsi | 15 +- > arch/arm/boot/dts/exynos5420.dtsi | 5 +- > arch/arm/mach-exynos/pm_domains.c | 28 +++ > drivers/gpu/drm/exynos/exynos_mixer.c | 9 > 12 files changed, 246 insertions(+), 4 deletions(-) > > -- I have no objection on this series, but just wondering my tree should be fine without 9/9 drm patch and it will be handled for 3.20? I'll take 1 to 8 patches once drm patch is landed for 3.20. - Kukjin
[PATCH V9 13/14] ARM: dts: snow: represent the connection between bridge and panel using videoport and endpoints
Ajay Kumar wrote:
>
> Define videoports and use endpoints to describe the connection between
> the encoder, bridge and the panel, instead of using phandles.
>
> Signed-off-by: Ajay Kumar
> Acked-by: Inki Dae
> Tested-by: Rahul Sharma
> Tested-by: Javier Martinez Canillas
> Tested-by: Gustavo Padovan
> Tested-by: Sjoerd Simons
> ---
> arch/arm/boot/dts/exynos5250-snow.dts | 30 --
> 1 file changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
> b/arch/arm/boot/dts/exynos5250-snow.dts
> index b9aeec4..1bd5d3a 100644
> --- a/arch/arm/boot/dts/exynos5250-snow.dts
> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
> @@ -183,7 +183,20 @@
> powerdown-gpios = < 5 GPIO_ACTIVE_HIGH>;
> reset-gpios = < 5 GPIO_ACTIVE_HIGH>;
> edid-emulation = <5>;
> - panel = <>;
> +
> + ports {
> + port at 0 {
> + bridge_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> +
> + port at 1 {
> + bridge_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> };
> };
>
> @@ -228,6 +241,12 @@
> compatible = "auo,b116xw03";
> power-supply = <>;
> backlight = <>;
> +
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> };
> };
>
> @@ -242,7 +261,14 @@
> samsung,link-rate = <0x0a>;
> samsung,lane-count = <2>;
> samsung,hpd-gpio = < 7 GPIO_ACTIVE_HIGH>;
> - bridge = <>;
> +
> + ports {
> + port at 0 {
> + dp_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> };
>
> {
> --
> 1.7.9.5
I'm fine on the DT changes in this series, shall I take 13/14 and 14/14 in
Samsung tree?
- Kukjin
[PATCH 1/3] ARM: dts: add fimd device support for exynos3250-rinato
On 01/03/15 15:50, Inki Dae wrote:
> On 2014ë
11ì 28ì¼ 20:39, Inki Dae wrote:
>> This patch adds fimd device node which is a display controller
>> for Exynos3250 Rinato board.
>
> Hi Kukjin,
>
> Please, ping~
>
> Thanks,
> Inki Dae
>
>>
>> Signed-off-by: Inki Dae
>> Acked-by: Kyungmin Park
>> ---
>> arch/arm/boot/dts/exynos3250-rinato.dts | 11 +++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
>> b/arch/arm/boot/dts/exynos3250-rinato.dts
>> index 80aa8b4..79aa916 100644
>> --- a/arch/arm/boot/dts/exynos3250-rinato.dts
>> +++ b/arch/arm/boot/dts/exynos3250-rinato.dts
>> @@ -125,6 +125,17 @@
>> };
>> };
>>
>> + {
>> +status = "okay";
>> +
>> +i80-if-timings {
>> +cs-setup = <0>;
>> +wr-setup = <0>;
>> +wr-act = <1>;
>> +wr-hold = <0>;
>> +};
>> +};
>> +
>> _0 {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
Applied this and 3rd one.
BTW, I can't see the "samsung,s6e63j0x03" support yet?
- Kukjin
[PATCH] drm/exynos: Fix (more) freeing issues in exynos_drm_drv.c
Inki Dae wrote: > > Applied. > > Thanks, > Inki Dae > > 2014-03-17 12:28 GMT+09:00 Daniel Kurtz : > > The following commit [0] fixed a use-after-free, but left the subdrv > open > > in the error path. > > > > [0] commit 6ca605f7c70895a35737435f17ae9cc5e36f1466 > > drm/exynos: Fix freeing issues in exynos_drm_drv.c > > > > Change-Id: I452e944bf090fb11434d9e34213c890c41c15d73 This should be removed when Inki apply this. Thanks, Kukjin > > Signed-off-by: Daniel Kurtz > > --- > > drivers/gpu/drm/exynos/exynos_drm_drv.c | 10 +++--- > > 1 file changed, 7 insertions(+), 3 deletions(-)
[RFC 00/12] Add DRM Exynos HDMI on SoCs from Exynos4 family
On 10/28/13 06:42, Inki Dae wrote: > Hi Tomasz, > > I have merged the re-factoring patch set from Sean Paul. Can you > re-base your patch set at top of exynos-drm-next? > Basically, RFC is not patch for merge. So Tomasz needs to re-submit after addressing comments from RFC. Thanks, Kukjin
[PATCHv3 1/4] drm/exynos: add device tree support for rotator
On 08/13/13 14:12, Chanho Park wrote:
> The exynos4 platform is only dt-based since 3.10, we should convert driver
> data
> and ids to dt-based parsing methods. The rotator driver has a limit table to
> get
> size limit of input picture. Each SoCs has slightly different limit value
> compared with any others.
> For example, exynos4210's max_size of RGB888 is 16k x 16k. But, others have
> 8k x 8k. Another example the exynos5250 should have multiple of 2 pixel size
> for its X/Y axis. Thus, we should keep different tables for each of them.
> This patch also includes desciptions of each nodes for the rotator and
> specifies
> a example how to bind it.
>
> Signed-off-by: Chanho Park
> Cc: Inki Dae
Inki, do you OK on this? If so, let me take this whole series into the
samsung tree.
Thanks,
Kukjin
> Signed-off-by: Kyungmin Park
> ---
> .../devicetree/bindings/gpu/samsung-rotator.txt| 27 +
> drivers/gpu/drm/exynos/exynos_drm_rotator.c| 108
> +++-
> 2 files changed, 107 insertions(+), 28 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/gpu/samsung-rotator.txt
>
> diff --git a/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
> b/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
> new file mode 100644
> index 000..82cd1ed
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
> @@ -0,0 +1,27 @@
> +* Samsung Image Rotator
> +
> +Required properties:
> + - compatible : value should be one of the following:
> + (a) "samsung,exynos4210-rotator" for Rotator IP in Exynos4210
> + (b) "samsung,exynos4212-rotator" for Rotator IP in Exynos4212/4412
> + (c) "samsung,exynos5250-rotator" for Rotator IP in Exynos5250
> +
> + - reg : Physical base address of the IP registers and length of memory
> + mapped region.
> +
> + - interrupts : Interrupt specifier for rotator interrupt, according to
> format
> + specific to interrupt parent.
> +
> + - clocks : Clock specifier for rotator clock, according to generic clock
> + bindings. (See Documentation/devicetree/bindings/clock/exynos*.txt)
> +
> + - clock-names : Names of clocks. For exynos rotator, it should be
> "rotator".
> +
> +Example:
> + rotator at 1281 {
> + compatible = "samsung,exynos4210-rotator";
> + reg =<0x1281 0x1000>;
> + interrupts =<0 83 0>;
> + clocks =< 278>;
> + clock-names = "rotator";
> + };
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> index 427640a..0485aea5 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> @@ -632,21 +632,98 @@ static int rotator_ippdrv_start(struct device *dev,
> enum drm_exynos_ipp_cmd cmd)
> return 0;
> }
>
> +static struct rot_limit_table rot_limit_tbl_4210 = {
> + .ycbcr420_2p = {
> + .min_w = 32,
> + .min_h = 32,
> + .max_w = SZ_64K,
> + .max_h = SZ_64K,
> + .align = 3,
> + },
> + .rgb888 = {
> + .min_w = 8,
> + .min_h = 8,
> + .max_w = SZ_16K,
> + .max_h = SZ_16K,
> + .align = 2,
> + },
> +};
> +
> +static struct rot_limit_table rot_limit_tbl_4x12 = {
> + .ycbcr420_2p = {
> + .min_w = 32,
> + .min_h = 32,
> + .max_w = SZ_32K,
> + .max_h = SZ_32K,
> + .align = 3,
> + },
> + .rgb888 = {
> + .min_w = 8,
> + .min_h = 8,
> + .max_w = SZ_8K,
> + .max_h = SZ_8K,
> + .align = 2,
> + },
> +};
> +
> +static struct rot_limit_table rot_limit_tbl_5250 = {
> + .ycbcr420_2p = {
> + .min_w = 32,
> + .min_h = 32,
> + .max_w = SZ_32K,
> + .max_h = SZ_32K,
> + .align = 3,
> + },
> + .rgb888 = {
> + .min_w = 8,
> + .min_h = 8,
> + .max_w = SZ_8K,
> + .max_h = SZ_8K,
> + .align = 1,
> + },
> +};
> +
> +static const struct of_device_id exynos_rotator_match[] = {
> + {
> + .compatible = "samsung,exynos4210-rotator",
> + .data =_limit_tbl_4210,
> + },
> + {
> + .compatible = "samsung,exynos4212-rotator",
> + .data =_limit_tbl_4x12,
> + },
> + {
> + .compatible = "samsung,exynos5250-rotator",
> + .data =_limit_tbl_5250,
> + },
> + {},
> +};
> +
> static int rotator_probe(struct platform_device *pdev)
> {
> struct device *dev =>dev;
> struct rot_context *rot;
> struct exynos_drm_ippdrv *ippdrv;
> + const struct of_device_id *match;
> int ret;
>
> + if (!dev->of_node) {
> + dev_err(dev, "cannot find of_node.\n");
> + return -ENODEV;
>
Re: [PATCHv3 1/4] drm/exynos: add device tree support for rotator
On 08/13/13 14:12, Chanho Park wrote:
The exynos4 platform is only dt-based since 3.10, we should convert driver data
and ids to dt-based parsing methods. The rotator driver has a limit table to get
size limit of input picture. Each SoCs has slightly different limit value
compared with any others.
For example, exynos4210's max_size of RGB888 is 16k x 16k. But, others have
8k x 8k. Another example the exynos5250 should have multiple of 2 pixel size
for its X/Y axis. Thus, we should keep different tables for each of them.
This patch also includes desciptions of each nodes for the rotator and specifies
a example how to bind it.
Signed-off-by: Chanho Parkchanho61.p...@samsung.com
Cc: Inki Daeinki@samsung.com
Inki, do you OK on this? If so, let me take this whole series into the
samsung tree.
Thanks,
Kukjin
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
.../devicetree/bindings/gpu/samsung-rotator.txt| 27 +
drivers/gpu/drm/exynos/exynos_drm_rotator.c| 108 +++-
2 files changed, 107 insertions(+), 28 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpu/samsung-rotator.txt
diff --git a/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
b/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
new file mode 100644
index 000..82cd1ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
@@ -0,0 +1,27 @@
+* Samsung Image Rotator
+
+Required properties:
+ - compatible : value should be one of the following:
+ (a) samsung,exynos4210-rotator for Rotator IP in Exynos4210
+ (b) samsung,exynos4212-rotator for Rotator IP in Exynos4212/4412
+ (c) samsung,exynos5250-rotator for Rotator IP in Exynos5250
+
+ - reg : Physical base address of the IP registers and length of memory
+ mapped region.
+
+ - interrupts : Interrupt specifier for rotator interrupt, according to format
+specific to interrupt parent.
+
+ - clocks : Clock specifier for rotator clock, according to generic clock
+bindings. (See Documentation/devicetree/bindings/clock/exynos*.txt)
+
+ - clock-names : Names of clocks. For exynos rotator, it should be rotator.
+
+Example:
+ rotator@1281 {
+ compatible = samsung,exynos4210-rotator;
+ reg =0x1281 0x1000;
+ interrupts =0 83 0;
+ clocks =clock 278;
+ clock-names = rotator;
+ };
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 427640a..0485aea5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -632,21 +632,98 @@ static int rotator_ippdrv_start(struct device *dev, enum
drm_exynos_ipp_cmd cmd)
return 0;
}
+static struct rot_limit_table rot_limit_tbl_4210 = {
+ .ycbcr420_2p = {
+ .min_w = 32,
+ .min_h = 32,
+ .max_w = SZ_64K,
+ .max_h = SZ_64K,
+ .align = 3,
+ },
+ .rgb888 = {
+ .min_w = 8,
+ .min_h = 8,
+ .max_w = SZ_16K,
+ .max_h = SZ_16K,
+ .align = 2,
+ },
+};
+
+static struct rot_limit_table rot_limit_tbl_4x12 = {
+ .ycbcr420_2p = {
+ .min_w = 32,
+ .min_h = 32,
+ .max_w = SZ_32K,
+ .max_h = SZ_32K,
+ .align = 3,
+ },
+ .rgb888 = {
+ .min_w = 8,
+ .min_h = 8,
+ .max_w = SZ_8K,
+ .max_h = SZ_8K,
+ .align = 2,
+ },
+};
+
+static struct rot_limit_table rot_limit_tbl_5250 = {
+ .ycbcr420_2p = {
+ .min_w = 32,
+ .min_h = 32,
+ .max_w = SZ_32K,
+ .max_h = SZ_32K,
+ .align = 3,
+ },
+ .rgb888 = {
+ .min_w = 8,
+ .min_h = 8,
+ .max_w = SZ_8K,
+ .max_h = SZ_8K,
+ .align = 1,
+ },
+};
+
+static const struct of_device_id exynos_rotator_match[] = {
+ {
+ .compatible = samsung,exynos4210-rotator,
+ .data =rot_limit_tbl_4210,
+ },
+ {
+ .compatible = samsung,exynos4212-rotator,
+ .data =rot_limit_tbl_4x12,
+ },
+ {
+ .compatible = samsung,exynos5250-rotator,
+ .data =rot_limit_tbl_5250,
+ },
+ {},
+};
+
static int rotator_probe(struct platform_device *pdev)
{
struct device *dev =pdev-dev;
struct rot_context *rot;
struct exynos_drm_ippdrv *ippdrv;
+ const struct of_device_id *match;
int ret;
+ if (!dev-of_node) {
+ dev_err(dev, cannot find of_node.\n);
+ return -ENODEV;
+ }
+
rot = devm_kzalloc(dev, sizeof(*rot), GFP_KERNEL);
if
[PATCH 0/5] clk/exynos5420: add clocks for hdmi subsystem
On 06/24/13 13:28, Rahul Sharma wrote: [...] > I never got these patches. I'm not subscribed to devicetree-devel or > linux-samsung so I only got two replies to patch #0, but none of the > code. Can you or Rajul resend? > Sure mike. >>> >>> Acked-by: Mike Turquette >>> Applied with Mike's ack. Thanks, - Kukjin
Re: [PATCH 0/5] clk/exynos5420: add clocks for hdmi subsystem
On 06/24/13 13:28, Rahul Sharma wrote: [...] I never got these patches. I'm not subscribed to devicetree-devel or linux-samsung so I only got two replies to patch #0, but none of the code. Can you or Rajul resend? Sure mike. Acked-by: Mike Turquettemturque...@linaro.org Applied with Mike's ack. Thanks, - Kukjin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] clk/exynos5420: add clocks for hdmi subsystem
On 06/19/13 13:04, Rahul Sharma wrote: > + mike > Mike, I'm waiting for your reply on this. If you're OK, let me take this series on top of exynos5420 stuff in samsung tree. Of course, if any concerns, please let me know. Thanks, - Kukjin > On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma > wrote: >> Add clock changes for hdmi subsystem for exynos5250 SoC. These >> include addition of new clocks like mout_hdmi and smmu_tv, associating >> ID to clk_hdmiphy and some essential corrections. >> >> This set is based on kukjin's for-next branch at >> http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git. >> >> This set dependents on the following patches which add support for Exynos5420 >> http://www.mail-archive.com/linux-samsung-soc at >> vger.kernel.org/msg19264.html >> >> Rahul Sharma (5): >>clk/exynos5420: add sclk_hdmiphy to the list of special clocks >>clk/exynos5420: add gate clock for tv sysmmu >>clk/exynos5420: fix the order of parents of hdmi mux >>clk/exynos5420: add hdmi mux to change parents in hdmi driver >>clk/exynos5420: assign sclk_pixel id to pixel clock divider >> >> .../devicetree/bindings/clock/exynos5420-clock.txt |7 +++ >> drivers/clk/samsung/clk-exynos5420.c | 18 >> +++--- >> 2 files changed, 18 insertions(+), 7 deletions(-) >> >> -- >> 1.7.10.4
[PATCH v3 3/3] ARM/dts: change compatible strings for hdmi subsystem
On 06/19/13 22:50, Kukjin Kim wrote:
> On 06/19/13 21:51, Rahul Sharma wrote:
>> This patch renames the combatible strings for hdmi, mixer, ddc
>> and hdmiphy. It follows the convention of using compatible string
>> which represent the SoC in which the IP was added for the first
>> time.
>>
>> Signed-off-by: Rahul Sharma
>
> Acked-by: Kukjin Kim
>
Just one nit in subject:
[PATCH] ARM: dts: . for exynos5250
Thanks,
- Kukjin
>> ---
>> arch/arm/boot/dts/cros5250-common.dtsi | 4 ++--
>> arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 ++--
>> arch/arm/boot/dts/exynos5250.dtsi | 4 ++--
>> 3 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
>> b/arch/arm/boot/dts/cros5250-common.dtsi
>> index 3f0239e..dc259e8b 100644
>> --- a/arch/arm/boot/dts/cros5250-common.dtsi
>> +++ b/arch/arm/boot/dts/cros5250-common.dtsi
>> @@ -190,7 +190,7 @@
>> samsung,i2c-max-bus-freq =<66000>;
>>
>> hdmiddc at 50 {
>> - compatible = "samsung,exynos5-hdmiddc";
>> + compatible = "samsung,exynos4210-hdmiddc";
>> reg =<0x50>;
>> };
>> };
>> @@ -224,7 +224,7 @@
>> samsung,i2c-max-bus-freq =<378000>;
>>
>> hdmiphy at 38 {
>> - compatible = "samsung,exynos5-hdmiphy";
>> + compatible = "samsung,exynos4212-hdmiphy";
>> reg =<0x38>;
>> };
>> };
>> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> index 3e0c792..f320d7c 100644
>> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> @@ -72,7 +72,7 @@
>> samsung,i2c-max-bus-freq =<66000>;
>>
>> hdmiddc at 50 {
>> - compatible = "samsung,exynos5-hdmiddc";
>> + compatible = "samsung,exynos4210-hdmiddc";
>> reg =<0x50>;
>> };
>> };
>> @@ -102,7 +102,7 @@
>> samsung,i2c-max-bus-freq =<66000>;
>>
>> hdmiphy at 38 {
>> - compatible = "samsung,exynos5-hdmiphy";
>> + compatible = "samsung,exynos4212-hdmiphy";
>> reg =<0x38>;
>> };
>> };
>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
>> b/arch/arm/boot/dts/exynos5250.dtsi
>> index 0673524..2f7763b 100644
>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>> @@ -601,7 +601,7 @@
>> };
>>
>> hdmi {
>> - compatible = "samsung,exynos5-hdmi";
>> + compatible = "samsung,exynos4212-hdmi";
>> reg =<0x1453 0x7>;
>> interrupts =<0 95 0>;
>> clocks =< 333>,< 136>,< 137>,
>> @@ -611,7 +611,7 @@
>> };
>>
>> mixer {
>> - compatible = "samsung,exynos5-mixer";
>> + compatible = "samsung,exynos5250-mixer";
>> reg =<0x1445 0x1>;
>> interrupts =<0 94 0>;
>> };
[PATCH v3 3/3] ARM/dts: change compatible strings for hdmi subsystem
On 06/19/13 21:51, Rahul Sharma wrote:
> This patch renames the combatible strings for hdmi, mixer, ddc
> and hdmiphy. It follows the convention of using compatible string
> which represent the SoC in which the IP was added for the first
> time.
>
> Signed-off-by: Rahul Sharma
Acked-by: Kukjin Kim
- Kukjin
> ---
> arch/arm/boot/dts/cros5250-common.dtsi|4 ++--
> arch/arm/boot/dts/exynos5250-smdk5250.dts |4 ++--
> arch/arm/boot/dts/exynos5250.dtsi |4 ++--
> 3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
> b/arch/arm/boot/dts/cros5250-common.dtsi
> index 3f0239e..dc259e8b 100644
> --- a/arch/arm/boot/dts/cros5250-common.dtsi
> +++ b/arch/arm/boot/dts/cros5250-common.dtsi
> @@ -190,7 +190,7 @@
> samsung,i2c-max-bus-freq =<66000>;
>
> hdmiddc at 50 {
> - compatible = "samsung,exynos5-hdmiddc";
> + compatible = "samsung,exynos4210-hdmiddc";
> reg =<0x50>;
> };
> };
> @@ -224,7 +224,7 @@
> samsung,i2c-max-bus-freq =<378000>;
>
> hdmiphy at 38 {
> - compatible = "samsung,exynos5-hdmiphy";
> + compatible = "samsung,exynos4212-hdmiphy";
> reg =<0x38>;
> };
> };
> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> index 3e0c792..f320d7c 100644
> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> @@ -72,7 +72,7 @@
> samsung,i2c-max-bus-freq =<66000>;
>
> hdmiddc at 50 {
> - compatible = "samsung,exynos5-hdmiddc";
> + compatible = "samsung,exynos4210-hdmiddc";
> reg =<0x50>;
> };
> };
> @@ -102,7 +102,7 @@
> samsung,i2c-max-bus-freq =<66000>;
>
> hdmiphy at 38 {
> - compatible = "samsung,exynos5-hdmiphy";
> + compatible = "samsung,exynos4212-hdmiphy";
> reg =<0x38>;
> };
> };
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> b/arch/arm/boot/dts/exynos5250.dtsi
> index 0673524..2f7763b 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -601,7 +601,7 @@
> };
>
> hdmi {
> - compatible = "samsung,exynos5-hdmi";
> + compatible = "samsung,exynos4212-hdmi";
> reg =<0x1453 0x7>;
> interrupts =<0 95 0>;
> clocks =< 333>,< 136>,< 137>,
> @@ -611,7 +611,7 @@
> };
>
> mixer {
> - compatible = "samsung,exynos5-mixer";
> + compatible = "samsung,exynos5250-mixer";
> reg =<0x1445 0x1>;
> interrupts =<0 94 0>;
> };
[PATCH 0/5] clk/exynos5250: add clocks for hdmi subsystem
On 06/18/13 14:09, Rahul Sharma wrote: > Hi Mr. Kukjin, > > Kindly consider the following patches for review and integration. > (+ Mike) Rahul, basically, looks good to me but I'm waiting for Mike's ack on this series... > regards, > Rahul Sharma. > > On Fri, Jun 14, 2013 at 3:39 PM, Arun Kumar K > wrote: >> Hi, >> Tested this series on snow board and is working fine. >> >> Tested-by: Arun Kumar K >> Arun, thanks for your test. - Kukjin >> Regards >> Arun >> >> On Mon, Jun 10, 2013 at 4:30 PM, Rahul Sharma >> wrote: >>> Add clock changes for hdmi subsystem for exynos5250 SoC. These >>> include addition of new clocks like mout_hdmi and smmu_tv, associating >>> ID to clk_hdmiphy and some essential corrections. >>> >>> This set is based on kukjin's for-next branch at >>> http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git. >>> >>> Arun Kumar K (1): >>>clk/exynos5250: Fix HDMI clock number in documentation >>> >>> Rahul Sharma (4): >>>clk/exynos5250: add mout_hdmi mux clock for hdmi >>>clk/exynos5250: add sclk_hdmiphy in the list of special clocks >>>clk/exynos5250: add clock for tv sysmmu >>>clk/exynos5250: change parent to aclk200_disp1 for hdmi subsystem >>> >>> .../devicetree/bindings/clock/exynos5250-clock.txt | 12 +++- >>> drivers/clk/samsung/clk-exynos5250.c | 18 >>> +- >>> 2 files changed, 24 insertions(+), 6 deletions(-)
Re: [PATCH v3 3/3] ARM/dts: change compatible strings for hdmi subsystem
On 06/19/13 22:50, Kukjin Kim wrote:
On 06/19/13 21:51, Rahul Sharma wrote:
This patch renames the combatible strings for hdmi, mixer, ddc
and hdmiphy. It follows the convention of using compatible string
which represent the SoC in which the IP was added for the first
time.
Signed-off-by: Rahul Sharmarahul.sha...@samsung.com
Acked-by: Kukjin Kim kgene@samsung.com
Just one nit in subject:
[PATCH] ARM: dts: . for exynos5250
Thanks,
- Kukjin
---
arch/arm/boot/dts/cros5250-common.dtsi | 4 ++--
arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 ++--
arch/arm/boot/dts/exynos5250.dtsi | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
b/arch/arm/boot/dts/cros5250-common.dtsi
index 3f0239e..dc259e8b 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -190,7 +190,7 @@
samsung,i2c-max-bus-freq =66000;
hdmiddc@50 {
- compatible = samsung,exynos5-hdmiddc;
+ compatible = samsung,exynos4210-hdmiddc;
reg =0x50;
};
};
@@ -224,7 +224,7 @@
samsung,i2c-max-bus-freq =378000;
hdmiphy@38 {
- compatible = samsung,exynos5-hdmiphy;
+ compatible = samsung,exynos4212-hdmiphy;
reg =0x38;
};
};
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 3e0c792..f320d7c 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -72,7 +72,7 @@
samsung,i2c-max-bus-freq =66000;
hdmiddc@50 {
- compatible = samsung,exynos5-hdmiddc;
+ compatible = samsung,exynos4210-hdmiddc;
reg =0x50;
};
};
@@ -102,7 +102,7 @@
samsung,i2c-max-bus-freq =66000;
hdmiphy@38 {
- compatible = samsung,exynos5-hdmiphy;
+ compatible = samsung,exynos4212-hdmiphy;
reg =0x38;
};
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 0673524..2f7763b 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -601,7 +601,7 @@
};
hdmi {
- compatible = samsung,exynos5-hdmi;
+ compatible = samsung,exynos4212-hdmi;
reg =0x1453 0x7;
interrupts =0 95 0;
clocks =clock 333,clock 136,clock 137,
@@ -611,7 +611,7 @@
};
mixer {
- compatible = samsung,exynos5-mixer;
+ compatible = samsung,exynos5250-mixer;
reg =0x1445 0x1;
interrupts =0 94 0;
};
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] clk/exynos5420: add clocks for hdmi subsystem
On 06/19/13 13:04, Rahul Sharma wrote: + mike Mike, I'm waiting for your reply on this. If you're OK, let me take this series on top of exynos5420 stuff in samsung tree. Of course, if any concerns, please let me know. Thanks, - Kukjin On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharmarahul.sha...@samsung.com wrote: Add clock changes for hdmi subsystem for exynos5250 SoC. These include addition of new clocks like mout_hdmi and smmu_tv, associating ID to clk_hdmiphy and some essential corrections. This set is based on kukjin's for-next branch at http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git. This set dependents on the following patches which add support for Exynos5420 http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg19264.html Rahul Sharma (5): clk/exynos5420: add sclk_hdmiphy to the list of special clocks clk/exynos5420: add gate clock for tv sysmmu clk/exynos5420: fix the order of parents of hdmi mux clk/exynos5420: add hdmi mux to change parents in hdmi driver clk/exynos5420: assign sclk_pixel id to pixel clock divider .../devicetree/bindings/clock/exynos5420-clock.txt |7 +++ drivers/clk/samsung/clk-exynos5420.c | 18 +++--- 2 files changed, 18 insertions(+), 7 deletions(-) -- 1.7.10.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] clk/exynos5250: add clocks for hdmi subsystem
On 06/18/13 14:09, Rahul Sharma wrote: Hi Mr. Kukjin, Kindly consider the following patches for review and integration. (+ Mike) Rahul, basically, looks good to me but I'm waiting for Mike's ack on this series... regards, Rahul Sharma. On Fri, Jun 14, 2013 at 3:39 PM, Arun Kumar Karunkk.sams...@gmail.com wrote: Hi, Tested this series on snow board and is working fine. Tested-by: Arun Kumar Karun...@samsung.com Arun, thanks for your test. - Kukjin Regards Arun On Mon, Jun 10, 2013 at 4:30 PM, Rahul Sharmarahul.sha...@samsung.com wrote: Add clock changes for hdmi subsystem for exynos5250 SoC. These include addition of new clocks like mout_hdmi and smmu_tv, associating ID to clk_hdmiphy and some essential corrections. This set is based on kukjin's for-next branch at http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git. Arun Kumar K (1): clk/exynos5250: Fix HDMI clock number in documentation Rahul Sharma (4): clk/exynos5250: add mout_hdmi mux clock for hdmi clk/exynos5250: add sclk_hdmiphy in the list of special clocks clk/exynos5250: add clock for tv sysmmu clk/exynos5250: change parent to aclk200_disp1 for hdmi subsystem .../devicetree/bindings/clock/exynos5250-clock.txt | 12 +++- drivers/clk/samsung/clk-exynos5250.c | 18 +- 2 files changed, 24 insertions(+), 6 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D
Kukjin Kim wrote: Oops, I'm re-sending due to my e-mail client problem :-( Sylwester Nawrocki wrote: On 02/01/2013 09:33 AM, Sachin Kamat wrote: On 1 February 2013 06:57, Inki Dae inki@samsung.com wrote: For example, If compatible = samsung,g2d-3.0 is added to exynos4210.dtsi, it'd be reasonable. But what if that compatible string is added to exynos4.dtsi?. This case isn't considered for exynos4412 SoC with v4.1. In case of Exynos4 series the base address of G2D ip is different across series. Hence we cannot define it in exynos4.dtsi and need to define the nodes in exynos4xxx.dtsi or specific board files. Thus we can use the version appended compatible string. However even the second option suggested by Sylwester is OK with me or to be even more specific we could go for both SoC as well as version option something like this. compatible = samsung,exynos3110-g2d-3.0 /* for Exynos3110, Exynos4210 */ compatible = samsung,exynos4212-g2d-4.1 /* for Exynos4212, Exynos4412 */ In any case please let me know the final preferred one so that I can update the code send the revised patches. The version with SoC name embedded in it seems most reliable and correct to me. compatible = samsung,exynos3110-fimg-2d /* for Exynos3110 (S5PC110, S5PV210), Exynos4210 */ If this convention will be used, I hope, the known name, S5PV210 can be used. Why don't you use same SoC name with using in arch/arm/? compatible = samsung,exynos4212-fimg-2d /* for Exynos4212, Exynos4412 */ FIMG stands for Fully Interactive Mobile Graphics, and other multimedia IPs follow this naming convention, e.g. FIMG-3D, FIMD (Display Controller), FIMC (Camera), etc. How about MFC? This is just my opinion though, and it seems this is a most common scheme from greping the device tree bindings documentation. IMO, you can grep '$ git grep compatible.*samsung'...or IP name. As Stephen pointed out, and I also did in some other mail thread in the past, not only an IP revision might be required, but also its integration details, specific to an SoC type are important. This actually happens to be the case with FIMC, where same version of one instance of the IP has more data interfaces routed to other SoC subsystems on one SoC type than on other one. Well, I don't think so. As you know Samsung makes many EXYNOS SoCs and nowadays the EXYNOS SoCs include many Samsung own IPs such as multimedia. And the IPs are reused on across Samsung SoCs, and I hope on other SoC vendor's SoC. It means Samsung is no longer just SoC vendor and can be called IP vendor. So let's see other IP vendors, ARM, Synopsys and so on. How are their IPs implemented in kernel? Why should Samsung use the SoC name for their IP? And why should we use old SoC name in futre? For example, see the s3c2410-xxx for i2c, wdt, rtc, i2s and so on. Unfortunately, no one didn't know Samsung should prepare some brand name or future at that time...Just I don't want to undergo trial and error again. I'm still saying why Samsung own IPs cannot be used as IP vendors' ones... I think it won't be possible to use a scheme like samsung-exynos-g2d-3.0 Hmm...I think, the name, 'EXYNOS' is not a brand name for IP... for all IPs. And I would much more like to see a uniform naming convention used, rather than living with a chaotic set of compatible properties, that has a potential to become even more chaotic in the future. Thanks. - Kukjin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D
Kukjin Kim wrote: > Oops, I'm re-sending due to my e-mail client problem :-( > Sylwester Nawrocki wrote: > > > > On 02/01/2013 09:33 AM, Sachin Kamat wrote: > > > On 1 February 2013 06:57, Inki Dae wrote: > > >> > > >> For example, > > >> If compatible = "samsung,g2d-3.0" is added to exynos4210.dtsi, it'd be > > >> reasonable. But what if that compatible string is added to exynos4.dtsi?. > > >> This case isn't considered for exynos4412 SoC with v4.1. > > > > > > In case of Exynos4 series the base address of G2D ip is different > > > across series. Hence we cannot define it in exynos4.dtsi and need to > > > define the nodes in exynos4xxx.dtsi or specific board files. Thus we > > > can use the version appended compatible string. > > > > > > However even the second option suggested by Sylwester is OK with me > or > > > to be even more specific we could go for both SoC as well as version > > > option something like this. > > > > > > compatible = "samsung,exynos3110-g2d-3.0" /* for Exynos3110, > > Exynos4210 */ > > > compatible = "samsung,exynos4212-g2d-4.1" /* for Exynos4212, > > Exynos4412 */ > > > > > > In any case please let me know the final preferred one so that I can > > > update the code send the revised patches. > > > > The version with SoC name embedded in it seems most reliable and correct > > to me. > > > > compatible = "samsung,exynos3110-fimg-2d" /* for Exynos3110 (S5PC110, > > S5PV210), > > Exynos4210 */ > > If this convention will be used, I hope, the known name, S5PV210 can be > used. Why don't you use same SoC name with using in arch/arm/? > > > compatible = "samsung,exynos4212-fimg-2d" /* for Exynos4212, > Exynos4412 > > */ > > > > FIMG stands for Fully Interactive Mobile Graphics, and other multimedia > > IPs follow this naming convention, e.g. FIMG-3D, FIMD (Display Controller), > > FIMC (Camera), etc. > > > How about MFC? > > > This is just my opinion though, and it seems this is a most common scheme > > from greping the device tree bindings documentation. > > > IMO, you can grep '$ git grep compatible.*samsung'...or IP name. > > > As Stephen pointed out, and I also did in some other mail thread in the > > past, not only an IP revision might be required, but also its integration > > details, specific to an SoC type are important. This actually happens > > to be the case with FIMC, where same version of one instance of the IP > > has more data interfaces routed to other SoC subsystems on one SoC type > > than on other one. > > > Well, I don't think so. As you know Samsung makes many EXYNOS SoCs and > nowadays the EXYNOS SoCs include many Samsung own IPs such as > multimedia. And the IPs are reused on across Samsung SoCs, and I hope on > other SoC vendor's SoC. It means Samsung is no longer just SoC vendor and > can be called IP vendor. So let's see other IP vendors, ARM, Synopsys and so > on. How are their IPs implemented in kernel? Why should Samsung use the > SoC name for their IP? And why should we use old SoC name in futre? For > example, see the s3c2410-xxx for i2c, wdt, rtc, i2s and so on. Unfortunately, > no one didn't know Samsung should prepare some brand name or future at > that time...Just I don't want to undergo trial and error again. I'm still > saying > why Samsung own IPs cannot be used as IP vendors' ones... > > > I think it won't be possible to use a scheme like "samsung-exynos-g2d-3.0" > > Hmm...I think, the name, 'EXYNOS' is not a brand name for IP... > > > for all IPs. And I would much more like to see a uniform naming convention > > used, rather than living with a chaotic set of compatible properties, that > > has a potential to become even more chaotic in the future. > Thanks. - Kukjin
[PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D
Sylwester Nawrocki wrote: > > On 02/01/2013 09:33 AM, Sachin Kamat wrote: > > On 1 February 2013 06:57, Inki Dae wrote: > >> > >> For example, > >> If compatible = "samsung,g2d-3.0" is added to exynos4210.dtsi, it'd be > >> reasonable. But what if that compatible string is added to exynos4.dtsi?. > >> This case isn't considered for exynos4412 SoC with v4.1. > > > > In case of Exynos4 series the base address of G2D ip is different > > across series. Hence we cannot define it in exynos4.dtsi and need to > > define the nodes in exynos4xxx.dtsi or specific board files. Thus we > > can use the version appended compatible string. > > > > However even the second option suggested by Sylwester is OK with me or > > to be even more specific we could go for both SoC as well as version > > option something like this. > > > > compatible = "samsung,exynos3110-g2d-3.0" /* for Exynos3110, > Exynos4210 */ > > compatible = "samsung,exynos4212-g2d-4.1" /* for Exynos4212, > Exynos4412 */ > > > > In any case please let me know the final preferred one so that I can > > update the code send the revised patches. > > The version with SoC name embedded in it seems most reliable and correct > to me. > > compatible = "samsung,exynos3110-fimg-2d" /* for Exynos3110 (S5PC110, > S5PV210), > Exynos4210 */ If this convention will be used, I hope, the known name, S5PV210 can be used. Why don't you use same SoC name with using in arch/arm/? > compatible = "samsung,exynos4212-fimg-2d" /* for Exynos4212, Exynos4412 > */ > > FIMG stands for Fully Interactive Mobile Graphics, and other multimedia > IPs follow this naming convention, e.g. FIMG-3D, FIMD (Display Controller), > FIMC (Camera), etc. > How about MFC? > This is just my opinion though, and it seems this is a most common scheme > from greping the device tree bindings documentation. > IMO, you can grep '$ git grep compatible.*samsung'...or IP name. > As Stephen pointed out, and I also did in some other mail thread in the > past, not only an IP revision might be required, but also its integration > details, specific to an SoC type are important. This actually happens > to be the case with FIMC, where same version of one instance of the IP > has more data interfaces routed to other SoC subsystems on one SoC type > than on other one. > Well, I don't think so. As you know Samsung makes many EXYNOS SoCs and nowadays the EXYNOS SoCs include many Samsung own IPs such as multimedia. And the IPs are reused on across Samsung SoCs, and I hope on other SoC vendor's SoC. It means Samsung is no longer just SoC vendor and can be called IP vendor. So let's see other IP vendors, ARM, Synopsys and so on. How are their IPs implemented in kernel? Why should Samsung use the SoC name for their IP? And why should we use old SoC name in futre? For example, see the s3c2410-xxx for i2c, wdt, rtc, i2s and so on. Unfortunately, no one didn't know Samsung should prepare some brand name or future at that time...Just I don't want to undergo trial and error again. I'm still saying why Samsung own IPs cannot be used as IP vendors' ones... > I think it won't be possible to use a scheme like "samsung-exynos-g2d-3.0" Hmm...I think, the name, 'EXYNOS' is not a brand name for IP... > for all IPs. And I would much more like to see a uniform naming convention > used, rather than living with a chaotic set of compatible properties, that > has a potential to become even more chaotic in the future. > Thanks. - Kukjin
RE: [PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D
Sylwester Nawrocki wrote: On 02/01/2013 09:33 AM, Sachin Kamat wrote: On 1 February 2013 06:57, Inki Dae inki@samsung.com wrote: For example, If compatible = samsung,g2d-3.0 is added to exynos4210.dtsi, it'd be reasonable. But what if that compatible string is added to exynos4.dtsi?. This case isn't considered for exynos4412 SoC with v4.1. In case of Exynos4 series the base address of G2D ip is different across series. Hence we cannot define it in exynos4.dtsi and need to define the nodes in exynos4xxx.dtsi or specific board files. Thus we can use the version appended compatible string. However even the second option suggested by Sylwester is OK with me or to be even more specific we could go for both SoC as well as version option something like this. compatible = samsung,exynos3110-g2d-3.0 /* for Exynos3110, Exynos4210 */ compatible = samsung,exynos4212-g2d-4.1 /* for Exynos4212, Exynos4412 */ In any case please let me know the final preferred one so that I can update the code send the revised patches. The version with SoC name embedded in it seems most reliable and correct to me. compatible = samsung,exynos3110-fimg-2d /* for Exynos3110 (S5PC110, S5PV210), Exynos4210 */ If this convention will be used, I hope, the known name, S5PV210 can be used. Why don't you use same SoC name with using in arch/arm/? compatible = samsung,exynos4212-fimg-2d /* for Exynos4212, Exynos4412 */ FIMG stands for Fully Interactive Mobile Graphics, and other multimedia IPs follow this naming convention, e.g. FIMG-3D, FIMD (Display Controller), FIMC (Camera), etc. How about MFC? This is just my opinion though, and it seems this is a most common scheme from greping the device tree bindings documentation. IMO, you can grep '$ git grep compatible.*samsung'...or IP name. As Stephen pointed out, and I also did in some other mail thread in the past, not only an IP revision might be required, but also its integration details, specific to an SoC type are important. This actually happens to be the case with FIMC, where same version of one instance of the IP has more data interfaces routed to other SoC subsystems on one SoC type than on other one. Well, I don't think so. As you know Samsung makes many EXYNOS SoCs and nowadays the EXYNOS SoCs include many Samsung own IPs such as multimedia. And the IPs are reused on across Samsung SoCs, and I hope on other SoC vendor's SoC. It means Samsung is no longer just SoC vendor and can be called IP vendor. So let's see other IP vendors, ARM, Synopsys and so on. How are their IPs implemented in kernel? Why should Samsung use the SoC name for their IP? And why should we use old SoC name in futre? For example, see the s3c2410-xxx for i2c, wdt, rtc, i2s and so on. Unfortunately, no one didn't know Samsung should prepare some brand name or future at that time...Just I don't want to undergo trial and error again. I'm still saying why Samsung own IPs cannot be used as IP vendors' ones... I think it won't be possible to use a scheme like samsung-exynos-g2d-3.0 Hmm...I think, the name, 'EXYNOS' is not a brand name for IP... for all IPs. And I would much more like to see a uniform naming convention used, rather than living with a chaotic set of compatible properties, that has a potential to become even more chaotic in the future. Thanks. - Kukjin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D
Sylwester Nawrocki wrote:
>
> Hi Inki,
>
Hi Sylwester and Inki,
> On 01/31/2013 02:30 AM, Inki Dae wrote:
> >> -Original Message-
> >> From: Sylwester Nawrocki [mailto:sylvester.nawrocki at gmail.com]
> >> Sent: Thursday, January 31, 2013 5:51 AM
> >> To: Inki Dae
> >> Cc: Sachin Kamat; linux-media at vger.kernel.org; dri-
> >> devel at lists.freedesktop.org; devicetree-discuss at lists.ozlabs.org;
> >> patches at linaro.org; s.nawrocki at samsung.com
> >> Subject: Re: [PATCH 2/2] drm/exynos: Add device tree based discovery
> >> support for G2D
> >>
> >> On 01/30/2013 09:50 AM, Inki Dae wrote:
> +static const struct of_device_id exynos_g2d_match[] = {
> + { .compatible = "samsung,g2d-v41" },
> >>>
> >>> not only Exynos5 and also Exyno4 has the g2d gpu and drm-based g2d
> >>> driver shoud support for all Exynos SoCs. How about using
> >>> "samsung,exynos5-g2d" instead and adding a new property 'version' to
> >>> identify ip version more surely? With this, we could know which SoC
> >>> and its g2d ip version. The version property could have '0x14' or
> >>> others. And please add descriptions to dt document.
> >>
> >> Err no. Are you suggesting using "samsung,exynos5-g2d" compatible
> string
> >> for Exynos4 specific IPs ? This would not be correct, and you still can
> >
> > I assumed the version 'v41' is the ip for Exynos5 SoC. So if this
version
> > means Exynos4 SoC then it should be "samsung,exynos4-g2d".
>
> Yes, v3.0 is implemented in the S5PC110 (Exynos3110) SoCs and Exynos4210,
> V4.1 can be found in Exynos4212 and Exynos4412, if I'm not mistaken.
>
> So we could have:
>
> compatible = "samsung,exynos-g2d-3.0" /* for Exynos3110, Exynos4210 */
> compatible = "samsung,exynos-g2d-4.1" /* for Exynos4212, Exynos4412 */
>
In my opinion, this is better than later. Because as I said, when we can use
IP version to identify, it is more clear and can be used
One more, how about following?
compatible = "samsung,g2d-3.0"
compatible = "samsung,g2d-4.1"
I think, just g2d is enough. For example, we are using it for mfc like
following: compatible = "samsung.mfc-v6"
> or alternatively
>
> compatible = "samsung,exynos3110-g2d" /* for Exynos3110, Exynos4210 */
> compatible = "samsung,exynos4212-g2d" /* for Exynos4212, Exynos4412 */
>
Thanks.
- Kukjin
RE: [PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D
Sylwester Nawrocki wrote:
Hi Inki,
Hi Sylwester and Inki,
On 01/31/2013 02:30 AM, Inki Dae wrote:
-Original Message-
From: Sylwester Nawrocki [mailto:sylvester.nawro...@gmail.com]
Sent: Thursday, January 31, 2013 5:51 AM
To: Inki Dae
Cc: Sachin Kamat; linux-me...@vger.kernel.org; dri-
de...@lists.freedesktop.org; devicetree-disc...@lists.ozlabs.org;
patc...@linaro.org; s.nawro...@samsung.com
Subject: Re: [PATCH 2/2] drm/exynos: Add device tree based discovery
support for G2D
On 01/30/2013 09:50 AM, Inki Dae wrote:
+static const struct of_device_id exynos_g2d_match[] = {
+ { .compatible = samsung,g2d-v41 },
not only Exynos5 and also Exyno4 has the g2d gpu and drm-based g2d
driver shoud support for all Exynos SoCs. How about using
samsung,exynos5-g2d instead and adding a new property 'version' to
identify ip version more surely? With this, we could know which SoC
and its g2d ip version. The version property could have '0x14' or
others. And please add descriptions to dt document.
Err no. Are you suggesting using samsung,exynos5-g2d compatible
string
for Exynos4 specific IPs ? This would not be correct, and you still can
I assumed the version 'v41' is the ip for Exynos5 SoC. So if this
version
means Exynos4 SoC then it should be samsung,exynos4-g2d.
Yes, v3.0 is implemented in the S5PC110 (Exynos3110) SoCs and Exynos4210,
V4.1 can be found in Exynos4212 and Exynos4412, if I'm not mistaken.
So we could have:
compatible = samsung,exynos-g2d-3.0 /* for Exynos3110, Exynos4210 */
compatible = samsung,exynos-g2d-4.1 /* for Exynos4212, Exynos4412 */
In my opinion, this is better than later. Because as I said, when we can use
IP version to identify, it is more clear and can be used
One more, how about following?
compatible = samsung,g2d-3.0
compatible = samsung,g2d-4.1
I think, just g2d is enough. For example, we are using it for mfc like
following: compatible = samsung.mfc-v6
or alternatively
compatible = samsung,exynos3110-g2d /* for Exynos3110, Exynos4210 */
compatible = samsung,exynos4212-g2d /* for Exynos4212, Exynos4412 */
Thanks.
- Kukjin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2 0/5] arm: samsung: Move FIMD headers to include/video/
Florian Tobias Schandinat wrote: > > On 08/01/2012 02:28 AM, Kukjin Kim wrote: > > Leela Krishna Amudala wrote: > >> > >> This patchset moves the contents of regs-fb-v4.h and regs-fb.h from > arch > >> side > >> to include/video/samsung_fimd.h > >> > >> This patchset is created and rebased against master branch of torvalds > >> tree. > >> Tested on smdk5250 board, build tested for other boards. > >> > > (Cc'ed Florian Tobias Schandinat) > > > > Yeah, since it's merge window, this series could be created against on > > mainline. And IMO, would be helpful to us if this series could be sent > to > > upstream via samsung tree after reviewing, because this touches too many > > files in samsung tree and just adds include/video/samsung_fimd.h. But > I'm > > not sure the added inclusion will be used in other file of drivers/video. > If > > so, I can provide some topic branch can be merged into Florian's tree. > > Florian, how about? > > Using a topic branch to merge it in both trees sounds like a good plan > to me. > Florian, Please pull following topic branch we talked. I already merged it into my -next. git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git v3.7-for-florian Note, I applied Leela's V4 patches not this V2 series. If any problems, please kindly let me know. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee: Linux 3.6-rc1 (2012-08-02 16:38:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git v3.7-for-florian Leela Krishna Amudala (2): include/video: move fimd register headers from platform to include/video include/video: Add register offsets for FIMD version 8 arch/arm/mach-exynos/mach-nuri.c |2 +- arch/arm/mach-exynos/mach-origen.c |2 +- arch/arm/mach-exynos/mach-smdk4x12.c |2 +- arch/arm/mach-exynos/mach-smdkv310.c |2 +- arch/arm/mach-exynos/mach-universal_c210.c |2 +- arch/arm/mach-exynos/setup-fimd0.c |2 +- arch/arm/mach-s3c24xx/mach-smdk2416.c |2 +- arch/arm/mach-s3c64xx/mach-anw6410.c |2 +- arch/arm/mach-s3c64xx/mach-crag6410.c |2 +- arch/arm/mach-s3c64xx/mach-hmt.c |2 +- arch/arm/mach-s3c64xx/mach-mini6410.c |2 +- arch/arm/mach-s3c64xx/mach-ncp.c |2 +- arch/arm/mach-s3c64xx/mach-real6410.c |2 +- arch/arm/mach-s3c64xx/mach-smartq5.c |2 +- arch/arm/mach-s3c64xx/mach-smartq7.c |2 +- arch/arm/mach-s3c64xx/mach-smdk6410.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6440.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6450.c |2 +- arch/arm/mach-s5pc100/mach-smdkc100.c |2 +- arch/arm/mach-s5pv210/mach-aquila.c|2 +- arch/arm/mach-s5pv210/mach-goni.c |2 +- arch/arm/mach-s5pv210/mach-smdkv210.c |2 +- arch/arm/plat-samsung/include/plat/regs-fb-v4.h| 159 drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +- drivers/video/s3c-fb.c |2 +- .../plat/regs-fb.h => include/video/samsung_fimd.h | 152 +-- 26 files changed, 165 insertions(+), 194 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h rename arch/arm/plat-samsung/include/plat/regs-fb.h => include/video/samsung_fimd.h (73%)
RE: [PATCH V2 0/5] arm: samsung: Move FIMD headers to include/video/
Florian Tobias Schandinat wrote: On 08/01/2012 02:28 AM, Kukjin Kim wrote: Leela Krishna Amudala wrote: This patchset moves the contents of regs-fb-v4.h and regs-fb.h from arch side to include/video/samsung_fimd.h This patchset is created and rebased against master branch of torvalds tree. Tested on smdk5250 board, build tested for other boards. (Cc'ed Florian Tobias Schandinat) Yeah, since it's merge window, this series could be created against on mainline. And IMO, would be helpful to us if this series could be sent to upstream via samsung tree after reviewing, because this touches too many files in samsung tree and just adds include/video/samsung_fimd.h. But I'm not sure the added inclusion will be used in other file of drivers/video. If so, I can provide some topic branch can be merged into Florian's tree. Florian, how about? Using a topic branch to merge it in both trees sounds like a good plan to me. Florian, Please pull following topic branch we talked. I already merged it into my -next. git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git v3.7-for-florian Note, I applied Leela's V4 patches not this V2 series. If any problems, please kindly let me know. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee: Linux 3.6-rc1 (2012-08-02 16:38:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git v3.7-for-florian Leela Krishna Amudala (2): include/video: move fimd register headers from platform to include/video include/video: Add register offsets for FIMD version 8 arch/arm/mach-exynos/mach-nuri.c |2 +- arch/arm/mach-exynos/mach-origen.c |2 +- arch/arm/mach-exynos/mach-smdk4x12.c |2 +- arch/arm/mach-exynos/mach-smdkv310.c |2 +- arch/arm/mach-exynos/mach-universal_c210.c |2 +- arch/arm/mach-exynos/setup-fimd0.c |2 +- arch/arm/mach-s3c24xx/mach-smdk2416.c |2 +- arch/arm/mach-s3c64xx/mach-anw6410.c |2 +- arch/arm/mach-s3c64xx/mach-crag6410.c |2 +- arch/arm/mach-s3c64xx/mach-hmt.c |2 +- arch/arm/mach-s3c64xx/mach-mini6410.c |2 +- arch/arm/mach-s3c64xx/mach-ncp.c |2 +- arch/arm/mach-s3c64xx/mach-real6410.c |2 +- arch/arm/mach-s3c64xx/mach-smartq5.c |2 +- arch/arm/mach-s3c64xx/mach-smartq7.c |2 +- arch/arm/mach-s3c64xx/mach-smdk6410.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6440.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6450.c |2 +- arch/arm/mach-s5pc100/mach-smdkc100.c |2 +- arch/arm/mach-s5pv210/mach-aquila.c|2 +- arch/arm/mach-s5pv210/mach-goni.c |2 +- arch/arm/mach-s5pv210/mach-smdkv210.c |2 +- arch/arm/plat-samsung/include/plat/regs-fb-v4.h| 159 drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +- drivers/video/s3c-fb.c |2 +- .../plat/regs-fb.h = include/video/samsung_fimd.h | 152 +-- 26 files changed, 165 insertions(+), 194 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h rename arch/arm/plat-samsung/include/plat/regs-fb.h = include/video/samsung_fimd.h (73%) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V4 0/2] arm: samsung: Move FIMD headers to include/video/
Leela Krishna Amudala wrote: > > This patchset moves the contents of regs-fb-v4.h and regs-fb.h from arch > side > to include/video/samsung_fimd.h > > This patchset is created and rebased against master branch of torvalds > tree. > Tested on smdk5250 board, build tested for other boards. > > Changes from version 3: > - Squashed 1st, 3rd, 4th and 5th patches from version 3 > > Changes from version 2: > - Changed the EXYNOS5_xxx macro name to FIMD_V8_xxx > - Moved the header inclusion under same kind > > Changes from version 1: > - Split the patches as per Sylwester comments > - Changed FIMD_V8_xxx macro to EXYNOS5_xxx > > Leela Krishna Amudala (2): > include/video: move fimd register headers from platform to > include/video > include/video: Add register offsets for FIMD version 8 > > arch/arm/mach-exynos/mach-nuri.c |2 +- > arch/arm/mach-exynos/mach-origen.c |2 +- > arch/arm/mach-exynos/mach-smdk4x12.c |2 +- > arch/arm/mach-exynos/mach-smdkv310.c |2 +- > arch/arm/mach-exynos/mach-universal_c210.c |2 +- > arch/arm/mach-exynos/setup-fimd0.c |2 +- > arch/arm/mach-s3c24xx/mach-smdk2416.c |2 +- > arch/arm/mach-s3c64xx/mach-anw6410.c |2 +- > arch/arm/mach-s3c64xx/mach-crag6410.c |2 +- > arch/arm/mach-s3c64xx/mach-hmt.c |2 +- > arch/arm/mach-s3c64xx/mach-mini6410.c |2 +- > arch/arm/mach-s3c64xx/mach-ncp.c |2 +- > arch/arm/mach-s3c64xx/mach-real6410.c |2 +- > arch/arm/mach-s3c64xx/mach-smartq5.c |2 +- > arch/arm/mach-s3c64xx/mach-smartq7.c |2 +- > arch/arm/mach-s3c64xx/mach-smdk6410.c |2 +- > arch/arm/mach-s5p64x0/mach-smdk6440.c |2 +- > arch/arm/mach-s5p64x0/mach-smdk6450.c |2 +- > arch/arm/mach-s5pc100/mach-smdkc100.c |2 +- > arch/arm/mach-s5pv210/mach-aquila.c|2 +- > arch/arm/mach-s5pv210/mach-goni.c |2 +- > arch/arm/mach-s5pv210/mach-smdkv210.c |2 +- > arch/arm/plat-samsung/include/plat/regs-fb-v4.h| 159 > > drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +- > drivers/video/s3c-fb.c |2 +- > .../plat/regs-fb.h => include/video/samsung_fimd.h | 152 > +-- > 26 files changed, 165 insertions(+), 194 deletions(-) > delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h > rename arch/arm/plat-samsung/include/plat/regs-fb.h => > include/video/samsung_fimd.h (73%) Looks OK to me. Will apply into topic branch, 'v3.7-for-florian' for Florian's pulling. If there is no objection for a couple of days, I will merge this into for-next and send to Florian. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.
RE: [PATCH V4 0/2] arm: samsung: Move FIMD headers to include/video/
Leela Krishna Amudala wrote: This patchset moves the contents of regs-fb-v4.h and regs-fb.h from arch side to include/video/samsung_fimd.h This patchset is created and rebased against master branch of torvalds tree. Tested on smdk5250 board, build tested for other boards. Changes from version 3: - Squashed 1st, 3rd, 4th and 5th patches from version 3 Changes from version 2: - Changed the EXYNOS5_xxx macro name to FIMD_V8_xxx - Moved the header inclusion under same kind Changes from version 1: - Split the patches as per Sylwester comments - Changed FIMD_V8_xxx macro to EXYNOS5_xxx Leela Krishna Amudala (2): include/video: move fimd register headers from platform to include/video include/video: Add register offsets for FIMD version 8 arch/arm/mach-exynos/mach-nuri.c |2 +- arch/arm/mach-exynos/mach-origen.c |2 +- arch/arm/mach-exynos/mach-smdk4x12.c |2 +- arch/arm/mach-exynos/mach-smdkv310.c |2 +- arch/arm/mach-exynos/mach-universal_c210.c |2 +- arch/arm/mach-exynos/setup-fimd0.c |2 +- arch/arm/mach-s3c24xx/mach-smdk2416.c |2 +- arch/arm/mach-s3c64xx/mach-anw6410.c |2 +- arch/arm/mach-s3c64xx/mach-crag6410.c |2 +- arch/arm/mach-s3c64xx/mach-hmt.c |2 +- arch/arm/mach-s3c64xx/mach-mini6410.c |2 +- arch/arm/mach-s3c64xx/mach-ncp.c |2 +- arch/arm/mach-s3c64xx/mach-real6410.c |2 +- arch/arm/mach-s3c64xx/mach-smartq5.c |2 +- arch/arm/mach-s3c64xx/mach-smartq7.c |2 +- arch/arm/mach-s3c64xx/mach-smdk6410.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6440.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6450.c |2 +- arch/arm/mach-s5pc100/mach-smdkc100.c |2 +- arch/arm/mach-s5pv210/mach-aquila.c|2 +- arch/arm/mach-s5pv210/mach-goni.c |2 +- arch/arm/mach-s5pv210/mach-smdkv210.c |2 +- arch/arm/plat-samsung/include/plat/regs-fb-v4.h| 159 drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +- drivers/video/s3c-fb.c |2 +- .../plat/regs-fb.h = include/video/samsung_fimd.h | 152 +-- 26 files changed, 165 insertions(+), 194 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h rename arch/arm/plat-samsung/include/plat/regs-fb.h = include/video/samsung_fimd.h (73%) Looks OK to me. Will apply into topic branch, 'v3.7-for-florian' for Florian's pulling. If there is no objection for a couple of days, I will merge this into for-next and send to Florian. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2 5/5] arm: samsung: delete frame buffer header files from platform
Sylwester Nawrocki wrote: > > Hi, > > On 08/01/2012 11:39 AM, Kukjin Kim wrote: > > Leela Krishna Amudala wrote: > >> On Wed, Aug 1, 2012 at 7:34 AM, Kukjin Kim > wrote: > >>> Leela Krishna Amudala wrote: > >>>> > >>>> The FIMD register headers are moved to include/video/ > >>>> hence, deleting these files from platform side > >>>> > >>>> Signed-off-by: Leela Krishna Amudala > >>>> --- > >>>> arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 159 - > >>>> arch/arm/plat-samsung/include/plat/regs-fb.h| 403 > >>> --- > >>>> > >>>> 2 files changed, 0 insertions(+), 562 deletions(-) > >>>> delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h > >>>> delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h > >>>> > >>> No. This should be squashed into first patch on this series. See below. > >>> > >>> arch/arm/plat-samsung/include/plat/regs-fb-v4.h| 159 > >>> > >>> .../plat/regs-fb.h => include/video/samsung_fimd.h | 145 > >>> -- > >>> 2 files changed, 134 insertions(+), 170 deletions(-) > >>> delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h > >>> rename arch/arm/plat-samsung/include/plat/regs-fb.h => > >>> include/video/samsung_fimd.h (74%) > >>> > >> > >> If I squash it with the first patch and if somebody set that as a head > >> commit, it will break the build. Hence, splitted it up from the first > >> patch. > >> > > NACK. your changes are not adding just moving. So should be squashed. If > > required, you could create just one patch for moving them, probably, 1st, > > 3rd, 4th and 5th patches into one patch. > > Yes, this patch series is mainly moving files around. But to avoid git > bisect breakage, it should be split as it is done now, or the whole > series should be squashed into one patch. The latter might be even easier > to handle, but having a single patch touching arch/arm/ and drivers/ > might not be a good idea. If you're fine handling that, then we just > need to squash this series into single patch. > It just need to be ensured, IMO, there is no bisection breakage. > I know you meant. But we don't need to keep the changes 'adding and removing' for just moving on this. I commented on 0/5 patch in this series before, if this is ready, I will create topic branch so that it could be merged into both mine and Florian's. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.
[PATCH V2 0/5] arm: samsung: Move FIMD headers to include/video/
Florian Tobias Schandinat wrote: > > On 08/01/2012 02:28 AM, Kukjin Kim wrote: > > Leela Krishna Amudala wrote: > >> > >> This patchset moves the contents of regs-fb-v4.h and regs-fb.h from > arch > >> side > >> to include/video/samsung_fimd.h > >> > >> This patchset is created and rebased against master branch of torvalds > >> tree. > >> Tested on smdk5250 board, build tested for other boards. > >> > > (Cc'ed Florian Tobias Schandinat) > > > > Yeah, since it's merge window, this series could be created against on > > mainline. And IMO, would be helpful to us if this series could be sent > to > > upstream via samsung tree after reviewing, because this touches too many > > files in samsung tree and just adds include/video/samsung_fimd.h. But > I'm > > not sure the added inclusion will be used in other file of drivers/video. > If > > so, I can provide some topic branch can be merged into Florian's tree. > > Florian, how about? > > Using a topic branch to merge it in both trees sounds like a good plan > to me. > Sure, if this change is ready, I will create topic branch then let you know. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.
[PATCH V2 5/5] arm: samsung: delete frame buffer header files from platform
Leela Krishna Amudala wrote: > > Hello Kgene, > > On Wed, Aug 1, 2012 at 7:34 AM, Kukjin Kim wrote: > > Leela Krishna Amudala wrote: > >> > >> The FIMD register headers are moved to include/video/ > >> hence, deleting these files from platform side > >> > >> Signed-off-by: Leela Krishna Amudala > >> --- > >> arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 159 - > >> arch/arm/plat-samsung/include/plat/regs-fb.h| 403 > > --- > >> > >> 2 files changed, 0 insertions(+), 562 deletions(-) > >> delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h > >> delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h > >> > > No. This should be squashed into first patch on this series. See below. > > > > arch/arm/plat-samsung/include/plat/regs-fb-v4.h| 159 > > > > .../plat/regs-fb.h => include/video/samsung_fimd.h | 145 > > -- > > 2 files changed, 134 insertions(+), 170 deletions(-) > > delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h > > rename arch/arm/plat-samsung/include/plat/regs-fb.h => > > include/video/samsung_fimd.h (74%) > > > > If I squash it with the first patch and if somebody set that as a head > commit, it will break the build. Hence, splitted it up from the first > patch. > NACK. your changes are not adding just moving. So should be squashed. If required, you could create just one patch for moving them, probably, 1st, 3rd, 4th and 5th patches into one patch. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. > Thank you Sylwester for suggesting this split up change. > > Regards, > Leela Krishna
[PATCH V2 0/5] arm: samsung: Move FIMD headers to include/video/
Leela Krishna Amudala wrote: > > This patchset moves the contents of regs-fb-v4.h and regs-fb.h from arch > side > to include/video/samsung_fimd.h > > This patchset is created and rebased against master branch of torvalds > tree. > Tested on smdk5250 board, build tested for other boards. > (Cc'ed Florian Tobias Schandinat) Yeah, since it's merge window, this series could be created against on mainline. And IMO, would be helpful to us if this series could be sent to upstream via samsung tree after reviewing, because this touches too many files in samsung tree and just adds include/video/samsung_fimd.h. But I'm not sure the added inclusion will be used in other file of drivers/video. If so, I can provide some topic branch can be merged into Florian's tree. Florian, how about? Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. > Changes from version 1: > - Split the patches as per Sylwester comments > - Changed FIMD_V8_xxx macro to EXYNOS5_xxx > > Leela Krishna Amudala (5): > include/video: Add samsung FIMD register header > include/video: Add Exynos5 specific FIMD register offsets > arm: samsung: Include the modified FIMD header file > driver: Include the modified FIMD header file > arm: samsung: delete frame buffer header files from platform > > arch/arm/mach-exynos/mach-nuri.c |2 +- > arch/arm/mach-exynos/mach-origen.c |2 +- > arch/arm/mach-exynos/mach-smdk4x12.c |2 +- > arch/arm/mach-exynos/mach-smdkv310.c |2 +- > arch/arm/mach-exynos/mach-universal_c210.c |2 +- > arch/arm/mach-exynos/setup-fimd0.c |2 +- > arch/arm/mach-s3c24xx/mach-smdk2416.c |2 +- > arch/arm/mach-s3c64xx/mach-anw6410.c |2 +- > arch/arm/mach-s3c64xx/mach-crag6410.c |2 +- > arch/arm/mach-s3c64xx/mach-hmt.c |2 +- > arch/arm/mach-s3c64xx/mach-mini6410.c |2 +- > arch/arm/mach-s3c64xx/mach-ncp.c |2 +- > arch/arm/mach-s3c64xx/mach-real6410.c |2 +- > arch/arm/mach-s3c64xx/mach-smartq5.c |2 +- > arch/arm/mach-s3c64xx/mach-smartq7.c |2 +- > arch/arm/mach-s3c64xx/mach-smdk6410.c |2 +- > arch/arm/mach-s5p64x0/mach-smdk6440.c |2 +- > arch/arm/mach-s5p64x0/mach-smdk6450.c |2 +- > arch/arm/mach-s5pc100/mach-smdkc100.c |2 +- > arch/arm/mach-s5pv210/mach-aquila.c|2 +- > arch/arm/mach-s5pv210/mach-goni.c |2 +- > arch/arm/mach-s5pv210/mach-smdkv210.c |2 +- > arch/arm/plat-samsung/include/plat/regs-fb-v4.h| 159 > > drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +- > drivers/video/s3c-fb.c |2 +- > .../plat/regs-fb.h => include/video/samsung_fimd.h | 152 > +-- > 26 files changed, 165 insertions(+), 194 deletions(-) > delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h > rename arch/arm/plat-samsung/include/plat/regs-fb.h => > include/video/samsung_fimd.h (74%)
[PATCH V2 4/5] driver: Include the modified FIMD header file
Leela Krishna Amudala wrote: > > The fimd register headers have been moved to include/video/ > hence, modifying the driver files accordingly. > > Signed-off-by: Leela Krishna Amudala > --- > drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +- > drivers/video/s3c-fb.c |2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > [...] > --- a/drivers/video/s3c-fb.c > +++ b/drivers/video/s3c-fb.c > @@ -26,7 +26,7 @@ > #include > > #include > -#include > +#include > #include > See my previous comments. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.
[PATCH V2 3/5] arm: samsung: Include the modified FIMD header file
Leela Krishna Amudala wrote: > > The fimd register headers have been moved to include/video/ > hence, modifying the machine files accordingly. > > Signed-off-by: Leela Krishna Amudala > --- > arch/arm/mach-exynos/mach-nuri.c |2 +- > arch/arm/mach-exynos/mach-origen.c |2 +- > arch/arm/mach-exynos/mach-smdk4x12.c |2 +- > arch/arm/mach-exynos/mach-smdkv310.c |2 +- > arch/arm/mach-exynos/mach-universal_c210.c |2 +- > arch/arm/mach-exynos/setup-fimd0.c |2 +- > arch/arm/mach-s3c24xx/mach-smdk2416.c |2 +- > arch/arm/mach-s3c64xx/mach-anw6410.c |2 +- > arch/arm/mach-s3c64xx/mach-crag6410.c |2 +- > arch/arm/mach-s3c64xx/mach-hmt.c |2 +- > arch/arm/mach-s3c64xx/mach-mini6410.c |2 +- > arch/arm/mach-s3c64xx/mach-ncp.c |2 +- > arch/arm/mach-s3c64xx/mach-real6410.c |2 +- > arch/arm/mach-s3c64xx/mach-smartq5.c |2 +- > arch/arm/mach-s3c64xx/mach-smartq7.c |2 +- > arch/arm/mach-s3c64xx/mach-smdk6410.c |2 +- > arch/arm/mach-s5p64x0/mach-smdk6440.c |2 +- > arch/arm/mach-s5p64x0/mach-smdk6450.c |2 +- > arch/arm/mach-s5pc100/mach-smdkc100.c |2 +- > arch/arm/mach-s5pv210/mach-aquila.c|2 +- > arch/arm/mach-s5pv210/mach-goni.c |2 +- > arch/arm/mach-s5pv210/mach-smdkv210.c |2 +- > 22 files changed, 22 insertions(+), 22 deletions(-) > > diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach- > nuri.c > index f98a83a..573a0c4 100644 > --- a/arch/arm/mach-exynos/mach-nuri.c > +++ b/arch/arm/mach-exynos/mach-nuri.c > @@ -39,7 +39,7 @@ > #include > > #include > -#include > +#include > #include > #include > #include NO! Don't just replace it. Please put the inclusions with the same kind like following. diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach-nuri.c index ea785fc..90d8daa 100644 --- a/arch/arm/mach-exynos/mach-nuri.c +++ b/arch/arm/mach-exynos/mach-nuri.c @@ -29,6 +29,7 @@ #include #include +#include #include #include #include @@ -39,7 +40,6 @@ #include #include -#include #include #include #include Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.
[PATCH V2 2/5] include/video: Add Exynos5 specific FIMD register offsets
Leela Krishna Amudala wrote: > > Exynos5 has VIDTCON and VIDCON registers at different offsets > from the previous SOCs. Hence, adding the macros. > > Signed-off-by: Leela Krishna Amudala > --- > include/video/samsung_fimd.h |7 +++ > 1 files changed, 7 insertions(+), 0 deletions(-) > > diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h > index e979f42..820f190 100644 > --- a/include/video/samsung_fimd.h > +++ b/include/video/samsung_fimd.h > @@ -524,3 +524,10 @@ > * 1110 -none- -none- -none- -none--none- > * -none- -none- -none- -none--none- > */ > + > +/*EXYNOS5 FIMD REG OFFSET */ > +#define EXYNOS5_VIDTCON0 (0x20010) > +#define EXYNOS5_VIDTCON1 (0x20014) > +#define EXYNOS5_VIDTCON2 (0x20018) > +#define EXYNOS5_VIDTCON3 (0x2001C) > +#define EXYNOS5_VIDCON1 (0x20004) > -- > 1.7.0.4 All of EXYNOS5 SoCs including upcoming SoCs _really_ have same address like above? I don't think so. You need to consider its flexibility or some compatibility when definitions are added. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.
[PATCH V2 1/5] include/video: Add samsung FIMD register header
Leela Krishna Amudala wrote: > > This patch copies the contents from regs-fb-v4.h and regs-fb.h to > include/video/samsung_fimd.h > > Signed-off-by: Leela Krishna Amudala > --- > include/video/samsung_fimd.h | 526 > ++ > 1 files changed, 526 insertions(+), 0 deletions(-) > create mode 100644 include/video/samsung_fimd.h > Firstly, please check my comment on your previous patches. And I don't see following definitions are needed and used now. If some definitions are not needed, they can be removed. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.
[PATCH V2 5/5] arm: samsung: delete frame buffer header files from platform
Leela Krishna Amudala wrote: > > The FIMD register headers are moved to include/video/ > hence, deleting these files from platform side > > Signed-off-by: Leela Krishna Amudala > --- > arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 159 - > arch/arm/plat-samsung/include/plat/regs-fb.h| 403 --- > > 2 files changed, 0 insertions(+), 562 deletions(-) > delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h > delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h > No. This should be squashed into first patch on this series. See below. arch/arm/plat-samsung/include/plat/regs-fb-v4.h| 159 .../plat/regs-fb.h => include/video/samsung_fimd.h | 145 -- 2 files changed, 134 insertions(+), 170 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h rename arch/arm/plat-samsung/include/plat/regs-fb.h => include/video/samsung_fimd.h (74%) Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.
[PATCH 1/3] Move FIMD register headers to include/video/
Marek Szyprowski wrote:
>
> Hello,
>
Hi all,
[...]
> > static struct s3c_fb_driverdata s3c_fb_data_exynos5 = {
> > .variant = {
> > .nr_windows = 5,
> > - .vidtcon= VIDTCON0,
> > + .vidtcon= FIMD_V8_VIDTCON0,
>
> Yes, this method looks good imo. Maybe even having something like
> vidtcon_base in
> variant structure will be enough to cover all VIDTCON0-3 registers.
>
Yes, I agree. And how about changing the name of s3c_fb_drvierdata to
xxx_fimd_v8 not xxx_fimd_exynos5? It's time to use independent from SoC name
because we don't have any guarantee of same address on all of EXYNOS5 SoCs.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
[PATCH 1/3] Move FIMD register headers to include/video/
Jingoo Han wrote: > > On Monday, July 30, 2012 8:16 PM, Leela Krishna Amudala wrote: > > > > Hello Jingoo Han, > > > > On Mon, Jul 30, 2012 at 2:23 PM, Jingoo Han wrote: > > > On Monday, July 30, 2012 5:45 PM, Leela Krishna Amudala wrote: > > >> > > >> Moved the contents of regs-fb-v4.h and regs-fb.h from arch side > > >> to include/video/samsung_fimd.h > > >> > > >> Signed-off-by: Leela Krishna Amudala > > >> --- > > >> arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 159 --- > > >> arch/arm/plat-samsung/include/plat/regs-fb.h| 403 --- > -- > > >> include/video/samsung_fimd.h| 533 > +++ > > >> 3 files changed, 533 insertions(+), 562 deletions(-) > > >> delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h > > >> delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h > > >> create mode 100644 include/video/samsung_fimd.h > > >> > > >> +*/ > > >> + > > >> +/*FIMD V8 REG OFFSET */ > > >> +#define FIMD_V8_VIDTCON0 (0x20010) > > >> +#define FIMD_V8_VIDTCON1 (0x20014) > > >> +#define FIMD_V8_VIDTCON2 (0x20018) > > >> +#define FIMD_V8_VIDTCON3 (0x2001C) > > >> +#define FIMD_V8_VIDCON1 (0x20004) > > > How about using soc_is_exynos5250()? > > +#define VIDTCON0 (soc_is_exynos5250() ? \ > + (0x20010) : (0x10)) > > In this case, the FIMD driver does not need to change. > Also, one binary is available. > I don't agree. Do you _really_ think the address will be fixed on other SoCs including upcoming SoCs? I'd prefer to use the version or something for it. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.
[PATCH 1/3] Move FIMD register headers to include/video/
Leela Krishna Amudala wrote: > > Moved the contents of regs-fb-v4.h and regs-fb.h from arch side > to include/video/samsung_fimd.h > > Signed-off-by: Leela Krishna Amudala > --- > arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 159 --- > arch/arm/plat-samsung/include/plat/regs-fb.h| 403 - > include/video/samsung_fimd.h| 533 +++ > 3 files changed, 533 insertions(+), 562 deletions(-) > delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h > delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h > create mode 100644 include/video/samsung_fimd.h > + I have some comments on this. [...] > +/* VIDCON0 */ I don't think above comment is needed because everybody knows that from the name of VIDCON0_. > + > +#define VIDCON0 (0x00) > +#define VIDCON0_INTERLACE(1 << 29) > +#define VIDCON0_VIDOUT_MASK (0x3 << 26) > +#define VIDCON0_VIDOUT_SHIFT (26) I think, you can use either of the following. +#define VIDCON0_VIDOUT_SHIFT (26) +#define VIDCON0_VIDOUT_MASK(0x3 << VIDCON0_VIDOUT_SHIFT) Or just without XXX_SHIFT if the XXX_SHIFT is not used somewhere else, +#define VIDCON0_VIDOUT_MASK (0x3 << 26) [...] Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.
RE: [PATCH 1/3] Move FIMD register headers to include/video/
Marek Szyprowski wrote:
Hello,
Hi all,
[...]
static struct s3c_fb_driverdata s3c_fb_data_exynos5 = {
.variant = {
.nr_windows = 5,
- .vidtcon= VIDTCON0,
+ .vidtcon= FIMD_V8_VIDTCON0,
Yes, this method looks good imo. Maybe even having something like
vidtcon_base in
variant structure will be enough to cover all VIDTCON0-3 registers.
Yes, I agree. And how about changing the name of s3c_fb_drvierdata to
xxx_fimd_v8 not xxx_fimd_exynos5? It's time to use independent from SoC name
because we don't have any guarantee of same address on all of EXYNOS5 SoCs.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 1/3] Move FIMD register headers to include/video/
Leela Krishna Amudala wrote: Moved the contents of regs-fb-v4.h and regs-fb.h from arch side to include/video/samsung_fimd.h Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com --- arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 159 --- arch/arm/plat-samsung/include/plat/regs-fb.h| 403 - include/video/samsung_fimd.h| 533 +++ 3 files changed, 533 insertions(+), 562 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h create mode 100644 include/video/samsung_fimd.h + I have some comments on this. [...] +/* VIDCON0 */ I don't think above comment is needed because everybody knows that from the name of VIDCON0_. + +#define VIDCON0 (0x00) +#define VIDCON0_INTERLACE(1 29) +#define VIDCON0_VIDOUT_MASK (0x3 26) +#define VIDCON0_VIDOUT_SHIFT (26) I think, you can use either of the following. +#define VIDCON0_VIDOUT_SHIFT (26) +#define VIDCON0_VIDOUT_MASK(0x3 VIDCON0_VIDOUT_SHIFT) Or just without XXX_SHIFT if the XXX_SHIFT is not used somewhere else, +#define VIDCON0_VIDOUT_MASK(0x3 26) [...] Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 1/3] Move FIMD register headers to include/video/
Jingoo Han wrote: On Monday, July 30, 2012 8:16 PM, Leela Krishna Amudala wrote: Hello Jingoo Han, On Mon, Jul 30, 2012 at 2:23 PM, Jingoo Han jg1@samsung.com wrote: On Monday, July 30, 2012 5:45 PM, Leela Krishna Amudala wrote: Moved the contents of regs-fb-v4.h and regs-fb.h from arch side to include/video/samsung_fimd.h Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com --- arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 159 --- arch/arm/plat-samsung/include/plat/regs-fb.h| 403 --- -- include/video/samsung_fimd.h| 533 +++ 3 files changed, 533 insertions(+), 562 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h create mode 100644 include/video/samsung_fimd.h +*/ + +/*FIMD V8 REG OFFSET */ +#define FIMD_V8_VIDTCON0 (0x20010) +#define FIMD_V8_VIDTCON1 (0x20014) +#define FIMD_V8_VIDTCON2 (0x20018) +#define FIMD_V8_VIDTCON3 (0x2001C) +#define FIMD_V8_VIDCON1 (0x20004) How about using soc_is_exynos5250()? +#define VIDTCON0 (soc_is_exynos5250() ? \ + (0x20010) : (0x10)) In this case, the FIMD driver does not need to change. Also, one binary is available. I don't agree. Do you _really_ think the address will be fixed on other SoCs including upcoming SoCs? I'd prefer to use the version or something for it. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH V2 5/5] arm: samsung: delete frame buffer header files from platform
Leela Krishna Amudala wrote: The FIMD register headers are moved to include/video/ hence, deleting these files from platform side Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com --- arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 159 - arch/arm/plat-samsung/include/plat/regs-fb.h| 403 --- 2 files changed, 0 insertions(+), 562 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h No. This should be squashed into first patch on this series. See below. arch/arm/plat-samsung/include/plat/regs-fb-v4.h| 159 .../plat/regs-fb.h = include/video/samsung_fimd.h | 145 -- 2 files changed, 134 insertions(+), 170 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h rename arch/arm/plat-samsung/include/plat/regs-fb.h = include/video/samsung_fimd.h (74%) Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH V2 1/5] include/video: Add samsung FIMD register header
Leela Krishna Amudala wrote: This patch copies the contents from regs-fb-v4.h and regs-fb.h to include/video/samsung_fimd.h Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com --- include/video/samsung_fimd.h | 526 ++ 1 files changed, 526 insertions(+), 0 deletions(-) create mode 100644 include/video/samsung_fimd.h Firstly, please check my comment on your previous patches. And I don't see following definitions are needed and used now. If some definitions are not needed, they can be removed. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH V2 2/5] include/video: Add Exynos5 specific FIMD register offsets
Leela Krishna Amudala wrote: Exynos5 has VIDTCON and VIDCON registers at different offsets from the previous SOCs. Hence, adding the macros. Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com --- include/video/samsung_fimd.h |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h index e979f42..820f190 100644 --- a/include/video/samsung_fimd.h +++ b/include/video/samsung_fimd.h @@ -524,3 +524,10 @@ * 1110 -none- -none- -none- -none--none- * -none- -none- -none- -none--none- */ + +/*EXYNOS5 FIMD REG OFFSET */ +#define EXYNOS5_VIDTCON0 (0x20010) +#define EXYNOS5_VIDTCON1 (0x20014) +#define EXYNOS5_VIDTCON2 (0x20018) +#define EXYNOS5_VIDTCON3 (0x2001C) +#define EXYNOS5_VIDCON1 (0x20004) -- 1.7.0.4 All of EXYNOS5 SoCs including upcoming SoCs _really_ have same address like above? I don't think so. You need to consider its flexibility or some compatibility when definitions are added. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH V2 3/5] arm: samsung: Include the modified FIMD header file
Leela Krishna Amudala wrote: The fimd register headers have been moved to include/video/ hence, modifying the machine files accordingly. Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com --- arch/arm/mach-exynos/mach-nuri.c |2 +- arch/arm/mach-exynos/mach-origen.c |2 +- arch/arm/mach-exynos/mach-smdk4x12.c |2 +- arch/arm/mach-exynos/mach-smdkv310.c |2 +- arch/arm/mach-exynos/mach-universal_c210.c |2 +- arch/arm/mach-exynos/setup-fimd0.c |2 +- arch/arm/mach-s3c24xx/mach-smdk2416.c |2 +- arch/arm/mach-s3c64xx/mach-anw6410.c |2 +- arch/arm/mach-s3c64xx/mach-crag6410.c |2 +- arch/arm/mach-s3c64xx/mach-hmt.c |2 +- arch/arm/mach-s3c64xx/mach-mini6410.c |2 +- arch/arm/mach-s3c64xx/mach-ncp.c |2 +- arch/arm/mach-s3c64xx/mach-real6410.c |2 +- arch/arm/mach-s3c64xx/mach-smartq5.c |2 +- arch/arm/mach-s3c64xx/mach-smartq7.c |2 +- arch/arm/mach-s3c64xx/mach-smdk6410.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6440.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6450.c |2 +- arch/arm/mach-s5pc100/mach-smdkc100.c |2 +- arch/arm/mach-s5pv210/mach-aquila.c|2 +- arch/arm/mach-s5pv210/mach-goni.c |2 +- arch/arm/mach-s5pv210/mach-smdkv210.c |2 +- 22 files changed, 22 insertions(+), 22 deletions(-) diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach- nuri.c index f98a83a..573a0c4 100644 --- a/arch/arm/mach-exynos/mach-nuri.c +++ b/arch/arm/mach-exynos/mach-nuri.c @@ -39,7 +39,7 @@ #include asm/mach-types.h #include plat/adc.h -#include plat/regs-fb-v4.h +#include video/samsung_fimd.h #include plat/regs-serial.h #include plat/cpu.h #include plat/devs.h NO! Don't just replace it. Please put the inclusions with the same kind like following. diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach-nuri.c index ea785fc..90d8daa 100644 --- a/arch/arm/mach-exynos/mach-nuri.c +++ b/arch/arm/mach-exynos/mach-nuri.c @@ -29,6 +29,7 @@ #include drm/exynos_drm.h #include video/platform_lcd.h +#include video/samsung_fimd.h #include media/m5mols.h #include media/s5k6aa.h #include media/s5p_fimc.h @@ -39,7 +40,6 @@ #include asm/mach-types.h #include plat/adc.h -#include plat/regs-fb-v4.h #include plat/regs-serial.h #include plat/cpu.h #include plat/devs.h Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH V2 4/5] driver: Include the modified FIMD header file
Leela Krishna Amudala wrote: The fimd register headers have been moved to include/video/ hence, modifying the driver files accordingly. Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +- drivers/video/s3c-fb.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) [...] --- a/drivers/video/s3c-fb.c +++ b/drivers/video/s3c-fb.c @@ -26,7 +26,7 @@ #include linux/pm_runtime.h #include mach/map.h -#include plat/regs-fb-v4.h +#include video/samsung_fimd.h #include plat/fb.h See my previous comments. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH V2 0/5] arm: samsung: Move FIMD headers to include/video/
Leela Krishna Amudala wrote: This patchset moves the contents of regs-fb-v4.h and regs-fb.h from arch side to include/video/samsung_fimd.h This patchset is created and rebased against master branch of torvalds tree. Tested on smdk5250 board, build tested for other boards. (Cc'ed Florian Tobias Schandinat) Yeah, since it's merge window, this series could be created against on mainline. And IMO, would be helpful to us if this series could be sent to upstream via samsung tree after reviewing, because this touches too many files in samsung tree and just adds include/video/samsung_fimd.h. But I'm not sure the added inclusion will be used in other file of drivers/video. If so, I can provide some topic branch can be merged into Florian's tree. Florian, how about? Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. Changes from version 1: - Split the patches as per Sylwester comments - Changed FIMD_V8_xxx macro to EXYNOS5_xxx Leela Krishna Amudala (5): include/video: Add samsung FIMD register header include/video: Add Exynos5 specific FIMD register offsets arm: samsung: Include the modified FIMD header file driver: Include the modified FIMD header file arm: samsung: delete frame buffer header files from platform arch/arm/mach-exynos/mach-nuri.c |2 +- arch/arm/mach-exynos/mach-origen.c |2 +- arch/arm/mach-exynos/mach-smdk4x12.c |2 +- arch/arm/mach-exynos/mach-smdkv310.c |2 +- arch/arm/mach-exynos/mach-universal_c210.c |2 +- arch/arm/mach-exynos/setup-fimd0.c |2 +- arch/arm/mach-s3c24xx/mach-smdk2416.c |2 +- arch/arm/mach-s3c64xx/mach-anw6410.c |2 +- arch/arm/mach-s3c64xx/mach-crag6410.c |2 +- arch/arm/mach-s3c64xx/mach-hmt.c |2 +- arch/arm/mach-s3c64xx/mach-mini6410.c |2 +- arch/arm/mach-s3c64xx/mach-ncp.c |2 +- arch/arm/mach-s3c64xx/mach-real6410.c |2 +- arch/arm/mach-s3c64xx/mach-smartq5.c |2 +- arch/arm/mach-s3c64xx/mach-smartq7.c |2 +- arch/arm/mach-s3c64xx/mach-smdk6410.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6440.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6450.c |2 +- arch/arm/mach-s5pc100/mach-smdkc100.c |2 +- arch/arm/mach-s5pv210/mach-aquila.c|2 +- arch/arm/mach-s5pv210/mach-goni.c |2 +- arch/arm/mach-s5pv210/mach-smdkv210.c |2 +- arch/arm/plat-samsung/include/plat/regs-fb-v4.h| 159 drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +- drivers/video/s3c-fb.c |2 +- .../plat/regs-fb.h = include/video/samsung_fimd.h | 152 +-- 26 files changed, 165 insertions(+), 194 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h rename arch/arm/plat-samsung/include/plat/regs-fb.h = include/video/samsung_fimd.h (74%) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH V2 5/5] arm: samsung: delete frame buffer header files from platform
Leela Krishna Amudala wrote: Hello Kgene, On Wed, Aug 1, 2012 at 7:34 AM, Kukjin Kim kgene@samsung.com wrote: Leela Krishna Amudala wrote: The FIMD register headers are moved to include/video/ hence, deleting these files from platform side Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com --- arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 159 - arch/arm/plat-samsung/include/plat/regs-fb.h| 403 --- 2 files changed, 0 insertions(+), 562 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h No. This should be squashed into first patch on this series. See below. arch/arm/plat-samsung/include/plat/regs-fb-v4.h| 159 .../plat/regs-fb.h = include/video/samsung_fimd.h | 145 -- 2 files changed, 134 insertions(+), 170 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h rename arch/arm/plat-samsung/include/plat/regs-fb.h = include/video/samsung_fimd.h (74%) If I squash it with the first patch and if somebody set that as a head commit, it will break the build. Hence, splitted it up from the first patch. NACK. your changes are not adding just moving. So should be squashed. If required, you could create just one patch for moving them, probably, 1st, 3rd, 4th and 5th patches into one patch. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. Thank you Sylwester for suggesting this split up change. Regards, Leela Krishna ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH V2 0/5] arm: samsung: Move FIMD headers to include/video/
Florian Tobias Schandinat wrote: On 08/01/2012 02:28 AM, Kukjin Kim wrote: Leela Krishna Amudala wrote: This patchset moves the contents of regs-fb-v4.h and regs-fb.h from arch side to include/video/samsung_fimd.h This patchset is created and rebased against master branch of torvalds tree. Tested on smdk5250 board, build tested for other boards. (Cc'ed Florian Tobias Schandinat) Yeah, since it's merge window, this series could be created against on mainline. And IMO, would be helpful to us if this series could be sent to upstream via samsung tree after reviewing, because this touches too many files in samsung tree and just adds include/video/samsung_fimd.h. But I'm not sure the added inclusion will be used in other file of drivers/video. If so, I can provide some topic branch can be merged into Florian's tree. Florian, how about? Using a topic branch to merge it in both trees sounds like a good plan to me. Sure, if this change is ready, I will create topic branch then let you know. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH V2 5/5] arm: samsung: delete frame buffer header files from platform
Sylwester Nawrocki wrote: Hi, On 08/01/2012 11:39 AM, Kukjin Kim wrote: Leela Krishna Amudala wrote: On Wed, Aug 1, 2012 at 7:34 AM, Kukjin Kim kgene@samsung.com wrote: Leela Krishna Amudala wrote: The FIMD register headers are moved to include/video/ hence, deleting these files from platform side Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com --- arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 159 - arch/arm/plat-samsung/include/plat/regs-fb.h| 403 --- 2 files changed, 0 insertions(+), 562 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h No. This should be squashed into first patch on this series. See below. arch/arm/plat-samsung/include/plat/regs-fb-v4.h| 159 .../plat/regs-fb.h = include/video/samsung_fimd.h | 145 -- 2 files changed, 134 insertions(+), 170 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h rename arch/arm/plat-samsung/include/plat/regs-fb.h = include/video/samsung_fimd.h (74%) If I squash it with the first patch and if somebody set that as a head commit, it will break the build. Hence, splitted it up from the first patch. NACK. your changes are not adding just moving. So should be squashed. If required, you could create just one patch for moving them, probably, 1st, 3rd, 4th and 5th patches into one patch. Yes, this patch series is mainly moving files around. But to avoid git bisect breakage, it should be split as it is done now, or the whole series should be squashed into one patch. The latter might be even easier to handle, but having a single patch touching arch/arm/ and drivers/ might not be a good idea. If you're fine handling that, then we just need to squash this series into single patch. It just need to be ensured, IMO, there is no bisection breakage. I know you meant. But we don't need to keep the changes 'adding and removing' for just moving on this. I commented on 0/5 patch in this series before, if this is ready, I will create topic branch so that it could be merged into both mine and Florian's. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
