[PATCH 0/1] drm/vc4: drv: Add error handding for bind

2020-10-26 Thread Hoegeun Kwon
Hello all,

There is a problem that if vc4_drm bind fails, a memory leak occurs on
the drm_property_create side as shown below. Add error handding for
drm_mode_config.

unreferenced object 0xff80f5a7a6c8 (size 576):
  comm "swapper/0", pid 1, jiffies 4294892559 (age 181.448s)
  hex dump (first 32 bytes):
00 00 1e 00 00 00 00 00 00 00 00 00 00 00 00 00  
f8 f1 0e f5 80 ff ff ff e0 a6 a7 f5 80 ff ff ff  
  backtrace:
[<fd3656dc>] kmem_cache_alloc+0x1a4/0x328
[<9dfa1aab>] radix_tree_node_alloc.constprop.19+0x50/0x108
[<a9f1657b>] idr_get_free+0x21c/0x2b8
[<99f2eea6>] idr_alloc_u32+0x68/0xf0
[<525beb52>] idr_alloc+0x44/0x80
[<dbfbaa4b>] __drm_mode_object_add+0x64/0xc0
[<2c24dfc8>] drm_mode_object_add+0x3c/0x50
[<f45b491f>] drm_property_create+0xf0/0x1a0
[<2e1a296b>] drm_connector_create_standard_properties+0x30/0x130
[<7c53e4bd>] drm_mode_config_init+0x138/0x498
[<cc1b0767>] vc4_drm_bind+0x168/0x1f8
[<41d69f98>] try_to_bring_up_master+0x180/0x1e8
[<d1e1caae>] component_master_add_with_match+0xbc/0x108
[<85cea46d>] vc4_platform_drm_probe+0xd8/0x108
[<eacabf20>] platform_drv_probe+0x58/0xa8
[<3822d094>] really_probe+0x10c/0x350

Best regards,
Hoegeun

Hoegeun Kwon (1):
  drm/vc4: drv: Add error handding for bind

 drivers/gpu/drm/vc4/vc4_drv.c | 1 +
 1 file changed, 1 insertion(+)

-- 
2.17.1



[PATCH 1/1] drm/vc4: drv: Add error handding for bind

2020-10-26 Thread Hoegeun Kwon
There is a problem that if vc4_drm bind fails, a memory leak occurs on
the drm_property_create side. Add error handding for drm_mode_config.

Signed-off-by: Hoegeun Kwon 
---
 drivers/gpu/drm/vc4/vc4_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index f1a5fd5dab6f..a17aa1db11b6 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -314,6 +314,7 @@ static int vc4_drm_bind(struct device *dev)
component_unbind_all(dev, drm);
 gem_destroy:
vc4_gem_destroy(drm);
+   drm_mode_config_cleanup(drm);
vc4_bo_cache_destroy(drm);
 dev_put:
drm_dev_put(drm);
-- 
2.17.1



Re: [PATCH v5 00/80] drm/vc4: Support BCM2711 Display Pipeline

2020-09-14 Thread Hoegeun Kwon
Hi Maxime,

On 9/8/20 9:00 PM, Maxime Ripard wrote:
> Hi Hoegeun,
>
> On Mon, Sep 07, 2020 at 08:49:12PM +0900, Hoegeun Kwon wrote:
>> On 9/3/20 5:00 PM, Maxime Ripard wrote:
>>> Hi everyone,
>>>
>>> Here's a (pretty long) series to introduce support in the VC4 DRM driver
>>> for the display pipeline found in the BCM2711 (and thus the RaspberryPi 4).
>>>
>>> The main differences are that there's two HDMI controllers and that there's
>>> more pixelvalve now. Those pixelvalve come with a mux in the HVS that still
>>> have only 3 FIFOs. Both of those differences are breaking a bunch of
>>> expectations in the driver, so we first need a good bunch of cleanup and
>>> reworks to introduce support for the new controllers.
>>>
>>> Similarly, the HDMI controller has all its registers shuffled and split in
>>> multiple controllers now, so we need a bunch of changes to support this as
>>> well.
>>>
>>> Only the HDMI support is enabled for now (even though the DPI and DSI
>>> outputs have been tested too).
>>>
>>> Let me know if you have any comments
>>> Maxime
>>>
>>> Cc: bcm-kernel-feedback-l...@broadcom.com
>>> Cc: devicet...@vger.kernel.org
>>> Cc: Kamal Dasu 
>>> Cc: Philipp Zabel 
>>> Cc: Rob Herring 
>>> Cc: Stephen Boyd 
>>>
>>> Changes from v4:
>>> - Rebased on top of next-20200828
>>> - Collected the various tags
>>> - Fixed some issues with 4k support and dual output (thanks Hoegeun!)
>> Thanks for your v5 patchset.
>>
>> I tested all patches based on the next-20200812.
> Thanks again for testing all the patches
>
>> Everything else is fine, but the dual hdmi modetest doesn't work well in my
>> environment...
>>
>> In my environment, dsi is not connected, I have seen your answer[1].
> Can you share a bit more your setup? What monitors are being connected
> to each HDMI port? Do you hotplug any?
Yes, Monitors are being connected to each HDMI ports. (did not use hotplug)

When booting, both HDMI-0 and 1 are recognized and the kernel log is output.
But after run modetest on HDMI-0(works) and modetest on HDMI-1(works),
crtc timed out occurs on HDMI-0 and does not work.

When HDMI-0 is not working we do a modetest on HDMI-0, it will work agin
after about 40 sec.

Below is the log for modetest.


root:~> modetest -Mvc4 -s 32:1280x720         - HDMI-0 works
setting mode 1280x720-60Hz@XR24 on connectors 32, crtc 64
failed to set gamma: Invalid argument

root:~> modetest -Mvc4 -s 32:1280x720         - HDMI-0 works
setting mode 1280x720-60Hz@XR24 on connectors 32, crtc 64
failed to set gamma: Invalid argument

root:~> modetest -Mvc4 -s 38:1280x720         - HDMI-1 works
setting mode 1280x720-60Hz@XR24 on connectors 38, crtc 69
failed to set gamma: Invalid argument

                               - Crtc timed out occurs on HDMI-0 and 
does not work.

[   71.134283] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* 
[CRTC:64:crtc-3] flip_done timed out
[   81.374296] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
[CRTC:64:crtc-3] flip_done timed out
[   91.618380] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
[CONNECTOR:32:HDMI-A-1] flip_done timed out
[  101.854274] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
[PLANE:60:plane-3] flip_done timed out

[  112.094271] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* 
[CRTC:64:crtc-3] flip_done timed out
[  122.590311] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
[CRTC:64:crtc-3] flip_done timed out

root:~> modetest -Mvc4 -s 32:1280x720
[  132.830309] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
[CONNECTOR:32:HDMI-A-1] flip_done timed out
[  143.070307] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
[PLANE:60:plane-3] flip_done timed out
[  153.310303] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* 
[CRTC:64:crtc-3] flip_done timed out
setting mode 1280x720-60Hz@XR24 on connectors 32, crtc 64
[  163.550340] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
[CRTC:64:crtc-3] flip_done timed out
[  173.790277] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
[CONNECTOR:32:HDMI-A-1] flip_done timed out
[  184.030286] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
[PLANE:60:plane-3] flip_done timed out
failed to set gamma: Invalid argument         - HDMI-0 works


Best regards,
Hoegeun




Re: [PATCH v5 80/80] ARM: dts: bcm2711: Enable the display pipeline

2020-09-07 Thread Hoegeun Kwon
Hi Maxime,

On 9/3/20 5:01 PM, Maxime Ripard wrote:
> Now that all the drivers have been adjusted for it, let's bring in the
> necessary device tree changes.
>
> The VEC and PV3 are left out for now, since it will require a more specific
> clock setup.
>
> Reviewed-by: Dave Stevenson 
> Tested-by: Chanwoo Choi 
> Tested-by: Hoegeun Kwon 
> Tested-by: Stefan Wahren 
> Signed-off-by: Maxime Ripard 

Thanks for your v5 patch


Reviewed-by: Hoegeun Kwon 


Best regards,

Hoegeun

> ---
>   arch/arm/boot/dts/bcm2711-rpi-4-b.dts |  48 +++-
>   arch/arm/boot/dts/bcm2711.dtsi| 122 ++-
>   2 files changed, 169 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts 
> b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> index e94244a215af..09a1182c2936 100644
> --- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> +++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> @@ -70,6 +70,14 @@
>   };
>   };
>   
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
>{
>   firmware_clocks: clocks {
>   compatible = "raspberrypi,firmware-clocks";
> @@ -170,6 +178,38 @@
> "RGMII_TXD3";
>   };
>   
> + {
> + clocks = <_clocks 13>, <_clocks 14>, < 0>, 
> <_27MHz>;
> + clock-names = "hdmi", "bvb", "audio", "cec";
> + status = "okay";
> +};
> +
> + {
> + clocks = <_clocks 13>, <_clocks 14>, < 1>, 
> <_27MHz>;
> + clock-names = "hdmi", "bvb", "audio", "cec";
> + status = "okay";
> +};
> +
> + {
> + clocks = <_clocks 4>;
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
>{
>   pinctrl-names = "default";
>   pinctrl-0 = <_0_gpio40 _1_gpio41>;
> @@ -253,3 +293,11 @@
>{
>   interrupts = ;
>   };
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "disabled";
> +};
> diff --git a/arch/arm/boot/dts/bcm2711.dtsi b/arch/arm/boot/dts/bcm2711.dtsi
> index 00bcaed1be32..4847dd305317 100644
> --- a/arch/arm/boot/dts/bcm2711.dtsi
> +++ b/arch/arm/boot/dts/bcm2711.dtsi
> @@ -12,6 +12,18 @@
>   
>   interrupt-parent = <>;
>   
> + vc4: gpu {
> + compatible = "brcm,bcm2711-vc5";
> + status = "disabled";
> + };
> +
> + clk_27MHz: clk-27M {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <2700>;
> + clock-output-names = "27MHz-clock";
> + };
> +
>   clk_108MHz: clk-108M {
>   #clock-cells = <0>;
>   compatible = "fixed-clock";
> @@ -238,6 +250,27 @@
>   status = "disabled";
>   };
>   
> + pixelvalve0: pixelvalve@7e206000 {
> + compatible = "brcm,bcm2711-pixelvalve0";
> + reg = <0x7e206000 0x100>;
> + interrupts = ;
> + status = "disabled";
> + };
> +
> + pixelvalve1: pixelvalve@7e207000 {
> + compatible = "brcm,bcm2711-pixelvalve1";
> + reg = <0x7e207000 0x100>;
> + interrupts = ;
> + status = "disabled";
> + };
> +
> + pixelvalve2: pixelvalve@7e20a000 {
> + compatible = "brcm,bcm2711-pixelvalve2";
> + reg = <0x7e20a000 0x100>;
> + interrupts = ;
> + status = "disabled";
> + };
> +
>   pwm1: pwm@7e20c800 {
>   compatible = "brcm,bcm2835-pwm";
>   reg = <0x7e20c800 0x28>;
> @@ -248,10 +281,25 @@
>   status = "disabled";
>   };
>   
> - hvs@7e40 {
> + pixelvalve4: pixelvalve@7e216000 {
> + compatible = "brcm,bcm2711-pixelvalve4";
> + reg = <0x7e216000 0x100>;
> + interrupts = ;

Re: [PATCH v5 77/80] dt-bindings: display: vc4: hdmi: Add BCM2711 HDMI controllers bindings

2020-09-07 Thread Hoegeun Kwon
Hi Maxime,

On 9/3/20 5:01 PM, Maxime Ripard wrote:
> The HDMI controllers found in the BCM2711 SoC need some adjustments to the
> bindings, especially since the registers have been shuffled around in more
> register ranges.
>
> Reviewed-by: Rob Herring 
> Tested-by: Chanwoo Choi 
> Tested-by: Hoegeun Kwon 
> Tested-by: Stefan Wahren 
> Signed-off-by: Maxime Ripard 

Thanks for your v5 patch


Reviewed-by: Hoegeun Kwon 


Best regards,

Hoegeun

> ---
>   Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml | 117 
> -
>   1 file changed, 117 insertions(+)
>   create mode 100644 
> Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml 
> b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> new file mode 100644
> index ..03a76729d26c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> @@ -0,0 +1,117 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: 
> https://protect2.fireeye.com/v1/url?k=0b6f5f6c-56a4d852-0b6ed423-0cc47a31309a-d9c680091736128f=1=24b01bb3-08a1-4c21-9bf9-e1d1e9ffdc3e=http%3A%2F%2Fdevicetree.org%2Fschemas%2Fdisplay%2Fbrcm%2Cbcm2711-hdmi.yaml%23
> +$schema: 
> https://protect2.fireeye.com/v1/url?k=a854ae90-f59f29ae-a85525df-0cc47a31309a-1160616098892a41=1=24b01bb3-08a1-4c21-9bf9-e1d1e9ffdc3e=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23
> +
> +title: Broadcom BCM2711 HDMI Controller Device Tree Bindings
> +
> +maintainers:
> +  - Eric Anholt 
> +
> +properties:
> +  compatible:
> +enum:
> +  - brcm,bcm2711-hdmi0
> +  - brcm,bcm2711-hdmi1
> +
> +  reg:
> +items:
> +  - description: HDMI controller register range
> +  - description: DVP register range
> +  - description: HDMI PHY register range
> +  - description: Rate Manager register range
> +  - description: Packet RAM register range
> +  - description: Metadata RAM register range
> +  - description: CSC register range
> +  - description: CEC register range
> +  - description: HD register range
> +
> +  reg-names:
> +items:
> +  - const: hdmi
> +  - const: dvp
> +  - const: phy
> +  - const: rm
> +  - const: packet
> +  - const: metadata
> +  - const: csc
> +  - const: cec
> +  - const: hd
> +
> +  clocks:
> +items:
> +  - description: The HDMI state machine clock
> +  - description: The Pixel BVB clock
> +  - description: The HDMI Audio parent clock
> +  - description: The HDMI CEC parent clock
> +
> +  clock-names:
> +items:
> +  - const: hdmi
> +  - const: bvb
> +  - const: audio
> +  - const: cec
> +
> +  ddc:
> +allOf:
> +  - $ref: /schemas/types.yaml#/definitions/phandle
> +description: >
> +  Phandle of the I2C controller used for DDC EDID probing
> +
> +  hpd-gpios:
> +description: >
> +  The GPIO pin for the HDMI hotplug detect (if it doesn't appear
> +  as an interrupt/status bit in the HDMI controller itself)
> +
> +  dmas:
> +maxItems: 1
> +description: >
> +  Should contain one entry pointing to the DMA channel used to
> +  transfer audio data.
> +
> +  dma-names:
> +const: audio-rx
> +
> +  resets:
> +maxItems: 1
> +
> +required:
> +  - compatible
> +  - reg
> +  - reg-names
> +  - clocks
> +  - resets
> +  - ddc
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +hdmi0: hdmi@7ef00700 {
> +compatible = "brcm,bcm2711-hdmi0";
> +reg = <0x7ef00700 0x300>,
> +  <0x7ef00300 0x200>,
> +  <0x7ef00f00 0x80>,
> +  <0x7ef00f80 0x80>,
> +  <0x7ef01b00 0x200>,
> +  <0x7ef01f00 0x400>,
> +  <0x7ef00200 0x80>,
> +  <0x7ef04300 0x100>,
> +  <0x7ef2 0x100>;
> +reg-names = "hdmi",
> +"dvp",
> +"phy",
> +"rm",
> +"packet",
> +"metadata",
> +"csc",
> +"cec",
> +"hd";
> +clocks = <_clocks 13>, <_clocks 14>, < 1>, 
> <_27MHz>;
> +clock-names = "hdmi", "bvb", "audio", "cec";
> +resets = < 0>;
> +ddc = <>;
> +};
> +
> +...


Re: [PATCH v5 00/80] drm/vc4: Support BCM2711 Display Pipeline

2020-09-07 Thread Hoegeun Kwon
Hi Maxime,

On 9/3/20 5:00 PM, Maxime Ripard wrote:
> Hi everyone,
>
> Here's a (pretty long) series to introduce support in the VC4 DRM driver
> for the display pipeline found in the BCM2711 (and thus the RaspberryPi 4).
>
> The main differences are that there's two HDMI controllers and that there's
> more pixelvalve now. Those pixelvalve come with a mux in the HVS that still
> have only 3 FIFOs. Both of those differences are breaking a bunch of
> expectations in the driver, so we first need a good bunch of cleanup and
> reworks to introduce support for the new controllers.
>
> Similarly, the HDMI controller has all its registers shuffled and split in
> multiple controllers now, so we need a bunch of changes to support this as
> well.
>
> Only the HDMI support is enabled for now (even though the DPI and DSI
> outputs have been tested too).
>
> Let me know if you have any comments
> Maxime
>
> Cc: bcm-kernel-feedback-l...@broadcom.com
> Cc: devicet...@vger.kernel.org
> Cc: Kamal Dasu 
> Cc: Philipp Zabel 
> Cc: Rob Herring 
> Cc: Stephen Boyd 
>
> Changes from v4:
>- Rebased on top of next-20200828
>- Collected the various tags
>- Fixed some issues with 4k support and dual output (thanks Hoegeun!)

Thanks for your v5 patchset.

I tested all patches based on the next-20200812.

Everything else is fine, but the dual hdmi modetest doesn't work well in my
environment...

In my environment, dsi is not connected, I have seen your answer[1].

Do you have any other settings? For example in config.txt.


[1] https://lkml.org/lkml/2020/9/2/566

>- Fixed typos in commit logs (thanks Dave!)
>- Split the csc setup hook into its own patch again
>- Added the CEC clock to the DT binding
>- Fixed the DT binding example
>- Reduced the number of calls to of_device_is_compatible in vc4_kms_load
>- Added back the check for the state commit in our commit hook

Best regards,

Hoegeun



Re: [PATCH v2 2/4] drm/vc4: hdmi: Add pixel bvb clock control

2020-09-01 Thread Hoegeun Kwon
Hi Chanwoo,

On 9/1/20 1:27 PM, Chanwoo Choi wrote:
> Hi Hoegeun,
>
> It looks good to me. But, just one comment.
>
> On 9/1/20 1:07 PM, Hoegeun Kwon wrote:
>> There is a problem that the output does not work at a resolution
>> exceeding FHD. To solve this, we need to adjust the bvb clock at a
>> resolution exceeding FHD.
>>
>> Signed-off-by: Hoegeun Kwon 
>> ---
>>   drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
>>   drivers/gpu/drm/vc4/vc4_hdmi.h |  1 +
>>   2 files changed, 26 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
>> index 95ec5eedea39..eb3192d1fd86 100644
>> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
>> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
>> @@ -80,6 +80,7 @@
>>   # define VC4_HD_M_ENABLE   BIT(0)
>>   
>>   #define CEC_CLOCK_FREQ 4
>> +#define VC4_HSM_MID_CLOCK 149985000
>>   
>>   static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
>>   {
>> @@ -380,6 +381,7 @@ static void vc4_hdmi_encoder_post_crtc_powerdown(struct 
>> drm_encoder *encoder)
>>  HDMI_WRITE(HDMI_VID_CTL,
>> HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
>>   
>> +clk_disable_unprepare(vc4_hdmi->pixel_bvb_clock);
>>  clk_disable_unprepare(vc4_hdmi->hsm_clock);
>>  clk_disable_unprepare(vc4_hdmi->pixel_clock);
>>   
>> @@ -638,6 +640,23 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct 
>> drm_encoder *encoder)
>>  return;
>>  }
>>   
>> +ret = clk_set_rate(vc4_hdmi->pixel_bvb_clock,
>> +(hsm_rate > VC4_HSM_MID_CLOCK ? 15000 : 7500));
>> +if (ret) {
>> +DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
>> +clk_disable_unprepare(vc4_hdmi->hsm_clock);
>> +clk_disable_unprepare(vc4_hdmi->pixel_clock);
>> +return;
>> +}
>> +
>> +ret = clk_prepare_enable(vc4_hdmi->pixel_bvb_clock);
>> +if (ret) {
>> +DRM_ERROR("Failed to turn on pixel bvb clock: %d\n", ret);
>> +clk_disable_unprepare(vc4_hdmi->hsm_clock);
>> +clk_disable_unprepare(vc4_hdmi->pixel_clock);
>> +return;
>> +}
> Generally, enable the clock before using clk and then change the clock rate.
> I think that you better to change the order between clk_prepare_enable and 
> clk_set_rate.

Thank you for your comment.


As Maxime answered in another patch [1], there is no clear rule of order 
here.

[1] https://lkml.org/lkml/2020/9/1/327


Best regards,

Hoegeun




[PATCH v2 0/4] drm/vc4: Support HDMI QHD or higher output

2020-08-31 Thread Hoegeun Kwon
Hi everyone,

There is a problem that the output does not work at a resolution
exceeding FHD. To solve this, we need to adjust the bvb clock at a
resolution exceeding FHD.

Rebased on top of next-20200708 and [1].

[1] : [PATCH v4 00/78] drm/vc4: Support BCM2711 Display Pipeline (Maxime's 
patchset)

Changes from v1:
  - Added dt-bindings documents
  - Change patch order, first fix driver and then device tree

Hoegeun Kwon (4):
  clk: bcm: rpi: Add register to control pixel bvb clk
  drm/vc4: hdmi: Add pixel bvb clock control
  dt-bindings: display: vc4: hdmi: Add bvb clock-names property
  ARM: dts: bcm2711: Add bvb clock for hdmi-pixel

 .../bindings/display/brcm,bcm2711-hdmi.yaml   | 12 ++---
 arch/arm/boot/dts/bcm2711-rpi-4-b.dts |  6 +++--
 drivers/clk/bcm/clk-raspberrypi.c |  1 +
 drivers/gpu/drm/vc4/vc4_hdmi.c| 25 +++
 drivers/gpu/drm/vc4/vc4_hdmi.h|  1 +
 5 files changed, 39 insertions(+), 6 deletions(-)

-- 
2.17.1



[PATCH v2 2/4] drm/vc4: hdmi: Add pixel bvb clock control

2020-08-31 Thread Hoegeun Kwon
There is a problem that the output does not work at a resolution
exceeding FHD. To solve this, we need to adjust the bvb clock at a
resolution exceeding FHD.

Signed-off-by: Hoegeun Kwon 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
 drivers/gpu/drm/vc4/vc4_hdmi.h |  1 +
 2 files changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 95ec5eedea39..eb3192d1fd86 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -80,6 +80,7 @@
 # define VC4_HD_M_ENABLE   BIT(0)
 
 #define CEC_CLOCK_FREQ 4
+#define VC4_HSM_MID_CLOCK 149985000
 
 static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
 {
@@ -380,6 +381,7 @@ static void vc4_hdmi_encoder_post_crtc_powerdown(struct 
drm_encoder *encoder)
HDMI_WRITE(HDMI_VID_CTL,
   HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
 
+   clk_disable_unprepare(vc4_hdmi->pixel_bvb_clock);
clk_disable_unprepare(vc4_hdmi->hsm_clock);
clk_disable_unprepare(vc4_hdmi->pixel_clock);
 
@@ -638,6 +640,23 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct 
drm_encoder *encoder)
return;
}
 
+   ret = clk_set_rate(vc4_hdmi->pixel_bvb_clock,
+   (hsm_rate > VC4_HSM_MID_CLOCK ? 15000 : 7500));
+   if (ret) {
+   DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
+   clk_disable_unprepare(vc4_hdmi->hsm_clock);
+   clk_disable_unprepare(vc4_hdmi->pixel_clock);
+   return;
+   }
+
+   ret = clk_prepare_enable(vc4_hdmi->pixel_bvb_clock);
+   if (ret) {
+   DRM_ERROR("Failed to turn on pixel bvb clock: %d\n", ret);
+   clk_disable_unprepare(vc4_hdmi->hsm_clock);
+   clk_disable_unprepare(vc4_hdmi->pixel_clock);
+   return;
+   }
+
if (vc4_hdmi->variant->reset)
vc4_hdmi->variant->reset(vc4_hdmi);
 
@@ -1593,6 +1612,12 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi 
*vc4_hdmi)
return PTR_ERR(vc4_hdmi->audio_clock);
}
 
+   vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
+   if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
+   DRM_ERROR("Failed to get pixel bvb clock\n");
+   return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
+   }
+
vc4_hdmi->reset = devm_reset_control_get(dev, NULL);
if (IS_ERR(vc4_hdmi->reset)) {
DRM_ERROR("Failed to get HDMI reset line\n");
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 0806c6d9f24e..63c6f8bddf1d 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -147,6 +147,7 @@ struct vc4_hdmi {
struct clk *pixel_clock;
struct clk *hsm_clock;
struct clk *audio_clock;
+   struct clk *pixel_bvb_clock;
 
struct reset_control *reset;
 
-- 
2.17.1



[PATCH v2 4/4] ARM: dts: bcm2711: Add bvb clock for hdmi-pixel

2020-08-31 Thread Hoegeun Kwon
It is necessary to control the hdmi pixel bvb clock. Add bvb clock.

Signed-off-by: Hoegeun Kwon 
---
 arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts 
b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
index b93eb30e1ddb..90dee4cb38bc 100644
--- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
@@ -172,12 +172,14 @@
 };
 
  {
-   clocks = <_clocks 13>, < 0>;
+   clocks = <_clocks 13>, < 0>, <_clocks 14>;
+   clock-names = "hdmi", "clk-108M", "bvb";
status = "okay";
 };
 
  {
-   clocks = <_clocks 13>, < 1>;
+   clocks = <_clocks 13>, < 1>, <_clocks 14>;
+   clock-names = "hdmi", "clk-108M", "bvb";
status = "okay";
 };
 
-- 
2.17.1



[PATCH v2 3/4] dt-bindings: display: vc4: hdmi: Add bvb clock-names property

2020-08-31 Thread Hoegeun Kwon
When using a resolution exceeding FHD, bvb clock is required.
Add bvb clock-names property.

Signed-off-by: Hoegeun Kwon 
---
 .../bindings/display/brcm,bcm2711-hdmi.yaml  | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml 
b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
index 6091fe3d315b..08cdcc579cf5 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
@@ -40,10 +40,14 @@ properties:
   - const: hd
 
   clocks:
-description: The HDMI state machine clock
+items:
+  - description: The HDMI state machine clock
+  - description: The bvb clock
 
   clock-names:
-const: hdmi
+items:
+  - const: hdmi
+  - const: bvb
 
   ddc:
 allOf:
@@ -100,8 +104,8 @@ examples:
 "csc",
 "cec",
 "hd";
-clocks = <_clocks 13>;
-clock-names = "hdmi";
+clocks = <_clocks 13>, <_clocks 14>;
+clock-names = "hdmi", "bvb";
 resets = < 0>;
 ddc = <>;
 };
-- 
2.17.1



[PATCH v2 1/4] clk: bcm: rpi: Add register to control pixel bvb clk

2020-08-31 Thread Hoegeun Kwon
To use QHD or higher, we need to modify the pixel_bvb_clk value. So
add register to control this clock.

Signed-off-by: Hoegeun Kwon 
---
 drivers/clk/bcm/clk-raspberrypi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/bcm/clk-raspberrypi.c 
b/drivers/clk/bcm/clk-raspberrypi.c
index 5cc82954e1ce..f89b9cfc4309 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -271,6 +271,7 @@ static int raspberrypi_discover_clocks(struct 
raspberrypi_clk *rpi,
case RPI_FIRMWARE_CORE_CLK_ID:
case RPI_FIRMWARE_M2MC_CLK_ID:
case RPI_FIRMWARE_V3D_CLK_ID:
+   case RPI_FIRMWARE_PIXEL_BVB_CLK_ID:
hw = raspberrypi_clk_register(rpi, clks->parent,
  clks->id);
if (IS_ERR(hw))
-- 
2.17.1



Re: [PATCH 3/3] drm/vc4: hdmi: Add pixel bvb clock control

2020-08-31 Thread Hoegeun Kwon
Thank you reviews by Dave, Maxime and Stefan.

On 8/29/20 12:37 AM, Dave Stevenson wrote:
> Hi Maxime, Stefan, and Hoegeun
>
> On Fri, 28 Aug 2020 at 16:25, Maxime Ripard  wrote:
>> Hi,
>>
>> On Fri, Aug 28, 2020 at 02:45:49PM +0200, Stefan Wahren wrote:
>>> Am 28.08.20 um 08:30 schrieb Hoegeun Kwon:
>>>> On 8/27/20 6:49 PM, Stefan Wahren wrote:
>>>>> Am 27.08.20 um 06:35 schrieb Hoegeun Kwon:
>>>>>> Hi Stefan,
>>>>>>
>>>>>> Thank you for your review.
>>>>>>
>>>>>>
>>>>>> On 8/26/20 7:04 PM, Stefan Wahren wrote:
>>>>>>> Hi Hoeguen,
>>>>>>>
>>>>>>> Am 21.08.20 um 09:10 schrieb Hoegeun Kwon:
>>>>>>>> There is a problem that the output does not work at a resolution
>>>>>>>> exceeding FHD. To solve this, we need to adjust the bvb clock at a
>>>>>>>> resolution exceeding FHD.
>>>>>>> this patch introduces a mandatory clock, please update
>>>>>>> brcm,bcm2835-hdmi.yaml first.
>>>>>>>
>>>>>>> Is this clock physically available on BCM283x or only on BCM2711?
>>>>>> As far as I know, BCM2711 raspberry pi 4 supports 4k,
>>>>>>
>>>>>> don't supported on pi 3 and pi 3+.
>>>>>>
>>>>>> Since 4k is not supported in versions prior to Raspberry Pi 4,
>>>>>>
>>>>>> I don't think we need to modify the bvb clock.
>>>>>>
>>>>>>
>>>>>> So I think it is better to update 'brcm,bcm2711-hdmi.yaml'
>>>>>>
>>>>>> instead of 'brcm,bcm2835-hdmi.yaml'.
>>>>> You are correct please update only brcm,bcm2711-hdmi.yaml.
>>>>>
>>>>> My concern was that the function vc4_hdmi_encoder_pre_crtc_configure()
>>>>> is called on a non-bcm2711 platform or on a Raspberry Pi 4 with an older
>>>>> DTB. So making the BVB clock optional might be better?
>>>> You are right, if use old dtb, we have a problem with the hdmi driver.
>>>>
>>>> So how about modifying it like this?
>>>>
>>>> @@ -1614,8 +1614,8 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi
>>>> *vc4_hdmi)
>>>>
>>>>   vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
>>>>   if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
>>>> -   DRM_ERROR("Failed to get pixel bvb clock\n");
>>>> -   return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
>>>> +   DRM_WARN("Failed to get pixel bvb clock\n");
>>>> +   vc4_hdmi->pixel_bvb_clock = NULL;
>>>>   }
>>> i think the better solution would be devm_clk_get_optional(), which
>>> return NULL in case the clock doesn't exist.
>> It's not really optional though. BCM2711 will require it in order to run
>> properly (as Hoegeun experienced), and the previous SoCs won't.
>>
>> If we use clk_get_optional and that the DT is missing the clock on the
>> BCM2711, we will silently ignore it which doesn't sound great.
> Am I missing something here? (I know I missed this earlier)
> We're in vc5_hdmi_init_resources, which is inherently bcm2711 only.
> bcm283x will go through vc4_hdmi_init_resources.
>
> As long as vc4_hdmi_init_resources has left vc4_hdmi->pixel_bvb_clock
> at NULL, then the clock framework will be happy to do a nop.
>
> For BCM2711 an old DT would have issues, but, as Maxime has stated, no
> binding or upstream DTB has been merged yet, so it can be made
> mandatory.

If so, it seems good to set bvb_clock to mandatory without taking into

account the BCM2711 an old DTB as it hasn't been merged yet.

I will send version 2 patches.

> Making it optional drops you back on whatever the firmware might have
> set it to, which may be sufficient for some resolutions but not
> others.

As a result of checking by adding bvb_clock when I operated it with

the firmware, it was confirmed that the firmware increased the bvb_clock

from 7500 to 15000 when the FHD was exceeded.


Best regards

Hoegeun

>
>Dave
>


Re: [PATCH 3/3] drm/vc4: hdmi: Add pixel bvb clock control

2020-08-28 Thread Hoegeun Kwon
On 8/27/20 6:49 PM, Stefan Wahren wrote:
> Am 27.08.20 um 06:35 schrieb Hoegeun Kwon:
>> Hi Stefan,
>>
>> Thank you for your review.
>>
>>
>> On 8/26/20 7:04 PM, Stefan Wahren wrote:
>>> Hi Hoeguen,
>>>
>>> Am 21.08.20 um 09:10 schrieb Hoegeun Kwon:
>>>> There is a problem that the output does not work at a resolution
>>>> exceeding FHD. To solve this, we need to adjust the bvb clock at a
>>>> resolution exceeding FHD.
>>> this patch introduces a mandatory clock, please update
>>> brcm,bcm2835-hdmi.yaml first.
>>>
>>> Is this clock physically available on BCM283x or only on BCM2711?
>> As far as I know, BCM2711 raspberry pi 4 supports 4k,
>>
>> don't supported on pi 3 and pi 3+.
>>
>> Since 4k is not supported in versions prior to Raspberry Pi 4,
>>
>> I don't think we need to modify the bvb clock.
>>
>>
>> So I think it is better to update 'brcm,bcm2711-hdmi.yaml'
>>
>> instead of 'brcm,bcm2835-hdmi.yaml'.
> You are correct please update only brcm,bcm2711-hdmi.yaml.
>
> My concern was that the function vc4_hdmi_encoder_pre_crtc_configure()
> is called on a non-bcm2711 platform or on a Raspberry Pi 4 with an older
> DTB. So making the BVB clock optional might be better?

You are right, if use old dtb, we have a problem with the hdmi driver.

So how about modifying it like this?

@@ -1614,8 +1614,8 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi 
*vc4_hdmi)

     vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
     if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
-   DRM_ERROR("Failed to get pixel bvb clock\n");
-   return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
+   DRM_WARN("Failed to get pixel bvb clock\n");
+   vc4_hdmi->pixel_bvb_clock = NULL;
     }

     vc4_hdmi->reset = devm_reset_control_get(dev, NULL);

If we modify like this, if there is no bvb clock in dtb, then 
pixel_bvb_clock will be null

and it will not affect the clk control function below.

   - clk_set_rate()
   - clk_prepare_enable()
   - clk_disable_unprepare()


Best regards

Hoegeun

>
>> Please comment, what do you think?
>>
>>> I'm a little bit afraid, this change could break with older firmware
>>> versions on BCM283x.
>> Tested it several times with libdrm modetest.
>>
>> I expect there will be no problem.
>>
>>
>> Best regards,
>>
>> Hoegeun
>>
>>> Best regards
>>> Stefan
>>>
>>>> Signed-off-by: Hoegeun Kwon 
>>>> ---
>>>>drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
>>>>drivers/gpu/drm/vc4/vc4_hdmi.h |  1 +
>>>>2 files changed, 26 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c 
>>>> b/drivers/gpu/drm/vc4/vc4_hdmi.c
>>>> index 95ec5eedea39..eb3192d1fd86 100644
>>>> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
>>>> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
>>>> @@ -80,6 +80,7 @@
>>>># define VC4_HD_M_ENABLEBIT(0)
>>>>
>>>>#define CEC_CLOCK_FREQ 4
>>>> +#define VC4_HSM_MID_CLOCK 149985000
>>>>
>>>>static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
>>>>{
>>>> @@ -380,6 +381,7 @@ static void 
>>>> vc4_hdmi_encoder_post_crtc_powerdown(struct drm_encoder *encoder)
>>>>HDMI_WRITE(HDMI_VID_CTL,
>>>>   HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
>>>>
>>>> +  clk_disable_unprepare(vc4_hdmi->pixel_bvb_clock);
>>>>clk_disable_unprepare(vc4_hdmi->hsm_clock);
>>>>clk_disable_unprepare(vc4_hdmi->pixel_clock);
>>>>
>>>> @@ -638,6 +640,23 @@ static void 
>>>> vc4_hdmi_encoder_pre_crtc_configure(struct drm_encoder *encoder)
>>>>return;
>>>>}
>>>>
>>>> +  ret = clk_set_rate(vc4_hdmi->pixel_bvb_clock,
>>>> +  (hsm_rate > VC4_HSM_MID_CLOCK ? 15000 : 7500));
>>>> +  if (ret) {
>>>> +  DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
>>>> +  clk_disable_unprepare(vc4_hdmi->hsm_clock);
>>>> +  clk_disable_unprepare(vc4_hdmi->pixel_clock);
>>>> +  return;
>>>> +  }
>>>> +
>>>> +  ret = clk_prepare_en

Re: [PATCH 3/3] drm/vc4: hdmi: Add pixel bvb clock control

2020-08-26 Thread Hoegeun Kwon
Hi Stefan,

Thank you for your review.


On 8/26/20 7:04 PM, Stefan Wahren wrote:
> Hi Hoeguen,
>
> Am 21.08.20 um 09:10 schrieb Hoegeun Kwon:
>> There is a problem that the output does not work at a resolution
>> exceeding FHD. To solve this, we need to adjust the bvb clock at a
>> resolution exceeding FHD.
> this patch introduces a mandatory clock, please update
> brcm,bcm2835-hdmi.yaml first.
>
> Is this clock physically available on BCM283x or only on BCM2711?

As far as I know, BCM2711 raspberry pi 4 supports 4k,

don't supported on pi 3 and pi 3+.

Since 4k is not supported in versions prior to Raspberry Pi 4,

I don't think we need to modify the bvb clock.


So I think it is better to update 'brcm,bcm2711-hdmi.yaml'

instead of 'brcm,bcm2835-hdmi.yaml'.

Please comment, what do you think?

>
> I'm a little bit afraid, this change could break with older firmware
> versions on BCM283x.

Tested it several times with libdrm modetest.

I expect there will be no problem.


Best regards,

Hoegeun

>
> Best regards
> Stefan
>
>> Signed-off-by: Hoegeun Kwon 
>> ---
>>   drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
>>   drivers/gpu/drm/vc4/vc4_hdmi.h |  1 +
>>   2 files changed, 26 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
>> index 95ec5eedea39..eb3192d1fd86 100644
>> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
>> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
>> @@ -80,6 +80,7 @@
>>   # define VC4_HD_M_ENABLE   BIT(0)
>>   
>>   #define CEC_CLOCK_FREQ 4
>> +#define VC4_HSM_MID_CLOCK 149985000
>>   
>>   static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
>>   {
>> @@ -380,6 +381,7 @@ static void vc4_hdmi_encoder_post_crtc_powerdown(struct 
>> drm_encoder *encoder)
>>  HDMI_WRITE(HDMI_VID_CTL,
>> HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
>>   
>> +clk_disable_unprepare(vc4_hdmi->pixel_bvb_clock);
>>  clk_disable_unprepare(vc4_hdmi->hsm_clock);
>>  clk_disable_unprepare(vc4_hdmi->pixel_clock);
>>   
>> @@ -638,6 +640,23 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct 
>> drm_encoder *encoder)
>>  return;
>>  }
>>   
>> +ret = clk_set_rate(vc4_hdmi->pixel_bvb_clock,
>> +(hsm_rate > VC4_HSM_MID_CLOCK ? 15000 : 7500));
>> +if (ret) {
>> +DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
>> +clk_disable_unprepare(vc4_hdmi->hsm_clock);
>> +clk_disable_unprepare(vc4_hdmi->pixel_clock);
>> +return;
>> +}
>> +
>> +ret = clk_prepare_enable(vc4_hdmi->pixel_bvb_clock);
>> +if (ret) {
>> +DRM_ERROR("Failed to turn on pixel bvb clock: %d\n", ret);
>> +clk_disable_unprepare(vc4_hdmi->hsm_clock);
>> +clk_disable_unprepare(vc4_hdmi->pixel_clock);
>> +return;
>> +}
>> +
>>  if (vc4_hdmi->variant->reset)
>>  vc4_hdmi->variant->reset(vc4_hdmi);
>>   
>> @@ -1593,6 +1612,12 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi 
>> *vc4_hdmi)
>>  return PTR_ERR(vc4_hdmi->audio_clock);
>>  }
>>   
>> +vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
>> +if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
>> +DRM_ERROR("Failed to get pixel bvb clock\n");
>> +return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
>> +}
>> +
>>  vc4_hdmi->reset = devm_reset_control_get(dev, NULL);
>>  if (IS_ERR(vc4_hdmi->reset)) {
>>  DRM_ERROR("Failed to get HDMI reset line\n");
>> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
>> index 0806c6d9f24e..63c6f8bddf1d 100644
>> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
>> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
>> @@ -147,6 +147,7 @@ struct vc4_hdmi {
>>  struct clk *pixel_clock;
>>  struct clk *hsm_clock;
>>  struct clk *audio_clock;
>> +struct clk *pixel_bvb_clock;
>>   
>>  struct reset_control *reset;
>>   
>


Re: [PATCH v4 00/78] drm/vc4: Support BCM2711 Display Pipeline

2020-08-21 Thread Hoegeun Kwon
Hi Maxime,

Thank you for your version 4 patch.
I tested all 78 patches based on the next-20200708.


Dual HDMI opearation does not work normally.
flip_done timed out occurs and doesn't work.
Could you check please it.

[  105.694541] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
[CRTC:64:crtc-3] flip_done timed out
[  115.934994] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
[CONNECTOR:32:HDMI-A-1] flip_done timed out
[  126.174545] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
[PLANE:60:plane-3] flip_done timed out


And there is a problem with 4k UDH not outputting...
So this problem worked as I fixed it like patches[1].

[1] [PATCH 0/3] drm/vc4: Support HDMI QHD or higher output


"[PATCH v4 00/78] drm/vc4: Support BCM2711 Display Pipeline" all patches.

Tested-by: Hoegeun Kwon 

Best regards,
Hoegeun

> Hi everyone,
>
> Here's a (pretty long) series to introduce support in the VC4 DRM driver
> for the display pipeline found in the BCM2711 (and thus the RaspberryPi 4).
>
> The main differences are that there's two HDMI controllers and that there's
> more pixelvalve now. Those pixelvalve come with a mux in the HVS that still
> have only 3 FIFOs. Both of those differences are breaking a bunch of
> expectations in the driver, so we first need a good bunch of cleanup and
> reworks to introduce support for the new controllers.
>
> Similarly, the HDMI controller has all its registers shuffled and split in
> multiple controllers now, so we need a bunch of changes to support this as
> well.
>
> Only the HDMI support is enabled for now (even though the DPI and DSI
> outputs have been tested too).
>
> Let me know if you have any comments
> Maxime
>
> Cc: bcm-kernel-feedback-l...@broadcom.com
> Cc: devicet...@vger.kernel.org
> Cc: Kamal Dasu 
> Cc: linux-...@vger.kernel.org
> Cc: Michael Turquette 
> Cc: Philipp Zabel 
> Cc: Rob Herring 
> Cc: Stephen Boyd 
>
> Changes from v3:
>- Rebased on top of next-20200708
>- Added a name to the HDMI audio codec component
>- Only disable the BCM2711 HDMI pixelvalves at boot
>- Fixed an error in the HVS binding
>- Fix a framebuffer size condition that was inverted
>- Changed the channel allocation algorithm using Eric's suggestion
>- Always write the muxing values instead of updating if needed
>- Improved a bit the hvs_available_channels comment in the structure
>- Change atomic_complete_commit code to use for_each_new_crtc_in_state
>- Change the muxing code to take into account disparities between the
>  BCM2711 and previous SoCs.
>- Only change the clock rate on BCM2711 during a modeset
>- Fix a crash at atomic_disable
>- Use clk_set_min_rate for the core clock too
>- Add a few defines, and simplify the FIFO level stuff
>- Reordered the patches according to Eric's reviews
>- Fixed a regression with VID_CTL setting on RPI3
>
> Changes from v2:
>- Rebased on top of next-20200526
>- Split the firmware clock series away
>- Removed the stuck pixel (with all the subsequent pixels being shifted
>  by one
>- Fixed the writeback issue too.
>- Fix the dual output
>- Fixed the return value of phy_get_cp_current
>- Enhanced the comment on the reset delay
>- Increase the max width and height
>- Made a proper Kconfig option for the DVP clock driver
>- Fixed the alsa card name collision
>
> Changes from v1:
>- Rebased on top of 5.7-rc1
>- Run checkpatch
>- Added audio support
>- Fixed some HDMI timeouts
>- Swiched to clk_hw_register_gate_parent_data
>- Reorder Kconfig symbols in drivers/i2c/busses
>- Make the firmware clocks a child of the firmware node
>- Switch DVP clock driver to clk_hw interface
>- constify raspberrypi_clk_data in raspberrypi_clock_property
>- Don't mark firmware clocks as IGNORE_UNUSED
>- Change from reset_ms to reset_us in reset-simple, and add a bit more
>  comments
>- Remove generic clk patch to test if a NULL pointer is returned
>- Removed misleading message in the is_prepared renaming patch commit
>  message
>- Constify HDMI controller variants
>- Fix a bug in the allocation size of the clk data array
>- Added a mention in the DT binding conversion patches about the breakage
>- Merged a few fixes from kbuild
>- Fixed a few bisection and CEC build issues
>- Collected Acked-by and Reviewed-by
>- Change Dave email address to raspberrypi.com
>
> Dave Stevenson (7):
>drm/vc4: Add support for the BCM2711 HVS5
>drm/vc4: plane: Change LBM alignment constraint on LBM
>drm/vc4: plane: Optimize the LBM allocation size
>drm/vc4: hdmi: Use reg-names t

[PATCH 2/3] ARM: dts: bcm2711: Add bvb clock for hdmi-pixel

2020-08-21 Thread Hoegeun Kwon
It is necessary to control the hdmi pixel bvb clock. Add bvb clock.

Signed-off-by: Hoegeun Kwon 
---
 arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts 
b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
index b93eb30e1ddb..90dee4cb38bc 100644
--- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
@@ -172,12 +172,14 @@
 };
 
  {
-   clocks = <_clocks 13>, < 0>;
+   clocks = <_clocks 13>, < 0>, <_clocks 14>;
+   clock-names = "hdmi", "clk-108M", "bvb";
status = "okay";
 };
 
  {
-   clocks = <_clocks 13>, < 1>;
+   clocks = <_clocks 13>, < 1>, <_clocks 14>;
+   clock-names = "hdmi", "clk-108M", "bvb";
status = "okay";
 };
 
-- 
2.17.1



[PATCH 1/3] clk: bcm: rpi: Add register to control pixel bvb clk

2020-08-21 Thread Hoegeun Kwon
To use QHD or higher, we need to modify the pixel_bvb_clk value. So
add register to control this clock.

Signed-off-by: Hoegeun Kwon 
---
 drivers/clk/bcm/clk-raspberrypi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/bcm/clk-raspberrypi.c 
b/drivers/clk/bcm/clk-raspberrypi.c
index 5cc82954e1ce..f89b9cfc4309 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -271,6 +271,7 @@ static int raspberrypi_discover_clocks(struct 
raspberrypi_clk *rpi,
case RPI_FIRMWARE_CORE_CLK_ID:
case RPI_FIRMWARE_M2MC_CLK_ID:
case RPI_FIRMWARE_V3D_CLK_ID:
+   case RPI_FIRMWARE_PIXEL_BVB_CLK_ID:
hw = raspberrypi_clk_register(rpi, clks->parent,
  clks->id);
if (IS_ERR(hw))
-- 
2.17.1



[PATCH 3/3] drm/vc4: hdmi: Add pixel bvb clock control

2020-08-21 Thread Hoegeun Kwon
There is a problem that the output does not work at a resolution
exceeding FHD. To solve this, we need to adjust the bvb clock at a
resolution exceeding FHD.

Signed-off-by: Hoegeun Kwon 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
 drivers/gpu/drm/vc4/vc4_hdmi.h |  1 +
 2 files changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 95ec5eedea39..eb3192d1fd86 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -80,6 +80,7 @@
 # define VC4_HD_M_ENABLE   BIT(0)
 
 #define CEC_CLOCK_FREQ 4
+#define VC4_HSM_MID_CLOCK 149985000
 
 static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
 {
@@ -380,6 +381,7 @@ static void vc4_hdmi_encoder_post_crtc_powerdown(struct 
drm_encoder *encoder)
HDMI_WRITE(HDMI_VID_CTL,
   HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
 
+   clk_disable_unprepare(vc4_hdmi->pixel_bvb_clock);
clk_disable_unprepare(vc4_hdmi->hsm_clock);
clk_disable_unprepare(vc4_hdmi->pixel_clock);
 
@@ -638,6 +640,23 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct 
drm_encoder *encoder)
return;
}
 
+   ret = clk_set_rate(vc4_hdmi->pixel_bvb_clock,
+   (hsm_rate > VC4_HSM_MID_CLOCK ? 15000 : 7500));
+   if (ret) {
+   DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
+   clk_disable_unprepare(vc4_hdmi->hsm_clock);
+   clk_disable_unprepare(vc4_hdmi->pixel_clock);
+   return;
+   }
+
+   ret = clk_prepare_enable(vc4_hdmi->pixel_bvb_clock);
+   if (ret) {
+   DRM_ERROR("Failed to turn on pixel bvb clock: %d\n", ret);
+   clk_disable_unprepare(vc4_hdmi->hsm_clock);
+   clk_disable_unprepare(vc4_hdmi->pixel_clock);
+   return;
+   }
+
if (vc4_hdmi->variant->reset)
vc4_hdmi->variant->reset(vc4_hdmi);
 
@@ -1593,6 +1612,12 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi 
*vc4_hdmi)
return PTR_ERR(vc4_hdmi->audio_clock);
}
 
+   vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
+   if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
+   DRM_ERROR("Failed to get pixel bvb clock\n");
+   return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
+   }
+
vc4_hdmi->reset = devm_reset_control_get(dev, NULL);
if (IS_ERR(vc4_hdmi->reset)) {
DRM_ERROR("Failed to get HDMI reset line\n");
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 0806c6d9f24e..63c6f8bddf1d 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -147,6 +147,7 @@ struct vc4_hdmi {
struct clk *pixel_clock;
struct clk *hsm_clock;
struct clk *audio_clock;
+   struct clk *pixel_bvb_clock;
 
struct reset_control *reset;
 
-- 
2.17.1



[PATCH 0/3] drm/vc4: Support HDMI QHD or higher output

2020-08-21 Thread Hoegeun Kwon
Hi everyone,

There is a problem that the output does not work at a resolution
exceeding FHD. To solve this, we need to adjust the bvb clock at a
resolution exceeding FHD.

Rebased on top of next-20200708 and [1].

[1] : [PATCH v4 00/78] drm/vc4: Support BCM2711 Display Pipeline (Maxime's 
patchset)

Hoegeun Kwon (3):
  clk: bcm: rpi: Add register to control pixel bvb clk
  ARM: dts: bcm2711: Add bvb clock for hdmi-pixel
  drm/vc4: hdmi: Add pixel bvb clock control

 arch/arm/boot/dts/bcm2711-rpi-4-b.dts |  6 --
 drivers/clk/bcm/clk-raspberrypi.c |  1 +
 drivers/gpu/drm/vc4/vc4_hdmi.c| 25 +
 drivers/gpu/drm/vc4/vc4_hdmi.h|  1 +
 4 files changed, 31 insertions(+), 2 deletions(-)

-- 
2.17.1



[RESEND PATCH v4 3/3] ARM: dts: exynos: Remove the display-timing and delay from rinato dts

2017-09-17 Thread Hoegeun Kwon
 The display-timing and delay are included in the panel driver. So it
 should be removed in dts.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---

Hi Krzysztof,

This patch was rebased to the mainline (v4.14-rc1).

Best regards,
Hoegeun

 arch/arm/boot/dts/exynos3250-rinato.dts | 22 --
 1 file changed, 22 deletions(-)

diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 0b45467..ff792ff 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -227,28 +227,6 @@
vci-supply = <_reg>;
reset-gpios = < 1 GPIO_ACTIVE_LOW>;
te-gpios = < 6 GPIO_ACTIVE_HIGH>;
-   power-on-delay= <30>;
-   power-off-delay= <120>;
-   reset-delay = <5>;
-   init-delay = <100>;
-   flip-horizontal;
-   flip-vertical;
-   panel-width-mm = <29>;
-   panel-height-mm = <29>;
-
-   display-timings {
-   timing-0 {
-   clock-frequency = <460>;
-   hactive = <320>;
-   vactive = <320>;
-   hfront-porch = <1>;
-   hback-porch = <1>;
-   hsync-len = <1>;
-   vfront-porch = <150>;
-   vback-porch = <1>;
-   vsync-len = <2>;
-   };
-   };
};
 };
 
-- 
1.9.1



[RESEND PATCH v4 3/3] ARM: dts: exynos: Remove the display-timing and delay from rinato dts

2017-09-17 Thread Hoegeun Kwon
 The display-timing and delay are included in the panel driver. So it
 should be removed in dts.

Signed-off-by: Hoegeun Kwon 
---

Hi Krzysztof,

This patch was rebased to the mainline (v4.14-rc1).

Best regards,
Hoegeun

 arch/arm/boot/dts/exynos3250-rinato.dts | 22 --
 1 file changed, 22 deletions(-)

diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 0b45467..ff792ff 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -227,28 +227,6 @@
vci-supply = <_reg>;
reset-gpios = < 1 GPIO_ACTIVE_LOW>;
te-gpios = < 6 GPIO_ACTIVE_HIGH>;
-   power-on-delay= <30>;
-   power-off-delay= <120>;
-   reset-delay = <5>;
-   init-delay = <100>;
-   flip-horizontal;
-   flip-vertical;
-   panel-width-mm = <29>;
-   panel-height-mm = <29>;
-
-   display-timings {
-   timing-0 {
-   clock-frequency = <460>;
-   hactive = <320>;
-   vactive = <320>;
-   hfront-porch = <1>;
-   hback-porch = <1>;
-   hsync-len = <1>;
-   vfront-porch = <150>;
-   vback-porch = <1>;
-   vsync-len = <2>;
-   };
-   };
};
 };
 
-- 
1.9.1



Re: [PATCH v4 4/4] [media] exynos-gsc: Add hardware rotation limits

2017-09-13 Thread Hoegeun Kwon

On 09/13/2017 09:13 PM, Sylwester Nawrocki wrote:

On 09/13/2017 01:41 PM, Hoegeun Kwon wrote:
@@ -1004,11 +1088,33 @@ static irqreturn_t gsc_irq_handler(int irq, 
void *priv)

  .num_clocks = 1,
  };
  +static struct gsc_driverdata gsc_v_5250_drvdata = {
+.variant = {
+[0] = _v_5250_variant,
+[1] = _v_5250_variant,
+[2] = _v_5250_variant,
+[3] = _v_5250_variant,
+},
+.num_entities = 4,
+.clk_names = { "gscl" },
+.num_clocks = 1,
+};
+
+static struct gsc_driverdata gsc_v_5420_drvdata = {
+.variant = {
+[0] = _v_5420_variant,
+[1] = _v_5420_variant,
+},
+.num_entities = 4,


Shouldn't num_enities be 2 here? You don't need to resend, I can
amend that when applying.




Yes, num_enities is 2.
Sorry I made a mistake.

Thanks Sylwester.

Best regards,
Hoegeun


+.clk_names = { "gscl" },
+.num_clocks = 1,
+};
+


--
Regards,
Sylwester






Re: [PATCH v4 4/4] [media] exynos-gsc: Add hardware rotation limits

2017-09-13 Thread Hoegeun Kwon

On 09/13/2017 09:13 PM, Sylwester Nawrocki wrote:

On 09/13/2017 01:41 PM, Hoegeun Kwon wrote:
@@ -1004,11 +1088,33 @@ static irqreturn_t gsc_irq_handler(int irq, 
void *priv)

  .num_clocks = 1,
  };
  +static struct gsc_driverdata gsc_v_5250_drvdata = {
+.variant = {
+[0] = _v_5250_variant,
+[1] = _v_5250_variant,
+[2] = _v_5250_variant,
+[3] = _v_5250_variant,
+},
+.num_entities = 4,
+.clk_names = { "gscl" },
+.num_clocks = 1,
+};
+
+static struct gsc_driverdata gsc_v_5420_drvdata = {
+.variant = {
+[0] = _v_5420_variant,
+[1] = _v_5420_variant,
+},
+.num_entities = 4,


Shouldn't num_enities be 2 here? You don't need to resend, I can
amend that when applying.




Yes, num_enities is 2.
Sorry I made a mistake.

Thanks Sylwester.

Best regards,
Hoegeun


+.clk_names = { "gscl" },
+.num_clocks = 1,
+};
+


--
Regards,
Sylwester






[PATCH v4 4/4] [media] exynos-gsc: Add hardware rotation limits

2017-09-13 Thread Hoegeun Kwon
The hardware rotation limits of gsc depends on SOC (Exynos
5250/5420/5433). Distinguish them and add them to the driver data.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 127 +--
 1 file changed, 122 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 4380150..173a238 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -958,6 +958,51 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
.target_rot_en_h= 2016,
 };
 
+static struct gsc_pix_max gsc_v_5250_max = {
+   .org_scaler_bypass_w= 8192,
+   .org_scaler_bypass_h= 8192,
+   .org_scaler_input_w = 4800,
+   .org_scaler_input_h = 3344,
+   .real_rot_dis_w = 4800,
+   .real_rot_dis_h = 3344,
+   .real_rot_en_w  = 2016,
+   .real_rot_en_h  = 2016,
+   .target_rot_dis_w   = 4800,
+   .target_rot_dis_h   = 3344,
+   .target_rot_en_w= 2016,
+   .target_rot_en_h= 2016,
+};
+
+static struct gsc_pix_max gsc_v_5420_max = {
+   .org_scaler_bypass_w= 8192,
+   .org_scaler_bypass_h= 8192,
+   .org_scaler_input_w = 4800,
+   .org_scaler_input_h = 3344,
+   .real_rot_dis_w = 4800,
+   .real_rot_dis_h = 3344,
+   .real_rot_en_w  = 2048,
+   .real_rot_en_h  = 2048,
+   .target_rot_dis_w   = 4800,
+   .target_rot_dis_h   = 3344,
+   .target_rot_en_w= 2016,
+   .target_rot_en_h= 2016,
+};
+
+static struct gsc_pix_max gsc_v_5433_max = {
+   .org_scaler_bypass_w= 8192,
+   .org_scaler_bypass_h= 8192,
+   .org_scaler_input_w = 4800,
+   .org_scaler_input_h = 3344,
+   .real_rot_dis_w = 4800,
+   .real_rot_dis_h = 3344,
+   .real_rot_en_w  = 2047,
+   .real_rot_en_h  = 2047,
+   .target_rot_dis_w   = 4800,
+   .target_rot_dis_h   = 3344,
+   .target_rot_en_w= 2016,
+   .target_rot_en_h= 2016,
+};
+
 static struct gsc_pix_min gsc_v_100_min = {
.org_w  = 64,
.org_h  = 32,
@@ -992,6 +1037,45 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
.local_sc_down  = 2,
 };
 
+static struct gsc_variant gsc_v_5250_variant = {
+   .pix_max= _v_5250_max,
+   .pix_min= _v_100_min,
+   .pix_align  = _v_100_align,
+   .in_buf_cnt = 32,
+   .out_buf_cnt= 32,
+   .sc_up_max  = 8,
+   .sc_down_max= 16,
+   .poly_sc_down_max   = 4,
+   .pre_sc_down_max= 4,
+   .local_sc_down  = 2,
+};
+
+static struct gsc_variant gsc_v_5420_variant = {
+   .pix_max= _v_5420_max,
+   .pix_min= _v_100_min,
+   .pix_align  = _v_100_align,
+   .in_buf_cnt = 32,
+   .out_buf_cnt= 32,
+   .sc_up_max  = 8,
+   .sc_down_max= 16,
+   .poly_sc_down_max   = 4,
+   .pre_sc_down_max= 4,
+   .local_sc_down  = 2,
+};
+
+static struct gsc_variant gsc_v_5433_variant = {
+   .pix_max= _v_5433_max,
+   .pix_min= _v_100_min,
+   .pix_align  = _v_100_align,
+   .in_buf_cnt = 32,
+   .out_buf_cnt= 32,
+   .sc_up_max  = 8,
+   .sc_down_max= 16,
+   .poly_sc_down_max   = 4,
+   .pre_sc_down_max= 4,
+   .local_sc_down  = 2,
+};
+
 static struct gsc_driverdata gsc_v_100_drvdata = {
.variant = {
[0] = _v_100_variant,
@@ -1004,11 +1088,33 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
.num_clocks = 1,
 };
 
+static struct gsc_driverdata gsc_v_5250_drvdata = {
+   .variant = {
+   [0] = _v_5250_variant,
+   [1] = _v_5250_variant,
+   [2] = _v_5250_variant,
+   [3] = _v_5250_variant,
+   },
+   .num_entities = 4,
+   .clk_names = { "gscl" },
+   .num_clocks = 1,
+};
+
+static struct gsc_driverdata gsc_v_5420_drvdata = {
+   .variant = {
+   [0] = _v_5420_variant,
+   [1] = _v_5420_variant,
+   },
+   .num_entities = 4,
+   .clk_names = { "gscl" },
+   .num_clocks = 1,
+};
+
 static struct gsc_driverdata gsc_5433_drvdata = {
.variant = {
-   [0] = _v_100_variant,
-   [1] = _v_100_variant,
-   [2] = _v_100_variant,
+   [0] = _v_5433_variant,
+   [1] = _v_5433_v

[PATCH v4 4/4] [media] exynos-gsc: Add hardware rotation limits

2017-09-13 Thread Hoegeun Kwon
The hardware rotation limits of gsc depends on SOC (Exynos
5250/5420/5433). Distinguish them and add them to the driver data.

Signed-off-by: Hoegeun Kwon 
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 127 +--
 1 file changed, 122 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 4380150..173a238 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -958,6 +958,51 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
.target_rot_en_h= 2016,
 };
 
+static struct gsc_pix_max gsc_v_5250_max = {
+   .org_scaler_bypass_w= 8192,
+   .org_scaler_bypass_h= 8192,
+   .org_scaler_input_w = 4800,
+   .org_scaler_input_h = 3344,
+   .real_rot_dis_w = 4800,
+   .real_rot_dis_h = 3344,
+   .real_rot_en_w  = 2016,
+   .real_rot_en_h  = 2016,
+   .target_rot_dis_w   = 4800,
+   .target_rot_dis_h   = 3344,
+   .target_rot_en_w= 2016,
+   .target_rot_en_h= 2016,
+};
+
+static struct gsc_pix_max gsc_v_5420_max = {
+   .org_scaler_bypass_w= 8192,
+   .org_scaler_bypass_h= 8192,
+   .org_scaler_input_w = 4800,
+   .org_scaler_input_h = 3344,
+   .real_rot_dis_w = 4800,
+   .real_rot_dis_h = 3344,
+   .real_rot_en_w  = 2048,
+   .real_rot_en_h  = 2048,
+   .target_rot_dis_w   = 4800,
+   .target_rot_dis_h   = 3344,
+   .target_rot_en_w= 2016,
+   .target_rot_en_h= 2016,
+};
+
+static struct gsc_pix_max gsc_v_5433_max = {
+   .org_scaler_bypass_w= 8192,
+   .org_scaler_bypass_h= 8192,
+   .org_scaler_input_w = 4800,
+   .org_scaler_input_h = 3344,
+   .real_rot_dis_w = 4800,
+   .real_rot_dis_h = 3344,
+   .real_rot_en_w  = 2047,
+   .real_rot_en_h  = 2047,
+   .target_rot_dis_w   = 4800,
+   .target_rot_dis_h   = 3344,
+   .target_rot_en_w= 2016,
+   .target_rot_en_h= 2016,
+};
+
 static struct gsc_pix_min gsc_v_100_min = {
.org_w  = 64,
.org_h  = 32,
@@ -992,6 +1037,45 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
.local_sc_down  = 2,
 };
 
+static struct gsc_variant gsc_v_5250_variant = {
+   .pix_max= _v_5250_max,
+   .pix_min= _v_100_min,
+   .pix_align  = _v_100_align,
+   .in_buf_cnt = 32,
+   .out_buf_cnt= 32,
+   .sc_up_max  = 8,
+   .sc_down_max= 16,
+   .poly_sc_down_max   = 4,
+   .pre_sc_down_max= 4,
+   .local_sc_down  = 2,
+};
+
+static struct gsc_variant gsc_v_5420_variant = {
+   .pix_max= _v_5420_max,
+   .pix_min= _v_100_min,
+   .pix_align  = _v_100_align,
+   .in_buf_cnt = 32,
+   .out_buf_cnt= 32,
+   .sc_up_max  = 8,
+   .sc_down_max= 16,
+   .poly_sc_down_max   = 4,
+   .pre_sc_down_max= 4,
+   .local_sc_down  = 2,
+};
+
+static struct gsc_variant gsc_v_5433_variant = {
+   .pix_max= _v_5433_max,
+   .pix_min= _v_100_min,
+   .pix_align  = _v_100_align,
+   .in_buf_cnt = 32,
+   .out_buf_cnt= 32,
+   .sc_up_max  = 8,
+   .sc_down_max= 16,
+   .poly_sc_down_max   = 4,
+   .pre_sc_down_max= 4,
+   .local_sc_down  = 2,
+};
+
 static struct gsc_driverdata gsc_v_100_drvdata = {
.variant = {
[0] = _v_100_variant,
@@ -1004,11 +1088,33 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
.num_clocks = 1,
 };
 
+static struct gsc_driverdata gsc_v_5250_drvdata = {
+   .variant = {
+   [0] = _v_5250_variant,
+   [1] = _v_5250_variant,
+   [2] = _v_5250_variant,
+   [3] = _v_5250_variant,
+   },
+   .num_entities = 4,
+   .clk_names = { "gscl" },
+   .num_clocks = 1,
+};
+
+static struct gsc_driverdata gsc_v_5420_drvdata = {
+   .variant = {
+   [0] = _v_5420_variant,
+   [1] = _v_5420_variant,
+   },
+   .num_entities = 4,
+   .clk_names = { "gscl" },
+   .num_clocks = 1,
+};
+
 static struct gsc_driverdata gsc_5433_drvdata = {
.variant = {
-   [0] = _v_100_variant,
-   [1] = _v_100_variant,
-   [2] = _v_100_variant,
+   [0] = _v_5433_variant,
+   [1] = _v_5433_variant,
+   [

[PATCH v4 2/4] ARM: dts: exynos: Add clean name of compatible.

2017-09-13 Thread Hoegeun Kwon
Exynos 5250 and 5420 have different hardware rotation limits. However,
currently it uses only one compatible - "exynos5-gsc". Since we have
to distinguish between these two, we add different compatible.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 arch/arm/boot/dts/exynos5250.dtsi | 8 
 arch/arm/boot/dts/exynos5420.dtsi | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 8dbeb87..d0d0460 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -637,7 +637,7 @@
};
 
gsc_0:  gsc@13e0 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5250-gsc", 
"samsung,exynos5-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -647,7 +647,7 @@
};
 
gsc_1:  gsc@13e1 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5250-gsc", 
"samsung,exynos5-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -657,7 +657,7 @@
};
 
gsc_2:  gsc@13e2 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5250-gsc", 
"samsung,exynos5-gsc";
reg = <0x13e2 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -667,7 +667,7 @@
};
 
gsc_3:  gsc@13e3 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5250-gsc", 
"samsung,exynos5-gsc";
reg = <0x13e3 0x1000>;
interrupts = ;
power-domains = <_gsc>;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 02d2f89..6166730 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -658,7 +658,7 @@
};
 
gsc_0: video-scaler@13e0 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5420-gsc", 
"samsung,exynos5-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
clocks = < CLK_GSCL0>;
@@ -668,7 +668,7 @@
};
 
gsc_1: video-scaler@13e1 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5420-gsc", 
"samsung,exynos5-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
clocks = < CLK_GSCL1>;
-- 
1.9.1



[PATCH v4 2/4] ARM: dts: exynos: Add clean name of compatible.

2017-09-13 Thread Hoegeun Kwon
Exynos 5250 and 5420 have different hardware rotation limits. However,
currently it uses only one compatible - "exynos5-gsc". Since we have
to distinguish between these two, we add different compatible.

Signed-off-by: Hoegeun Kwon 
---
 arch/arm/boot/dts/exynos5250.dtsi | 8 
 arch/arm/boot/dts/exynos5420.dtsi | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 8dbeb87..d0d0460 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -637,7 +637,7 @@
};
 
gsc_0:  gsc@13e0 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5250-gsc", 
"samsung,exynos5-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -647,7 +647,7 @@
};
 
gsc_1:  gsc@13e1 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5250-gsc", 
"samsung,exynos5-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -657,7 +657,7 @@
};
 
gsc_2:  gsc@13e2 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5250-gsc", 
"samsung,exynos5-gsc";
reg = <0x13e2 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -667,7 +667,7 @@
};
 
gsc_3:  gsc@13e3 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5250-gsc", 
"samsung,exynos5-gsc";
reg = <0x13e3 0x1000>;
interrupts = ;
power-domains = <_gsc>;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 02d2f89..6166730 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -658,7 +658,7 @@
};
 
gsc_0: video-scaler@13e0 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5420-gsc", 
"samsung,exynos5-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
clocks = < CLK_GSCL0>;
@@ -668,7 +668,7 @@
};
 
gsc_1: video-scaler@13e1 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5420-gsc", 
"samsung,exynos5-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
clocks = < CLK_GSCL1>;
-- 
1.9.1



[PATCH v4 3/4] drm/exynos/gsc: Add hardware rotation limits

2017-09-13 Thread Hoegeun Kwon
The gscaler has hardware rotation limits that need to be hardcoded
into driver. Distinguish them and add them to the property list.

The hardware rotation limits are related to the cropped source size.
When swap occurs, use rot_max size instead of crop_max size.

Also the scaling limits are related to pos size, use pos size to check
the limits.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 104 +++-
 include/uapi/drm/exynos_drm.h   |   2 +
 2 files changed, 77 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 0506b2b..66a19d7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -150,6 +151,15 @@ struct gsc_context {
boolsuspended;
 };
 
+/*
+ * struct gsc_driverdata - per device type driver data for init time.
+ *
+ * @rot_max: rotation max resolution.
+ */
+struct gsc_driverdata {
+   struct drm_exynos_sz rot_max;
+};
+
 /* 8-tap Filter Coefficient */
 static const int h_coef_8t[GSC_COEF_RATIO][GSC_COEF_ATTR][GSC_COEF_H_8T] = {
{   /* Ratio <= 65536 (~8:8) */
@@ -1401,6 +1411,23 @@ static int gsc_ippdrv_check_property(struct device *dev,
bool swap;
int i;
 
+   config = >config[EXYNOS_DRM_OPS_DST];
+
+   /* check for degree */
+   switch (config->degree) {
+   case EXYNOS_DRM_DEGREE_90:
+   case EXYNOS_DRM_DEGREE_270:
+   swap = true;
+   break;
+   case EXYNOS_DRM_DEGREE_0:
+   case EXYNOS_DRM_DEGREE_180:
+   swap = false;
+   break;
+   default:
+   DRM_ERROR("invalid degree.\n");
+   goto err_property;
+   }
+
for_each_ipp_ops(i) {
if ((i == EXYNOS_DRM_OPS_SRC) &&
(property->cmd == IPP_CMD_WB))
@@ -1416,21 +1443,6 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
-   /* check for degree */
-   switch (config->degree) {
-   case EXYNOS_DRM_DEGREE_90:
-   case EXYNOS_DRM_DEGREE_270:
-   swap = true;
-   break;
-   case EXYNOS_DRM_DEGREE_0:
-   case EXYNOS_DRM_DEGREE_180:
-   swap = false;
-   break;
-   default:
-   DRM_ERROR("invalid degree.\n");
-   goto err_property;
-   }
-
/* check for buffer bound */
if ((pos->x + pos->w > sz->hsize) ||
(pos->y + pos->h > sz->vsize)) {
@@ -1438,21 +1450,27 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
+   /*
+* The rotation hardware limits are related to the cropped
+* source size. So use rot_max size to check the limits when
+* swap happens. And also the scaling limits are related to pos
+* size, use pos size to check the limits.
+*/
/* check for crop */
if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
if (swap) {
if ((pos->h < pp->crop_min.hsize) ||
-   (sz->vsize > pp->crop_max.hsize) ||
+   (pos->h > pp->rot_max.hsize) ||
(pos->w < pp->crop_min.vsize) ||
-   (sz->hsize > pp->crop_max.vsize)) {
+   (pos->w > pp->rot_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
} else {
if ((pos->w < pp->crop_min.hsize) ||
-   (sz->hsize > pp->crop_max.hsize) ||
+   (pos->w > pp->crop_max.hsize) ||
(pos->h < pp->crop_min.vsize) ||
-   (sz->vsize > pp->crop_max.vsize)) {
+   (pos->h > pp->crop_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
@@ -1463,17 +1481,17 @@ static int

[PATCH v4 3/4] drm/exynos/gsc: Add hardware rotation limits

2017-09-13 Thread Hoegeun Kwon
The gscaler has hardware rotation limits that need to be hardcoded
into driver. Distinguish them and add them to the property list.

The hardware rotation limits are related to the cropped source size.
When swap occurs, use rot_max size instead of crop_max size.

Also the scaling limits are related to pos size, use pos size to check
the limits.

Signed-off-by: Hoegeun Kwon 
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 104 +++-
 include/uapi/drm/exynos_drm.h   |   2 +
 2 files changed, 77 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 0506b2b..66a19d7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -150,6 +151,15 @@ struct gsc_context {
boolsuspended;
 };
 
+/*
+ * struct gsc_driverdata - per device type driver data for init time.
+ *
+ * @rot_max: rotation max resolution.
+ */
+struct gsc_driverdata {
+   struct drm_exynos_sz rot_max;
+};
+
 /* 8-tap Filter Coefficient */
 static const int h_coef_8t[GSC_COEF_RATIO][GSC_COEF_ATTR][GSC_COEF_H_8T] = {
{   /* Ratio <= 65536 (~8:8) */
@@ -1401,6 +1411,23 @@ static int gsc_ippdrv_check_property(struct device *dev,
bool swap;
int i;
 
+   config = >config[EXYNOS_DRM_OPS_DST];
+
+   /* check for degree */
+   switch (config->degree) {
+   case EXYNOS_DRM_DEGREE_90:
+   case EXYNOS_DRM_DEGREE_270:
+   swap = true;
+   break;
+   case EXYNOS_DRM_DEGREE_0:
+   case EXYNOS_DRM_DEGREE_180:
+   swap = false;
+   break;
+   default:
+   DRM_ERROR("invalid degree.\n");
+   goto err_property;
+   }
+
for_each_ipp_ops(i) {
if ((i == EXYNOS_DRM_OPS_SRC) &&
(property->cmd == IPP_CMD_WB))
@@ -1416,21 +1443,6 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
-   /* check for degree */
-   switch (config->degree) {
-   case EXYNOS_DRM_DEGREE_90:
-   case EXYNOS_DRM_DEGREE_270:
-   swap = true;
-   break;
-   case EXYNOS_DRM_DEGREE_0:
-   case EXYNOS_DRM_DEGREE_180:
-   swap = false;
-   break;
-   default:
-   DRM_ERROR("invalid degree.\n");
-   goto err_property;
-   }
-
/* check for buffer bound */
if ((pos->x + pos->w > sz->hsize) ||
(pos->y + pos->h > sz->vsize)) {
@@ -1438,21 +1450,27 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
+   /*
+* The rotation hardware limits are related to the cropped
+* source size. So use rot_max size to check the limits when
+* swap happens. And also the scaling limits are related to pos
+* size, use pos size to check the limits.
+*/
/* check for crop */
if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
if (swap) {
if ((pos->h < pp->crop_min.hsize) ||
-   (sz->vsize > pp->crop_max.hsize) ||
+   (pos->h > pp->rot_max.hsize) ||
(pos->w < pp->crop_min.vsize) ||
-   (sz->hsize > pp->crop_max.vsize)) {
+   (pos->w > pp->rot_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
} else {
if ((pos->w < pp->crop_min.hsize) ||
-   (sz->hsize > pp->crop_max.hsize) ||
+   (pos->w > pp->crop_max.hsize) ||
(pos->h < pp->crop_min.vsize) ||
-   (sz->vsize > pp->crop_max.vsize)) {
+   (pos->h > pp->crop_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
@@ -1463,17 +1481,17 @@ static int gsc_ippdrv_check_property(struct device *dev,
  

[PATCH v4 1/4] [media] exynos-gsc: Add compatible for Exynos 5250 and 5420 specific version

2017-09-13 Thread Hoegeun Kwon
Exynos 5250 and 5420 have different hardware rotation limits.
Since we have to distinguish between these two, we add different
compatible(samsung,exynos5250-gsc and samsung,exynos5420-gsc).

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 Documentation/devicetree/bindings/media/exynos5-gsc.txt | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/exynos5-gsc.txt 
b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
index 26ca25b..0d4fdae 100644
--- a/Documentation/devicetree/bindings/media/exynos5-gsc.txt
+++ b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
@@ -3,8 +3,11 @@
 G-Scaler is used for scaling and color space conversion on EXYNOS5 SoCs.
 
 Required properties:
-- compatible: should be "samsung,exynos5-gsc" (for Exynos 5250, 5420 and
- 5422 SoCs) or "samsung,exynos5433-gsc" (Exynos 5433)
+- compatible: should be one of
+ "samsung,exynos5250-gsc"
+ "samsung,exynos5420-gsc"
+ "samsung,exynos5433-gsc"
+ "samsung,exynos5-gsc" (deprecated)
 - reg: should contain G-Scaler physical address location and length.
 - interrupts: should contain G-Scaler interrupt number
 
@@ -15,7 +18,7 @@ Optional properties:
 Example:
 
 gsc_0:  gsc@0x13e0 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5250-gsc";
reg = <0x13e0 0x1000>;
interrupts = <0 85 0>;
 };
-- 
1.9.1



[PATCH v4 1/4] [media] exynos-gsc: Add compatible for Exynos 5250 and 5420 specific version

2017-09-13 Thread Hoegeun Kwon
Exynos 5250 and 5420 have different hardware rotation limits.
Since we have to distinguish between these two, we add different
compatible(samsung,exynos5250-gsc and samsung,exynos5420-gsc).

Signed-off-by: Hoegeun Kwon 
---
 Documentation/devicetree/bindings/media/exynos5-gsc.txt | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/exynos5-gsc.txt 
b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
index 26ca25b..0d4fdae 100644
--- a/Documentation/devicetree/bindings/media/exynos5-gsc.txt
+++ b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
@@ -3,8 +3,11 @@
 G-Scaler is used for scaling and color space conversion on EXYNOS5 SoCs.
 
 Required properties:
-- compatible: should be "samsung,exynos5-gsc" (for Exynos 5250, 5420 and
- 5422 SoCs) or "samsung,exynos5433-gsc" (Exynos 5433)
+- compatible: should be one of
+ "samsung,exynos5250-gsc"
+ "samsung,exynos5420-gsc"
+ "samsung,exynos5433-gsc"
+ "samsung,exynos5-gsc" (deprecated)
 - reg: should contain G-Scaler physical address location and length.
 - interrupts: should contain G-Scaler interrupt number
 
@@ -15,7 +18,7 @@ Optional properties:
 Example:
 
 gsc_0:  gsc@0x13e0 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5250-gsc";
reg = <0x13e0 0x1000>;
interrupts = <0 85 0>;
 };
-- 
1.9.1



[PATCH v4 0/4] Exynos-gsc: Support the hardware rotation limits

2017-09-13 Thread Hoegeun Kwon
Hello all,

Frist, thanks Krzysztof, Robin and Sylwester.

The gscaler has hardware rotation limits. So this patch set support
the rotate hardware limits of gsc.

Changes for V4:
- Fixed the most specific compatible come first in device tree.
- Kept compatible("samsung,exynos5-gsc") in ther driver.
- Added mark compatible("samsung,exynos5-gsc") as deprecated.
- Added print dmesg if your driver uses compatible("samsung, exynos5-gsc").
- Removed the patch 5, 6 of ver3.

Changes for V3:
- Fixed of_match_node() to of_device_get_match_data() in drm gsc driver.
- Added hardware rotation limits for gsc driver of v4l2.
- Added the remove unnecessary compatible for DT document and Exynos dts.

Changes for V2:
- Added the interface info in binding document.
- Added clean name of compatible in Exynos dts.
- Added maximum supported picture size hardcoded into driver.

Best regards,
Hoegeun

Hoegeun Kwon (4):
  [media] exynos-gsc: Add compatible for Exynos 5250 and 5420 specific
version
  ARM: dts: exynos: Add clean name of compatible.
  drm/exynos/gsc: Add hardware rotation limits
  [media] exynos-gsc: Add hardware rotation limits

 .../devicetree/bindings/media/exynos5-gsc.txt  |   9 +-
 arch/arm/boot/dts/exynos5250.dtsi  |   8 +-
 arch/arm/boot/dts/exynos5420.dtsi  |   4 +-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c| 104 -
 drivers/media/platform/exynos-gsc/gsc-core.c   | 127 -
 include/uapi/drm/exynos_drm.h  |   2 +
 6 files changed, 211 insertions(+), 43 deletions(-)

-- 
1.9.1



[PATCH v4 0/4] Exynos-gsc: Support the hardware rotation limits

2017-09-13 Thread Hoegeun Kwon
Hello all,

Frist, thanks Krzysztof, Robin and Sylwester.

The gscaler has hardware rotation limits. So this patch set support
the rotate hardware limits of gsc.

Changes for V4:
- Fixed the most specific compatible come first in device tree.
- Kept compatible("samsung,exynos5-gsc") in ther driver.
- Added mark compatible("samsung,exynos5-gsc") as deprecated.
- Added print dmesg if your driver uses compatible("samsung, exynos5-gsc").
- Removed the patch 5, 6 of ver3.

Changes for V3:
- Fixed of_match_node() to of_device_get_match_data() in drm gsc driver.
- Added hardware rotation limits for gsc driver of v4l2.
- Added the remove unnecessary compatible for DT document and Exynos dts.

Changes for V2:
- Added the interface info in binding document.
- Added clean name of compatible in Exynos dts.
- Added maximum supported picture size hardcoded into driver.

Best regards,
Hoegeun

Hoegeun Kwon (4):
  [media] exynos-gsc: Add compatible for Exynos 5250 and 5420 specific
version
  ARM: dts: exynos: Add clean name of compatible.
  drm/exynos/gsc: Add hardware rotation limits
  [media] exynos-gsc: Add hardware rotation limits

 .../devicetree/bindings/media/exynos5-gsc.txt  |   9 +-
 arch/arm/boot/dts/exynos5250.dtsi  |   8 +-
 arch/arm/boot/dts/exynos5420.dtsi  |   4 +-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c| 104 -
 drivers/media/platform/exynos-gsc/gsc-core.c   | 127 -
 include/uapi/drm/exynos_drm.h  |   2 +
 6 files changed, 211 insertions(+), 43 deletions(-)

-- 
1.9.1



Re: [PATCH v3 4/6] [media] exynos-gsc: Add hardware rotation limits

2017-09-13 Thread Hoegeun Kwon

On 09/13/2017 06:11 PM, Sylwester Nawrocki wrote:

Hi Hoegeun,

On 09/13/2017 04:33 AM, Hoegeun Kwon wrote:

@@ -1017,8 +1083,12 @@ static irqreturn_t gsc_irq_handler(int irq,
void *priv)
  static const struct of_device_id exynos_gsc_match[] = {
{
-.compatible = "samsung,exynos5-gsc",
-.data = _v_100_drvdata,

Can you keep the "samsung,exynos5-gsc" entry with the gsc_v_5250_variant
data, so that it can work with "samsung,exynos5-gsc" compatible in DT
on both exynos5250 and exynos5420 SoCs?


Thank you for your question.

Exynos 5250 and 5420 have different hardware rotation limits.
Exynos 5250 is '.real_rot_en_w/h = 2016' and 5420 is '.real_rot_en_w/h =
2048'.

So my opinion they must have different compatible.

I think there is some misunderstanding, mu suggestion was to keep the
"samsung,exynos5-gsc" compatible entry in addition to the new introduced
ones: "samsung,exynos5250-gsc" and "samsung,exynos5420-gsc". That's in
order to make your changes possibly backward compatible, in theory
the updated driver should still work without changes in dts.



Thank you again for your explanation.

Yes, I understood.
I will keep "samsung,exynos5-gsc" compatible,
and add Exynos 5250/5420/5433 compatible.

Best regards,
Hoegeun



Re: [PATCH v3 4/6] [media] exynos-gsc: Add hardware rotation limits

2017-09-13 Thread Hoegeun Kwon

On 09/13/2017 06:11 PM, Sylwester Nawrocki wrote:

Hi Hoegeun,

On 09/13/2017 04:33 AM, Hoegeun Kwon wrote:

@@ -1017,8 +1083,12 @@ static irqreturn_t gsc_irq_handler(int irq,
void *priv)
  static const struct of_device_id exynos_gsc_match[] = {
{
-.compatible = "samsung,exynos5-gsc",
-.data = _v_100_drvdata,

Can you keep the "samsung,exynos5-gsc" entry with the gsc_v_5250_variant
data, so that it can work with "samsung,exynos5-gsc" compatible in DT
on both exynos5250 and exynos5420 SoCs?


Thank you for your question.

Exynos 5250 and 5420 have different hardware rotation limits.
Exynos 5250 is '.real_rot_en_w/h = 2016' and 5420 is '.real_rot_en_w/h =
2048'.

So my opinion they must have different compatible.

I think there is some misunderstanding, mu suggestion was to keep the
"samsung,exynos5-gsc" compatible entry in addition to the new introduced
ones: "samsung,exynos5250-gsc" and "samsung,exynos5420-gsc". That's in
order to make your changes possibly backward compatible, in theory
the updated driver should still work without changes in dts.



Thank you again for your explanation.

Yes, I understood.
I will keep "samsung,exynos5-gsc" compatible,
and add Exynos 5250/5420/5433 compatible.

Best regards,
Hoegeun



Re: [PATCH v3 4/6] [media] exynos-gsc: Add hardware rotation limits

2017-09-12 Thread Hoegeun Kwon

Hi Sylwester,

On 09/11/2017 06:35 PM, Sylwester Nawrocki wrote:

On 09/08/2017 08:02 AM, Hoegeun Kwon wrote:

The hardware rotation limits of gsc depends on SOC (Exynos
5250/5420/5433). Distinguish them and add them to the driver data.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
  drivers/media/platform/exynos-gsc/gsc-core.c | 96 


  1 file changed, 83 insertions(+), 13 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c

index 4380150..8f8636e 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -943,7 +943,37 @@ static irqreturn_t gsc_irq_handler(int irq, void 
*priv)

  return IRQ_HANDLED;
  }
  -static struct gsc_pix_max gsc_v_100_max = {
+static struct gsc_pix_max gsc_v_5250_max = {
+.org_scaler_bypass_w= 8192,
+.org_scaler_bypass_h= 8192,
+.org_scaler_input_w= 4800,
+.org_scaler_input_h= 3344,
+.real_rot_dis_w= 4800,
+.real_rot_dis_h= 3344,
+.real_rot_en_w= 2016,
+.real_rot_en_h= 2016,
+.target_rot_dis_w= 4800,
+.target_rot_dis_h= 3344,
+.target_rot_en_w= 2016,
+.target_rot_en_h= 2016,
+};
+
+static struct gsc_pix_max gsc_v_5420_max = {
+.org_scaler_bypass_w= 8192,
+.org_scaler_bypass_h= 8192,
+.org_scaler_input_w= 4800,
+.org_scaler_input_h= 3344,
+.real_rot_dis_w= 4800,
+.real_rot_dis_h= 3344,
+.real_rot_en_w= 2048,
+.real_rot_en_h= 2048,
+.target_rot_dis_w= 4800,
+.target_rot_dis_h= 3344,
+.target_rot_en_w= 2016,
+.target_rot_en_h= 2016,
+};
+
+static struct gsc_pix_max gsc_v_5433_max = {
  .org_scaler_bypass_w= 8192,
  .org_scaler_bypass_h= 8192,
  .org_scaler_input_w= 4800,
@@ -979,8 +1009,8 @@ static irqreturn_t gsc_irq_handler(int irq, void 
*priv)

  .target_h= 2,  /* yuv420 : 2, others : 1 */
  };
  -static struct gsc_variant gsc_v_100_variant = {
-.pix_max= _v_100_max,
+static struct gsc_variant gsc_v_5250_variant = {
+.pix_max= _v_5250_max,
  .pix_min= _v_100_min,
  .pix_align= _v_100_align,
  .in_buf_cnt= 32,
@@ -992,12 +1022,48 @@ static irqreturn_t gsc_irq_handler(int irq, 
void *priv)

  .local_sc_down= 2,
  };
  -static struct gsc_driverdata gsc_v_100_drvdata = {
+static struct gsc_variant gsc_v_5420_variant = {
+.pix_max= _v_5420_max,
+.pix_min= _v_100_min,
+.pix_align= _v_100_align,
+.in_buf_cnt= 32,
+.out_buf_cnt= 32,
+.sc_up_max= 8,
+.sc_down_max= 16,
+.poly_sc_down_max= 4,
+.pre_sc_down_max= 4,
+.local_sc_down= 2,
+};
+
+static struct gsc_variant gsc_v_5433_variant = {
+.pix_max= _v_5433_max,
+.pix_min= _v_100_min,
+.pix_align= _v_100_align,
+.in_buf_cnt= 32,
+.out_buf_cnt= 32,
+.sc_up_max= 8,
+.sc_down_max= 16,
+.poly_sc_down_max= 4,
+.pre_sc_down_max= 4,
+.local_sc_down= 2,
+};
+
+static struct gsc_driverdata gsc_v_5250_drvdata = {
  .variant = {
-[0] = _v_100_variant,
-[1] = _v_100_variant,
-[2] = _v_100_variant,
-[3] = _v_100_variant,
+[0] = _v_5250_variant,
+[1] = _v_5250_variant,
+[2] = _v_5250_variant,
+[3] = _v_5250_variant,
+},
+.num_entities = 4,
+.clk_names = { "gscl" },
+.num_clocks = 1,
+};
+
+static struct gsc_driverdata gsc_v_5420_drvdata = {
+.variant = {
+[0] = _v_5420_variant,
+[1] = _v_5420_variant,
  },
  .num_entities = 4,
  .clk_names = { "gscl" },
@@ -1006,9 +1072,9 @@ static irqreturn_t gsc_irq_handler(int irq, 
void *priv)

static struct gsc_driverdata gsc_5433_drvdata = {
  .variant = {
-[0] = _v_100_variant,
-[1] = _v_100_variant,
-[2] = _v_100_variant,
+[0] = _v_5433_variant,
+[1] = _v_5433_variant,
+[2] = _v_5433_variant,
  },
  .num_entities = 3,
  .clk_names = { "pclk", "aclk", "aclk_xiu", "aclk_gsclbend" },
@@ -1017,8 +1083,12 @@ static irqreturn_t gsc_irq_handler(int irq, 
void *priv)

static const struct of_device_id exynos_gsc_match[] = {
  {
-.compatible = "samsung,exynos5-gsc",
-.data = _v_100_drvdata,


Can you keep the "samsung,exynos5-gsc" entry with the gsc_v_5250_variant
data, so that it can work with "samsung,exynos5-gsc" compatible in DT
on both exynos5250 and exynos5420 SoCs?



Thank you for your question.

Exynos 5250 and 5420 have different hardware rotation limits.
Exynos 5250 is '.real_rot_en_w/h = 2016' an

Re: [PATCH v3 4/6] [media] exynos-gsc: Add hardware rotation limits

2017-09-12 Thread Hoegeun Kwon

Hi Sylwester,

On 09/11/2017 06:35 PM, Sylwester Nawrocki wrote:

On 09/08/2017 08:02 AM, Hoegeun Kwon wrote:

The hardware rotation limits of gsc depends on SOC (Exynos
5250/5420/5433). Distinguish them and add them to the driver data.

Signed-off-by: Hoegeun Kwon 
---
  drivers/media/platform/exynos-gsc/gsc-core.c | 96 


  1 file changed, 83 insertions(+), 13 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c

index 4380150..8f8636e 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -943,7 +943,37 @@ static irqreturn_t gsc_irq_handler(int irq, void 
*priv)

  return IRQ_HANDLED;
  }
  -static struct gsc_pix_max gsc_v_100_max = {
+static struct gsc_pix_max gsc_v_5250_max = {
+.org_scaler_bypass_w= 8192,
+.org_scaler_bypass_h= 8192,
+.org_scaler_input_w= 4800,
+.org_scaler_input_h= 3344,
+.real_rot_dis_w= 4800,
+.real_rot_dis_h= 3344,
+.real_rot_en_w= 2016,
+.real_rot_en_h= 2016,
+.target_rot_dis_w= 4800,
+.target_rot_dis_h= 3344,
+.target_rot_en_w= 2016,
+.target_rot_en_h= 2016,
+};
+
+static struct gsc_pix_max gsc_v_5420_max = {
+.org_scaler_bypass_w= 8192,
+.org_scaler_bypass_h= 8192,
+.org_scaler_input_w= 4800,
+.org_scaler_input_h= 3344,
+.real_rot_dis_w= 4800,
+.real_rot_dis_h= 3344,
+.real_rot_en_w= 2048,
+.real_rot_en_h= 2048,
+.target_rot_dis_w= 4800,
+.target_rot_dis_h= 3344,
+.target_rot_en_w= 2016,
+.target_rot_en_h= 2016,
+};
+
+static struct gsc_pix_max gsc_v_5433_max = {
  .org_scaler_bypass_w= 8192,
  .org_scaler_bypass_h= 8192,
  .org_scaler_input_w= 4800,
@@ -979,8 +1009,8 @@ static irqreturn_t gsc_irq_handler(int irq, void 
*priv)

  .target_h= 2,  /* yuv420 : 2, others : 1 */
  };
  -static struct gsc_variant gsc_v_100_variant = {
-.pix_max= _v_100_max,
+static struct gsc_variant gsc_v_5250_variant = {
+.pix_max= _v_5250_max,
  .pix_min= _v_100_min,
  .pix_align= _v_100_align,
  .in_buf_cnt= 32,
@@ -992,12 +1022,48 @@ static irqreturn_t gsc_irq_handler(int irq, 
void *priv)

  .local_sc_down= 2,
  };
  -static struct gsc_driverdata gsc_v_100_drvdata = {
+static struct gsc_variant gsc_v_5420_variant = {
+.pix_max= _v_5420_max,
+.pix_min= _v_100_min,
+.pix_align= _v_100_align,
+.in_buf_cnt= 32,
+.out_buf_cnt= 32,
+.sc_up_max= 8,
+.sc_down_max= 16,
+.poly_sc_down_max= 4,
+.pre_sc_down_max= 4,
+.local_sc_down= 2,
+};
+
+static struct gsc_variant gsc_v_5433_variant = {
+.pix_max= _v_5433_max,
+.pix_min= _v_100_min,
+.pix_align= _v_100_align,
+.in_buf_cnt= 32,
+.out_buf_cnt= 32,
+.sc_up_max= 8,
+.sc_down_max= 16,
+.poly_sc_down_max= 4,
+.pre_sc_down_max= 4,
+.local_sc_down= 2,
+};
+
+static struct gsc_driverdata gsc_v_5250_drvdata = {
  .variant = {
-[0] = _v_100_variant,
-[1] = _v_100_variant,
-[2] = _v_100_variant,
-[3] = _v_100_variant,
+[0] = _v_5250_variant,
+[1] = _v_5250_variant,
+[2] = _v_5250_variant,
+[3] = _v_5250_variant,
+},
+.num_entities = 4,
+.clk_names = { "gscl" },
+.num_clocks = 1,
+};
+
+static struct gsc_driverdata gsc_v_5420_drvdata = {
+.variant = {
+[0] = _v_5420_variant,
+[1] = _v_5420_variant,
  },
  .num_entities = 4,
  .clk_names = { "gscl" },
@@ -1006,9 +1072,9 @@ static irqreturn_t gsc_irq_handler(int irq, 
void *priv)

static struct gsc_driverdata gsc_5433_drvdata = {
  .variant = {
-[0] = _v_100_variant,
-[1] = _v_100_variant,
-[2] = _v_100_variant,
+[0] = _v_5433_variant,
+[1] = _v_5433_variant,
+[2] = _v_5433_variant,
  },
  .num_entities = 3,
  .clk_names = { "pclk", "aclk", "aclk_xiu", "aclk_gsclbend" },
@@ -1017,8 +1083,12 @@ static irqreturn_t gsc_irq_handler(int irq, 
void *priv)

static const struct of_device_id exynos_gsc_match[] = {
  {
-.compatible = "samsung,exynos5-gsc",
-.data = _v_100_drvdata,


Can you keep the "samsung,exynos5-gsc" entry with the gsc_v_5250_variant
data, so that it can work with "samsung,exynos5-gsc" compatible in DT
on both exynos5250 and exynos5420 SoCs?



Thank you for your question.

Exynos 5250 and 5420 have different hardware rotation limits.
Exynos 5250 is '.real_rot_en_w/h = 2016' and 5420 is '.real_rot_en

Re: [PATCH v2 2/3] ARM: dts: exynos: Add clean name of compatible.

2017-09-12 Thread Hoegeun Kwon

On 09/10/2017 04:57 AM, kbuild test robot wrote:

Hi Hoegeun,

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.13 next-20170908]
[cannot apply to drm-exynos/exynos-drm/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Hoegeun-Kwon/drm-exynos-gsc-Support-the-hardware-rotation-limits/20170910-015155
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm-at91_dt_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
 wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
 chmod +x ~/bin/make.cross
 # save the attached .config to linux build tree
 make.cross ARCH=arm

All errors (new ones prefixed by >>):


Error: arch/arm/boot/dts/exynos5250.dtsi:640.40-41 syntax error

FATAL ERROR: Unable to parse input tree


Thank you for your check.

This problem was caused by typos.
ver3 has been modified.

Best regards,
Hoegeun



---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation




Re: [PATCH v2 2/3] ARM: dts: exynos: Add clean name of compatible.

2017-09-12 Thread Hoegeun Kwon

On 09/10/2017 04:57 AM, kbuild test robot wrote:

Hi Hoegeun,

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.13 next-20170908]
[cannot apply to drm-exynos/exynos-drm/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Hoegeun-Kwon/drm-exynos-gsc-Support-the-hardware-rotation-limits/20170910-015155
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm-at91_dt_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
 wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
 chmod +x ~/bin/make.cross
 # save the attached .config to linux build tree
 make.cross ARCH=arm

All errors (new ones prefixed by >>):


Error: arch/arm/boot/dts/exynos5250.dtsi:640.40-41 syntax error

FATAL ERROR: Unable to parse input tree


Thank you for your check.

This problem was caused by typos.
ver3 has been modified.

Best regards,
Hoegeun



---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation




[PATCH v3 6/6] ARM: dts: exynos: Remove unnecessary compatible

2017-09-08 Thread Hoegeun Kwon
Currently, the compatible('samsung,exynos5-gsc') is not used.
Remove unnecessary compatible.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 arch/arm/boot/dts/exynos5250.dtsi | 8 
 arch/arm/boot/dts/exynos5420.dtsi | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index bf08101..e632faf 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -637,7 +637,7 @@
};
 
gsc_0:  gsc@13e0 {
-   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5250-gsc";
+   compatible = "samsung,exynos5250-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -647,7 +647,7 @@
};
 
gsc_1:  gsc@13e1 {
-   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5250-gsc";
+   compatible = "samsung,exynos5250-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -657,7 +657,7 @@
};
 
gsc_2:  gsc@13e2 {
-   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5250-gsc";
+   compatible = "samsung,exynos5250-gsc";
reg = <0x13e2 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -667,7 +667,7 @@
};
 
gsc_3:  gsc@13e3 {
-   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5250-gsc";
+   compatible = "samsung,exynos5250-gsc";
reg = <0x13e3 0x1000>;
interrupts = ;
power-domains = <_gsc>;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 86afe77..58392b3 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -658,7 +658,7 @@
};
 
gsc_0: video-scaler@13e0 {
-   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";
+   compatible = "samsung,exynos5420-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
clocks = < CLK_GSCL0>;
@@ -668,7 +668,7 @@
};
 
gsc_1: video-scaler@13e1 {
-   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";
+   compatible = "samsung,exynos5420-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
clocks = < CLK_GSCL1>;
-- 
1.9.1



[PATCH v3 5/6] [media] exynos-gsc: Remove unnecessary compatible

2017-09-08 Thread Hoegeun Kwon
Currently, the compatible('samsung,exynos5-gsc') is not used.
Remove unnecessary compatible.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 Documentation/devicetree/bindings/media/exynos5-gsc.txt | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/exynos5-gsc.txt 
b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
index daa56d5..1ea05f1 100644
--- a/Documentation/devicetree/bindings/media/exynos5-gsc.txt
+++ b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
@@ -3,9 +3,9 @@
 G-Scaler is used for scaling and color space conversion on EXYNOS5 SoCs.
 
 Required properties:
-- compatible: should be "samsung,exynos5-gsc" (for Exynos 5250, 5420 and
- 5422 SoCs) or "samsung,exynos5433-gsc" (Exynos 5433)
- or "samsung,exynos5250-gsc" or "samsung,exynos5420-gsc"
+- compatible: should be "samsung,exynos5250-gsc", "samsung,exynos5420-gsc"
+ or "samsung,exynos5433-gsc" (for Exynos 5250, 5420, 5422,
+ and 5433 SoCs)
 - reg: should contain G-Scaler physical address location and length.
 - interrupts: should contain G-Scaler interrupt number
 
@@ -16,7 +16,7 @@ Optional properties:
 Example:
 
 gsc_0:  gsc@0x13e0 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5250-gsc;
reg = <0x13e0 0x1000>;
interrupts = <0 85 0>;
 };
-- 
1.9.1



[PATCH v3 6/6] ARM: dts: exynos: Remove unnecessary compatible

2017-09-08 Thread Hoegeun Kwon
Currently, the compatible('samsung,exynos5-gsc') is not used.
Remove unnecessary compatible.

Signed-off-by: Hoegeun Kwon 
---
 arch/arm/boot/dts/exynos5250.dtsi | 8 
 arch/arm/boot/dts/exynos5420.dtsi | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index bf08101..e632faf 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -637,7 +637,7 @@
};
 
gsc_0:  gsc@13e0 {
-   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5250-gsc";
+   compatible = "samsung,exynos5250-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -647,7 +647,7 @@
};
 
gsc_1:  gsc@13e1 {
-   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5250-gsc";
+   compatible = "samsung,exynos5250-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -657,7 +657,7 @@
};
 
gsc_2:  gsc@13e2 {
-   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5250-gsc";
+   compatible = "samsung,exynos5250-gsc";
reg = <0x13e2 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -667,7 +667,7 @@
};
 
gsc_3:  gsc@13e3 {
-   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5250-gsc";
+   compatible = "samsung,exynos5250-gsc";
reg = <0x13e3 0x1000>;
interrupts = ;
power-domains = <_gsc>;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 86afe77..58392b3 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -658,7 +658,7 @@
};
 
gsc_0: video-scaler@13e0 {
-   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";
+   compatible = "samsung,exynos5420-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
clocks = < CLK_GSCL0>;
@@ -668,7 +668,7 @@
};
 
gsc_1: video-scaler@13e1 {
-   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";
+   compatible = "samsung,exynos5420-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
clocks = < CLK_GSCL1>;
-- 
1.9.1



[PATCH v3 5/6] [media] exynos-gsc: Remove unnecessary compatible

2017-09-08 Thread Hoegeun Kwon
Currently, the compatible('samsung,exynos5-gsc') is not used.
Remove unnecessary compatible.

Signed-off-by: Hoegeun Kwon 
---
 Documentation/devicetree/bindings/media/exynos5-gsc.txt | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/exynos5-gsc.txt 
b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
index daa56d5..1ea05f1 100644
--- a/Documentation/devicetree/bindings/media/exynos5-gsc.txt
+++ b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
@@ -3,9 +3,9 @@
 G-Scaler is used for scaling and color space conversion on EXYNOS5 SoCs.
 
 Required properties:
-- compatible: should be "samsung,exynos5-gsc" (for Exynos 5250, 5420 and
- 5422 SoCs) or "samsung,exynos5433-gsc" (Exynos 5433)
- or "samsung,exynos5250-gsc" or "samsung,exynos5420-gsc"
+- compatible: should be "samsung,exynos5250-gsc", "samsung,exynos5420-gsc"
+ or "samsung,exynos5433-gsc" (for Exynos 5250, 5420, 5422,
+ and 5433 SoCs)
 - reg: should contain G-Scaler physical address location and length.
 - interrupts: should contain G-Scaler interrupt number
 
@@ -16,7 +16,7 @@ Optional properties:
 Example:
 
 gsc_0:  gsc@0x13e0 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5250-gsc;
reg = <0x13e0 0x1000>;
interrupts = <0 85 0>;
 };
-- 
1.9.1



[PATCH v3 4/6] [media] exynos-gsc: Add hardware rotation limits

2017-09-08 Thread Hoegeun Kwon
The hardware rotation limits of gsc depends on SOC (Exynos
5250/5420/5433). Distinguish them and add them to the driver data.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 96 
 1 file changed, 83 insertions(+), 13 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 4380150..8f8636e 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -943,7 +943,37 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
return IRQ_HANDLED;
 }
 
-static struct gsc_pix_max gsc_v_100_max = {
+static struct gsc_pix_max gsc_v_5250_max = {
+   .org_scaler_bypass_w= 8192,
+   .org_scaler_bypass_h= 8192,
+   .org_scaler_input_w = 4800,
+   .org_scaler_input_h = 3344,
+   .real_rot_dis_w = 4800,
+   .real_rot_dis_h = 3344,
+   .real_rot_en_w  = 2016,
+   .real_rot_en_h  = 2016,
+   .target_rot_dis_w   = 4800,
+   .target_rot_dis_h   = 3344,
+   .target_rot_en_w= 2016,
+   .target_rot_en_h= 2016,
+};
+
+static struct gsc_pix_max gsc_v_5420_max = {
+   .org_scaler_bypass_w= 8192,
+   .org_scaler_bypass_h= 8192,
+   .org_scaler_input_w = 4800,
+   .org_scaler_input_h = 3344,
+   .real_rot_dis_w = 4800,
+   .real_rot_dis_h = 3344,
+   .real_rot_en_w  = 2048,
+   .real_rot_en_h  = 2048,
+   .target_rot_dis_w   = 4800,
+   .target_rot_dis_h   = 3344,
+   .target_rot_en_w= 2016,
+   .target_rot_en_h= 2016,
+};
+
+static struct gsc_pix_max gsc_v_5433_max = {
.org_scaler_bypass_w= 8192,
.org_scaler_bypass_h= 8192,
.org_scaler_input_w = 4800,
@@ -979,8 +1009,8 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
.target_h   = 2,  /* yuv420 : 2, others : 1 */
 };
 
-static struct gsc_variant gsc_v_100_variant = {
-   .pix_max= _v_100_max,
+static struct gsc_variant gsc_v_5250_variant = {
+   .pix_max= _v_5250_max,
.pix_min= _v_100_min,
.pix_align  = _v_100_align,
.in_buf_cnt = 32,
@@ -992,12 +1022,48 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
.local_sc_down  = 2,
 };
 
-static struct gsc_driverdata gsc_v_100_drvdata = {
+static struct gsc_variant gsc_v_5420_variant = {
+   .pix_max= _v_5420_max,
+   .pix_min= _v_100_min,
+   .pix_align  = _v_100_align,
+   .in_buf_cnt = 32,
+   .out_buf_cnt= 32,
+   .sc_up_max  = 8,
+   .sc_down_max= 16,
+   .poly_sc_down_max   = 4,
+   .pre_sc_down_max= 4,
+   .local_sc_down  = 2,
+};
+
+static struct gsc_variant gsc_v_5433_variant = {
+   .pix_max= _v_5433_max,
+   .pix_min= _v_100_min,
+   .pix_align  = _v_100_align,
+   .in_buf_cnt = 32,
+   .out_buf_cnt= 32,
+   .sc_up_max  = 8,
+   .sc_down_max= 16,
+   .poly_sc_down_max   = 4,
+   .pre_sc_down_max= 4,
+   .local_sc_down  = 2,
+};
+
+static struct gsc_driverdata gsc_v_5250_drvdata = {
.variant = {
-   [0] = _v_100_variant,
-   [1] = _v_100_variant,
-   [2] = _v_100_variant,
-   [3] = _v_100_variant,
+   [0] = _v_5250_variant,
+   [1] = _v_5250_variant,
+   [2] = _v_5250_variant,
+   [3] = _v_5250_variant,
+   },
+   .num_entities = 4,
+   .clk_names = { "gscl" },
+   .num_clocks = 1,
+};
+
+static struct gsc_driverdata gsc_v_5420_drvdata = {
+   .variant = {
+   [0] = _v_5420_variant,
+   [1] = _v_5420_variant,
},
.num_entities = 4,
.clk_names = { "gscl" },
@@ -1006,9 +1072,9 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
 
 static struct gsc_driverdata gsc_5433_drvdata = {
.variant = {
-   [0] = _v_100_variant,
-   [1] = _v_100_variant,
-   [2] = _v_100_variant,
+   [0] = _v_5433_variant,
+   [1] = _v_5433_variant,
+   [2] = _v_5433_variant,
},
.num_entities = 3,
.clk_names = { "pclk", "aclk", "aclk_xiu", "aclk_gsclbend" },
@@ -1017,8 +1083,12 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
 
 static const struct of_device_id exynos_gsc_match[] = {
{
-   .compatible = "samsung,exynos5-gsc",
-

[PATCH v3 4/6] [media] exynos-gsc: Add hardware rotation limits

2017-09-08 Thread Hoegeun Kwon
The hardware rotation limits of gsc depends on SOC (Exynos
5250/5420/5433). Distinguish them and add them to the driver data.

Signed-off-by: Hoegeun Kwon 
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 96 
 1 file changed, 83 insertions(+), 13 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 4380150..8f8636e 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -943,7 +943,37 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
return IRQ_HANDLED;
 }
 
-static struct gsc_pix_max gsc_v_100_max = {
+static struct gsc_pix_max gsc_v_5250_max = {
+   .org_scaler_bypass_w= 8192,
+   .org_scaler_bypass_h= 8192,
+   .org_scaler_input_w = 4800,
+   .org_scaler_input_h = 3344,
+   .real_rot_dis_w = 4800,
+   .real_rot_dis_h = 3344,
+   .real_rot_en_w  = 2016,
+   .real_rot_en_h  = 2016,
+   .target_rot_dis_w   = 4800,
+   .target_rot_dis_h   = 3344,
+   .target_rot_en_w= 2016,
+   .target_rot_en_h= 2016,
+};
+
+static struct gsc_pix_max gsc_v_5420_max = {
+   .org_scaler_bypass_w= 8192,
+   .org_scaler_bypass_h= 8192,
+   .org_scaler_input_w = 4800,
+   .org_scaler_input_h = 3344,
+   .real_rot_dis_w = 4800,
+   .real_rot_dis_h = 3344,
+   .real_rot_en_w  = 2048,
+   .real_rot_en_h  = 2048,
+   .target_rot_dis_w   = 4800,
+   .target_rot_dis_h   = 3344,
+   .target_rot_en_w= 2016,
+   .target_rot_en_h= 2016,
+};
+
+static struct gsc_pix_max gsc_v_5433_max = {
.org_scaler_bypass_w= 8192,
.org_scaler_bypass_h= 8192,
.org_scaler_input_w = 4800,
@@ -979,8 +1009,8 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
.target_h   = 2,  /* yuv420 : 2, others : 1 */
 };
 
-static struct gsc_variant gsc_v_100_variant = {
-   .pix_max= _v_100_max,
+static struct gsc_variant gsc_v_5250_variant = {
+   .pix_max= _v_5250_max,
.pix_min= _v_100_min,
.pix_align  = _v_100_align,
.in_buf_cnt = 32,
@@ -992,12 +1022,48 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
.local_sc_down  = 2,
 };
 
-static struct gsc_driverdata gsc_v_100_drvdata = {
+static struct gsc_variant gsc_v_5420_variant = {
+   .pix_max= _v_5420_max,
+   .pix_min= _v_100_min,
+   .pix_align  = _v_100_align,
+   .in_buf_cnt = 32,
+   .out_buf_cnt= 32,
+   .sc_up_max  = 8,
+   .sc_down_max= 16,
+   .poly_sc_down_max   = 4,
+   .pre_sc_down_max= 4,
+   .local_sc_down  = 2,
+};
+
+static struct gsc_variant gsc_v_5433_variant = {
+   .pix_max= _v_5433_max,
+   .pix_min= _v_100_min,
+   .pix_align  = _v_100_align,
+   .in_buf_cnt = 32,
+   .out_buf_cnt= 32,
+   .sc_up_max  = 8,
+   .sc_down_max= 16,
+   .poly_sc_down_max   = 4,
+   .pre_sc_down_max= 4,
+   .local_sc_down  = 2,
+};
+
+static struct gsc_driverdata gsc_v_5250_drvdata = {
.variant = {
-   [0] = _v_100_variant,
-   [1] = _v_100_variant,
-   [2] = _v_100_variant,
-   [3] = _v_100_variant,
+   [0] = _v_5250_variant,
+   [1] = _v_5250_variant,
+   [2] = _v_5250_variant,
+   [3] = _v_5250_variant,
+   },
+   .num_entities = 4,
+   .clk_names = { "gscl" },
+   .num_clocks = 1,
+};
+
+static struct gsc_driverdata gsc_v_5420_drvdata = {
+   .variant = {
+   [0] = _v_5420_variant,
+   [1] = _v_5420_variant,
},
.num_entities = 4,
.clk_names = { "gscl" },
@@ -1006,9 +1072,9 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
 
 static struct gsc_driverdata gsc_5433_drvdata = {
.variant = {
-   [0] = _v_100_variant,
-   [1] = _v_100_variant,
-   [2] = _v_100_variant,
+   [0] = _v_5433_variant,
+   [1] = _v_5433_variant,
+   [2] = _v_5433_variant,
},
.num_entities = 3,
.clk_names = { "pclk", "aclk", "aclk_xiu", "aclk_gsclbend" },
@@ -1017,8 +1083,12 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
 
 static const struct of_device_id exynos_gsc_match[] = {
{
-   .compatible = "samsung,exynos5-gsc",
-   .data = _v_100_drvdata,
+  

[PATCH v3 3/6] drm/exynos/gsc: Add hardware rotation limits

2017-09-08 Thread Hoegeun Kwon
The gscaler has hardware rotation limits that need to be hardcoded
into driver. Distinguish them and add them to the property list.

The hardware rotation limits are related to the cropped source size.
When swap occurs, use rot_max size instead of crop_max size.

Also the scaling limits are related to pos size, use pos size to check
the limits.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 93 +++--
 include/uapi/drm/exynos_drm.h   |  2 +
 2 files changed, 66 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 0506b2b..a4fb347 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -150,6 +151,15 @@ struct gsc_context {
boolsuspended;
 };
 
+/*
+ * struct gsc_driverdata - per device type driver data for init time.
+ *
+ * @rot_max: rotation max resolution.
+ */
+struct gsc_driverdata {
+   struct drm_exynos_sz rot_max;
+};
+
 /* 8-tap Filter Coefficient */
 static const int h_coef_8t[GSC_COEF_RATIO][GSC_COEF_ATTR][GSC_COEF_H_8T] = {
{   /* Ratio <= 65536 (~8:8) */
@@ -1401,6 +1411,23 @@ static int gsc_ippdrv_check_property(struct device *dev,
bool swap;
int i;
 
+   config = >config[EXYNOS_DRM_OPS_DST];
+
+   /* check for degree */
+   switch (config->degree) {
+   case EXYNOS_DRM_DEGREE_90:
+   case EXYNOS_DRM_DEGREE_270:
+   swap = true;
+   break;
+   case EXYNOS_DRM_DEGREE_0:
+   case EXYNOS_DRM_DEGREE_180:
+   swap = false;
+   break;
+   default:
+   DRM_ERROR("invalid degree.\n");
+   goto err_property;
+   }
+
for_each_ipp_ops(i) {
if ((i == EXYNOS_DRM_OPS_SRC) &&
(property->cmd == IPP_CMD_WB))
@@ -1416,21 +1443,6 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
-   /* check for degree */
-   switch (config->degree) {
-   case EXYNOS_DRM_DEGREE_90:
-   case EXYNOS_DRM_DEGREE_270:
-   swap = true;
-   break;
-   case EXYNOS_DRM_DEGREE_0:
-   case EXYNOS_DRM_DEGREE_180:
-   swap = false;
-   break;
-   default:
-   DRM_ERROR("invalid degree.\n");
-   goto err_property;
-   }
-
/* check for buffer bound */
if ((pos->x + pos->w > sz->hsize) ||
(pos->y + pos->h > sz->vsize)) {
@@ -1438,21 +1450,27 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
+   /*
+* The rotation hardware limits are related to the cropped
+* source size. So use rot_max size to check the limits when
+* swap happens. And also the scaling limits are related to pos
+* size, use pos size to check the limits.
+*/
/* check for crop */
if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
if (swap) {
if ((pos->h < pp->crop_min.hsize) ||
-   (sz->vsize > pp->crop_max.hsize) ||
+   (pos->h > pp->rot_max.hsize) ||
(pos->w < pp->crop_min.vsize) ||
-   (sz->hsize > pp->crop_max.vsize)) {
+   (pos->w > pp->rot_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
} else {
if ((pos->w < pp->crop_min.hsize) ||
-   (sz->hsize > pp->crop_max.hsize) ||
+   (pos->w > pp->crop_max.hsize) ||
(pos->h < pp->crop_min.vsize) ||
-   (sz->vsize > pp->crop_max.vsize)) {
+   (pos->h > pp->crop_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
@@ -1463,17 +1481,17 @@ static int

[PATCH v3 3/6] drm/exynos/gsc: Add hardware rotation limits

2017-09-08 Thread Hoegeun Kwon
The gscaler has hardware rotation limits that need to be hardcoded
into driver. Distinguish them and add them to the property list.

The hardware rotation limits are related to the cropped source size.
When swap occurs, use rot_max size instead of crop_max size.

Also the scaling limits are related to pos size, use pos size to check
the limits.

Signed-off-by: Hoegeun Kwon 
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 93 +++--
 include/uapi/drm/exynos_drm.h   |  2 +
 2 files changed, 66 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 0506b2b..a4fb347 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -150,6 +151,15 @@ struct gsc_context {
boolsuspended;
 };
 
+/*
+ * struct gsc_driverdata - per device type driver data for init time.
+ *
+ * @rot_max: rotation max resolution.
+ */
+struct gsc_driverdata {
+   struct drm_exynos_sz rot_max;
+};
+
 /* 8-tap Filter Coefficient */
 static const int h_coef_8t[GSC_COEF_RATIO][GSC_COEF_ATTR][GSC_COEF_H_8T] = {
{   /* Ratio <= 65536 (~8:8) */
@@ -1401,6 +1411,23 @@ static int gsc_ippdrv_check_property(struct device *dev,
bool swap;
int i;
 
+   config = >config[EXYNOS_DRM_OPS_DST];
+
+   /* check for degree */
+   switch (config->degree) {
+   case EXYNOS_DRM_DEGREE_90:
+   case EXYNOS_DRM_DEGREE_270:
+   swap = true;
+   break;
+   case EXYNOS_DRM_DEGREE_0:
+   case EXYNOS_DRM_DEGREE_180:
+   swap = false;
+   break;
+   default:
+   DRM_ERROR("invalid degree.\n");
+   goto err_property;
+   }
+
for_each_ipp_ops(i) {
if ((i == EXYNOS_DRM_OPS_SRC) &&
(property->cmd == IPP_CMD_WB))
@@ -1416,21 +1443,6 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
-   /* check for degree */
-   switch (config->degree) {
-   case EXYNOS_DRM_DEGREE_90:
-   case EXYNOS_DRM_DEGREE_270:
-   swap = true;
-   break;
-   case EXYNOS_DRM_DEGREE_0:
-   case EXYNOS_DRM_DEGREE_180:
-   swap = false;
-   break;
-   default:
-   DRM_ERROR("invalid degree.\n");
-   goto err_property;
-   }
-
/* check for buffer bound */
if ((pos->x + pos->w > sz->hsize) ||
(pos->y + pos->h > sz->vsize)) {
@@ -1438,21 +1450,27 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
+   /*
+* The rotation hardware limits are related to the cropped
+* source size. So use rot_max size to check the limits when
+* swap happens. And also the scaling limits are related to pos
+* size, use pos size to check the limits.
+*/
/* check for crop */
if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
if (swap) {
if ((pos->h < pp->crop_min.hsize) ||
-   (sz->vsize > pp->crop_max.hsize) ||
+   (pos->h > pp->rot_max.hsize) ||
(pos->w < pp->crop_min.vsize) ||
-   (sz->hsize > pp->crop_max.vsize)) {
+   (pos->w > pp->rot_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
} else {
if ((pos->w < pp->crop_min.hsize) ||
-   (sz->hsize > pp->crop_max.hsize) ||
+   (pos->w > pp->crop_max.hsize) ||
(pos->h < pp->crop_min.vsize) ||
-   (sz->vsize > pp->crop_max.vsize)) {
+   (pos->h > pp->crop_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
@@ -1463,17 +1481,17 @@ static int gsc_ippdrv_check_property(struct device *dev,
  

[PATCH v3 2/6] ARM: dts: exynos: Add clean name of compatible.

2017-09-08 Thread Hoegeun Kwon
Exynos 5250 and 5420 have different hardware rotation limits. However,
currently it uses only one compatible - "exynos5-gsc". Since we have
to distinguish between these two, we add different compatible.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 arch/arm/boot/dts/exynos5250.dtsi | 8 
 arch/arm/boot/dts/exynos5420.dtsi | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 8dbeb87..bf08101 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -637,7 +637,7 @@
};
 
gsc_0:  gsc@13e0 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5250-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -647,7 +647,7 @@
};
 
gsc_1:  gsc@13e1 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5250-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -657,7 +657,7 @@
};
 
gsc_2:  gsc@13e2 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5250-gsc";
reg = <0x13e2 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -667,7 +667,7 @@
};
 
gsc_3:  gsc@13e3 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5250-gsc";
reg = <0x13e3 0x1000>;
interrupts = ;
power-domains = <_gsc>;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 02d2f89..86afe77 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -658,7 +658,7 @@
};
 
gsc_0: video-scaler@13e0 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
clocks = < CLK_GSCL0>;
@@ -668,7 +668,7 @@
};
 
gsc_1: video-scaler@13e1 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
clocks = < CLK_GSCL1>;
-- 
1.9.1



[PATCH v3 2/6] ARM: dts: exynos: Add clean name of compatible.

2017-09-08 Thread Hoegeun Kwon
Exynos 5250 and 5420 have different hardware rotation limits. However,
currently it uses only one compatible - "exynos5-gsc". Since we have
to distinguish between these two, we add different compatible.

Signed-off-by: Hoegeun Kwon 
---
 arch/arm/boot/dts/exynos5250.dtsi | 8 
 arch/arm/boot/dts/exynos5420.dtsi | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 8dbeb87..bf08101 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -637,7 +637,7 @@
};
 
gsc_0:  gsc@13e0 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5250-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -647,7 +647,7 @@
};
 
gsc_1:  gsc@13e1 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5250-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -657,7 +657,7 @@
};
 
gsc_2:  gsc@13e2 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5250-gsc";
reg = <0x13e2 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -667,7 +667,7 @@
};
 
gsc_3:  gsc@13e3 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5250-gsc";
reg = <0x13e3 0x1000>;
interrupts = ;
power-domains = <_gsc>;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 02d2f89..86afe77 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -658,7 +658,7 @@
};
 
gsc_0: video-scaler@13e0 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
clocks = < CLK_GSCL0>;
@@ -668,7 +668,7 @@
};
 
gsc_1: video-scaler@13e1 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
clocks = < CLK_GSCL1>;
-- 
1.9.1



[PATCH v3 1/6] [media] exynos-gsc: Add compatible for Exynos 5250 and 5420 specific version

2017-09-08 Thread Hoegeun Kwon
Exynos 5250 and 5420 have different hardware rotation limits.
Since we have to distinguish between these two, we add different
compatible(samsung,exynos5250-gsc and samsung,exynos5420-gsc).

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 Documentation/devicetree/bindings/media/exynos5-gsc.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/media/exynos5-gsc.txt 
b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
index 26ca25b..daa56d5 100644
--- a/Documentation/devicetree/bindings/media/exynos5-gsc.txt
+++ b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
@@ -5,6 +5,7 @@ G-Scaler is used for scaling and color space conversion on 
EXYNOS5 SoCs.
 Required properties:
 - compatible: should be "samsung,exynos5-gsc" (for Exynos 5250, 5420 and
  5422 SoCs) or "samsung,exynos5433-gsc" (Exynos 5433)
+ or "samsung,exynos5250-gsc" or "samsung,exynos5420-gsc"
 - reg: should contain G-Scaler physical address location and length.
 - interrupts: should contain G-Scaler interrupt number
 
-- 
1.9.1



[PATCH v3 1/6] [media] exynos-gsc: Add compatible for Exynos 5250 and 5420 specific version

2017-09-08 Thread Hoegeun Kwon
Exynos 5250 and 5420 have different hardware rotation limits.
Since we have to distinguish between these two, we add different
compatible(samsung,exynos5250-gsc and samsung,exynos5420-gsc).

Signed-off-by: Hoegeun Kwon 
---
 Documentation/devicetree/bindings/media/exynos5-gsc.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/media/exynos5-gsc.txt 
b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
index 26ca25b..daa56d5 100644
--- a/Documentation/devicetree/bindings/media/exynos5-gsc.txt
+++ b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
@@ -5,6 +5,7 @@ G-Scaler is used for scaling and color space conversion on 
EXYNOS5 SoCs.
 Required properties:
 - compatible: should be "samsung,exynos5-gsc" (for Exynos 5250, 5420 and
  5422 SoCs) or "samsung,exynos5433-gsc" (Exynos 5433)
+ or "samsung,exynos5250-gsc" or "samsung,exynos5420-gsc"
 - reg: should contain G-Scaler physical address location and length.
 - interrupts: should contain G-Scaler interrupt number
 
-- 
1.9.1



[PATCH v3 0/6] Exynos-gsc: Support the hardware rotation limits

2017-09-08 Thread Hoegeun Kwon
Hello all,

The gscaler has hardware rotation limits. So this patch set support
the rotate hardware limits of gsc.

To avoid problems with bisectability, patches 1~4 must be merged and
then merged 5 and 6.

Changes for V3:
- Fixed of_match_node() to of_device_get_match_data() in drm gsc driver.
- Added hardware rotation limits for gsc driver of v4l2.
- Added the remove unnecessary compatible for DT document and Exynos dts.

Changes for V2:
- Added the interface info in binding document.
- Added clean name of compatible in Exynos dts.
- Added maximum supported picture size hardcoded into driver.

Best regards,
Hoegeun

Hoegeun Kwon (6):
  [media] exynos-gsc: Add compatible for Exynos 5250 and 5420 specific
version
  ARM: dts: exynos: Add clean name of compatible.
  drm/exynos/gsc: Add hardware rotation limits
  [media] exynos-gsc: Add hardware rotation limits
  [media] exynos-gsc: Remove unnecessary compatible
  ARM: dts: exynos: Remove unnecessary compatible

 .../devicetree/bindings/media/exynos5-gsc.txt  |  7 +-
 arch/arm/boot/dts/exynos5250.dtsi  |  8 +-
 arch/arm/boot/dts/exynos5420.dtsi  |  4 +-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c| 93 ++---
 drivers/media/platform/exynos-gsc/gsc-core.c   | 96 +++---
 include/uapi/drm/exynos_drm.h  |  2 +
 6 files changed, 159 insertions(+), 51 deletions(-)

-- 
1.9.1



[PATCH v3 0/6] Exynos-gsc: Support the hardware rotation limits

2017-09-08 Thread Hoegeun Kwon
Hello all,

The gscaler has hardware rotation limits. So this patch set support
the rotate hardware limits of gsc.

To avoid problems with bisectability, patches 1~4 must be merged and
then merged 5 and 6.

Changes for V3:
- Fixed of_match_node() to of_device_get_match_data() in drm gsc driver.
- Added hardware rotation limits for gsc driver of v4l2.
- Added the remove unnecessary compatible for DT document and Exynos dts.

Changes for V2:
- Added the interface info in binding document.
- Added clean name of compatible in Exynos dts.
- Added maximum supported picture size hardcoded into driver.

Best regards,
Hoegeun

Hoegeun Kwon (6):
  [media] exynos-gsc: Add compatible for Exynos 5250 and 5420 specific
version
  ARM: dts: exynos: Add clean name of compatible.
  drm/exynos/gsc: Add hardware rotation limits
  [media] exynos-gsc: Add hardware rotation limits
  [media] exynos-gsc: Remove unnecessary compatible
  ARM: dts: exynos: Remove unnecessary compatible

 .../devicetree/bindings/media/exynos5-gsc.txt  |  7 +-
 arch/arm/boot/dts/exynos5250.dtsi  |  8 +-
 arch/arm/boot/dts/exynos5420.dtsi  |  4 +-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c| 93 ++---
 drivers/media/platform/exynos-gsc/gsc-core.c   | 96 +++---
 include/uapi/drm/exynos_drm.h  |  2 +
 6 files changed, 159 insertions(+), 51 deletions(-)

-- 
1.9.1



Re: [PATCH v2 2/3] ARM: dts: exynos: Add clean name of compatible.

2017-09-07 Thread Hoegeun Kwon

On 09/07/2017 08:27 PM, Marek Szyprowski wrote:

Hi Hoegeun,

On 2017-09-07 11:39, Hoegeun Kwon wrote:

Exynos 5250 and 5420 have different hardware rotation limits. However,
currently it uses only one compatible - "exynos5-gsc". Since we have
to distinguish between these two, we add different compatible.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>


The new values (5250/5420 specific) should replace old exynos5-gsc, 
there is no

point providing both in dts.



Hi Marek,

Thanks for your review.

I used both compatibles to not modify v4l2.
But v4l2 will also be fixed, so 'exynos5-gsc' will be removed.

And also, Thanks for your comment for of_device_get_match_data() of 
patch(3/3).


Best regards,
Hoegeun


---
  arch/arm/boot/dts/exynos5250.dtsi | 8 
  arch/arm/boot/dts/exynos5420.dtsi | 4 ++--
  2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi

index 8dbeb87..f795c76 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -637,7 +637,7 @@
  };
gsc_0:  gsc@13e0 {
-compatible = "samsung,exynos5-gsc";
+compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";

  reg = <0x13e0 0x1000>;
  interrupts = ;
  power-domains = <_gsc>;
@@ -647,7 +647,7 @@
  };
gsc_1:  gsc@13e1 {
-compatible = "samsung,exynos5-gsc";
+compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";

  reg = <0x13e1 0x1000>;
  interrupts = ;
  power-domains = <_gsc>;
@@ -657,7 +657,7 @@
  };
gsc_2:  gsc@13e2 {
-compatible = "samsung,exynos5-gsc";
+compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";

  reg = <0x13e2 0x1000>;
  interrupts = ;
  power-domains = <_gsc>;
@@ -667,7 +667,7 @@
  };
gsc_3:  gsc@13e3 {
-compatible = "samsung,exynos5-gsc";
+compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";

  reg = <0x13e3 0x1000>;
  interrupts = ;
  power-domains = <_gsc>;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi

index 02d2f89..86afe77 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -658,7 +658,7 @@
  };
gsc_0: video-scaler@13e0 {
-compatible = "samsung,exynos5-gsc";
+compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";

  reg = <0x13e0 0x1000>;
  interrupts = ;
  clocks = < CLK_GSCL0>;
@@ -668,7 +668,7 @@
  };
gsc_1: video-scaler@13e1 {
-compatible = "samsung,exynos5-gsc";
+compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";

  reg = <0x13e1 0x1000>;
  interrupts = ;
  clocks = < CLK_GSCL1>;


Best regards




Re: [PATCH v2 2/3] ARM: dts: exynos: Add clean name of compatible.

2017-09-07 Thread Hoegeun Kwon

On 09/07/2017 08:27 PM, Marek Szyprowski wrote:

Hi Hoegeun,

On 2017-09-07 11:39, Hoegeun Kwon wrote:

Exynos 5250 and 5420 have different hardware rotation limits. However,
currently it uses only one compatible - "exynos5-gsc". Since we have
to distinguish between these two, we add different compatible.

Signed-off-by: Hoegeun Kwon 


The new values (5250/5420 specific) should replace old exynos5-gsc, 
there is no

point providing both in dts.



Hi Marek,

Thanks for your review.

I used both compatibles to not modify v4l2.
But v4l2 will also be fixed, so 'exynos5-gsc' will be removed.

And also, Thanks for your comment for of_device_get_match_data() of 
patch(3/3).


Best regards,
Hoegeun


---
  arch/arm/boot/dts/exynos5250.dtsi | 8 
  arch/arm/boot/dts/exynos5420.dtsi | 4 ++--
  2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi

index 8dbeb87..f795c76 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -637,7 +637,7 @@
  };
gsc_0:  gsc@13e0 {
-compatible = "samsung,exynos5-gsc";
+compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";

  reg = <0x13e0 0x1000>;
  interrupts = ;
  power-domains = <_gsc>;
@@ -647,7 +647,7 @@
  };
gsc_1:  gsc@13e1 {
-compatible = "samsung,exynos5-gsc";
+compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";

  reg = <0x13e1 0x1000>;
  interrupts = ;
  power-domains = <_gsc>;
@@ -657,7 +657,7 @@
  };
gsc_2:  gsc@13e2 {
-compatible = "samsung,exynos5-gsc";
+compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";

  reg = <0x13e2 0x1000>;
  interrupts = ;
  power-domains = <_gsc>;
@@ -667,7 +667,7 @@
  };
gsc_3:  gsc@13e3 {
-compatible = "samsung,exynos5-gsc";
+compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";

  reg = <0x13e3 0x1000>;
  interrupts = ;
  power-domains = <_gsc>;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi

index 02d2f89..86afe77 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -658,7 +658,7 @@
  };
gsc_0: video-scaler@13e0 {
-compatible = "samsung,exynos5-gsc";
+compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";

  reg = <0x13e0 0x1000>;
  interrupts = ;
  clocks = < CLK_GSCL0>;
@@ -668,7 +668,7 @@
  };
gsc_1: video-scaler@13e1 {
-compatible = "samsung,exynos5-gsc";
+compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";

  reg = <0x13e1 0x1000>;
  interrupts = ;
  clocks = < CLK_GSCL1>;


Best regards




Re: [PATCH 3/3] drm/exynos/gsc: Add rotation hardware limits of gscaler

2017-09-07 Thread Hoegeun Kwon

On 09/07/2017 08:25 PM, Marek Szyprowski wrote:

Hi Hoegeun,

On 2017-09-07 07:16, Hoegeun Kwon wrote:

On 09/04/2017 03:19 PM, Hoegeun Kwon wrote:

On 09/01/2017 04:31 PM, Marek Szyprowski wrote:

Hi Hoegeun,

On 2017-09-01 03:47, Hoegeun Kwon wrote:
The gscaler has hardware rotation limits that need to be imported 
from

dts. Parse them and add them to the property list.

The rotation hardware limits are related to the cropped source size.
When swap occurs, use rot_max size instead of crop_max size.

Also the scaling limits are related to post size, use pos size to
check the limits.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
  drivers/gpu/drm/exynos/exynos_drm_gsc.c | 63 
+

  include/uapi/drm/exynos_drm.h   |  2 ++
  2 files changed, 42 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c

index 0506b2b..dd9b057 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1401,6 +1401,23 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  bool swap;
  int i;
  +config = >config[EXYNOS_DRM_OPS_DST];
+
+/* check for degree */
+switch (config->degree) {
+case EXYNOS_DRM_DEGREE_90:
+case EXYNOS_DRM_DEGREE_270:
+swap = true;
+break;
+case EXYNOS_DRM_DEGREE_0:
+case EXYNOS_DRM_DEGREE_180:
+swap = false;
+break;
+default:
+DRM_ERROR("invalid degree.\n");
+goto err_property;
+}
+
  for_each_ipp_ops(i) {
  if ((i == EXYNOS_DRM_OPS_SRC) &&
  (property->cmd == IPP_CMD_WB))
@@ -1416,21 +1433,6 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  goto err_property;
  }
  -/* check for degree */
-switch (config->degree) {
-case EXYNOS_DRM_DEGREE_90:
-case EXYNOS_DRM_DEGREE_270:
-swap = true;
-break;
-case EXYNOS_DRM_DEGREE_0:
-case EXYNOS_DRM_DEGREE_180:
-swap = false;
-break;
-default:
-DRM_ERROR("invalid degree.\n");
-goto err_property;
-}
-
  /* check for buffer bound */
  if ((pos->x + pos->w > sz->hsize) ||
  (pos->y + pos->h > sz->vsize)) {
@@ -1438,21 +1440,27 @@ static int 
gsc_ippdrv_check_property(struct device *dev,

  goto err_property;
  }
  +/*
+ * The rotation hardware limits are related to the cropped
+ * source size. So use rot_max size to check the limits when
+ * swap happens. And also the scaling limits are related 
to pos

+ * size, use pos size to check the limits.
+ */
  /* check for crop */
  if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
  if (swap) {
  if ((pos->h < pp->crop_min.hsize) ||
-(sz->vsize > pp->crop_max.hsize) ||
+(pos->h > pp->rot_max.hsize) ||
  (pos->w < pp->crop_min.vsize) ||
-(sz->hsize > pp->crop_max.vsize)) {
+(pos->w > pp->rot_max.vsize)) {
  DRM_ERROR("out of crop size.\n");
  goto err_property;
  }
  } else {
  if ((pos->w < pp->crop_min.hsize) ||
-(sz->hsize > pp->crop_max.hsize) ||
+(pos->w > pp->crop_max.hsize) ||
  (pos->h < pp->crop_min.vsize) ||
-(sz->vsize > pp->crop_max.vsize)) {
+(pos->h > pp->crop_max.vsize)) {
  DRM_ERROR("out of crop size.\n");
  goto err_property;
  }
@@ -1463,17 +1471,17 @@ static int 
gsc_ippdrv_check_property(struct device *dev,

  if ((i == EXYNOS_DRM_OPS_DST) && (pp->scale)) {
  if (swap) {
  if ((pos->h < pp->scale_min.hsize) ||
-(sz->vsize > pp->scale_max.hsize) ||
+(pos->h > pp->scale_max.hsize) ||
  (pos->w < pp->scale_min.vsize) ||
-(sz->hsize > pp->scale_max.vsize)) {
+(pos->w > pp->scale_max.vsize)) {
  DRM_ERROR("out of scale size.\n");
  goto err_property;
  }
  } else {
  if ((pos->w < pp->scale_min.hsize) ||
-(sz->hsize > pp->scale_max.hsize) ||
+(pos->w > pp->scale_max.hsize) ||
  (pos->h < pp->scal

Re: [PATCH 3/3] drm/exynos/gsc: Add rotation hardware limits of gscaler

2017-09-07 Thread Hoegeun Kwon

On 09/07/2017 08:25 PM, Marek Szyprowski wrote:

Hi Hoegeun,

On 2017-09-07 07:16, Hoegeun Kwon wrote:

On 09/04/2017 03:19 PM, Hoegeun Kwon wrote:

On 09/01/2017 04:31 PM, Marek Szyprowski wrote:

Hi Hoegeun,

On 2017-09-01 03:47, Hoegeun Kwon wrote:
The gscaler has hardware rotation limits that need to be imported 
from

dts. Parse them and add them to the property list.

The rotation hardware limits are related to the cropped source size.
When swap occurs, use rot_max size instead of crop_max size.

Also the scaling limits are related to post size, use pos size to
check the limits.

Signed-off-by: Hoegeun Kwon 
---
  drivers/gpu/drm/exynos/exynos_drm_gsc.c | 63 
+

  include/uapi/drm/exynos_drm.h   |  2 ++
  2 files changed, 42 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c

index 0506b2b..dd9b057 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1401,6 +1401,23 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  bool swap;
  int i;
  +config = >config[EXYNOS_DRM_OPS_DST];
+
+/* check for degree */
+switch (config->degree) {
+case EXYNOS_DRM_DEGREE_90:
+case EXYNOS_DRM_DEGREE_270:
+swap = true;
+break;
+case EXYNOS_DRM_DEGREE_0:
+case EXYNOS_DRM_DEGREE_180:
+swap = false;
+break;
+default:
+DRM_ERROR("invalid degree.\n");
+goto err_property;
+}
+
  for_each_ipp_ops(i) {
  if ((i == EXYNOS_DRM_OPS_SRC) &&
  (property->cmd == IPP_CMD_WB))
@@ -1416,21 +1433,6 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  goto err_property;
  }
  -/* check for degree */
-switch (config->degree) {
-case EXYNOS_DRM_DEGREE_90:
-case EXYNOS_DRM_DEGREE_270:
-swap = true;
-break;
-case EXYNOS_DRM_DEGREE_0:
-case EXYNOS_DRM_DEGREE_180:
-swap = false;
-break;
-default:
-DRM_ERROR("invalid degree.\n");
-goto err_property;
-}
-
  /* check for buffer bound */
  if ((pos->x + pos->w > sz->hsize) ||
  (pos->y + pos->h > sz->vsize)) {
@@ -1438,21 +1440,27 @@ static int 
gsc_ippdrv_check_property(struct device *dev,

  goto err_property;
  }
  +/*
+ * The rotation hardware limits are related to the cropped
+ * source size. So use rot_max size to check the limits when
+ * swap happens. And also the scaling limits are related 
to pos

+ * size, use pos size to check the limits.
+ */
  /* check for crop */
  if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
  if (swap) {
  if ((pos->h < pp->crop_min.hsize) ||
-(sz->vsize > pp->crop_max.hsize) ||
+(pos->h > pp->rot_max.hsize) ||
  (pos->w < pp->crop_min.vsize) ||
-(sz->hsize > pp->crop_max.vsize)) {
+(pos->w > pp->rot_max.vsize)) {
  DRM_ERROR("out of crop size.\n");
  goto err_property;
  }
  } else {
  if ((pos->w < pp->crop_min.hsize) ||
-(sz->hsize > pp->crop_max.hsize) ||
+(pos->w > pp->crop_max.hsize) ||
  (pos->h < pp->crop_min.vsize) ||
-(sz->vsize > pp->crop_max.vsize)) {
+(pos->h > pp->crop_max.vsize)) {
  DRM_ERROR("out of crop size.\n");
  goto err_property;
  }
@@ -1463,17 +1471,17 @@ static int 
gsc_ippdrv_check_property(struct device *dev,

  if ((i == EXYNOS_DRM_OPS_DST) && (pp->scale)) {
  if (swap) {
  if ((pos->h < pp->scale_min.hsize) ||
-(sz->vsize > pp->scale_max.hsize) ||
+(pos->h > pp->scale_max.hsize) ||
  (pos->w < pp->scale_min.vsize) ||
-(sz->hsize > pp->scale_max.vsize)) {
+(pos->w > pp->scale_max.vsize)) {
  DRM_ERROR("out of scale size.\n");
  goto err_property;
  }
  } else {
  if ((pos->w < pp->scale_min.hsize) ||
-(sz->hsize > pp->scale_max.hsize) ||
+(pos->w > pp->scale_max.hsize) ||
  (pos->h < pp->scale_min.vsize) ||
-  

[PATCH v2 3/3] drm/exynos/gsc: Add hardware rotation limits

2017-09-07 Thread Hoegeun Kwon
The gscaler has hardware rotation limits that need to be hardcoded
into driver. Distinguish them and add them to the property list.

The hardware rotation limits are related to the cropped source size.
When swap occurs, use rot_max size instead of crop_max size.

Also the scaling limits are related to pos size, use pos size to check
the limits.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 100 +++-
 include/uapi/drm/exynos_drm.h   |   2 +
 2 files changed, 73 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 0506b2b..590a645 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -150,6 +150,15 @@ struct gsc_context {
boolsuspended;
 };
 
+/*
+ * struct gsc_driverdata - per device type driver data for init time.
+ *
+ * @rot_max: rotation max resolution.
+ */
+struct gsc_driverdata {
+   struct drm_exynos_sz rot_max;
+};
+
 /* 8-tap Filter Coefficient */
 static const int h_coef_8t[GSC_COEF_RATIO][GSC_COEF_ATTR][GSC_COEF_H_8T] = {
{   /* Ratio <= 65536 (~8:8) */
@@ -1401,6 +1410,23 @@ static int gsc_ippdrv_check_property(struct device *dev,
bool swap;
int i;
 
+   config = >config[EXYNOS_DRM_OPS_DST];
+
+   /* check for degree */
+   switch (config->degree) {
+   case EXYNOS_DRM_DEGREE_90:
+   case EXYNOS_DRM_DEGREE_270:
+   swap = true;
+   break;
+   case EXYNOS_DRM_DEGREE_0:
+   case EXYNOS_DRM_DEGREE_180:
+   swap = false;
+   break;
+   default:
+   DRM_ERROR("invalid degree.\n");
+   goto err_property;
+   }
+
for_each_ipp_ops(i) {
if ((i == EXYNOS_DRM_OPS_SRC) &&
(property->cmd == IPP_CMD_WB))
@@ -1416,21 +1442,6 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
-   /* check for degree */
-   switch (config->degree) {
-   case EXYNOS_DRM_DEGREE_90:
-   case EXYNOS_DRM_DEGREE_270:
-   swap = true;
-   break;
-   case EXYNOS_DRM_DEGREE_0:
-   case EXYNOS_DRM_DEGREE_180:
-   swap = false;
-   break;
-   default:
-   DRM_ERROR("invalid degree.\n");
-   goto err_property;
-   }
-
/* check for buffer bound */
if ((pos->x + pos->w > sz->hsize) ||
(pos->y + pos->h > sz->vsize)) {
@@ -1438,21 +1449,27 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
+   /*
+* The rotation hardware limits are related to the cropped
+* source size. So use rot_max size to check the limits when
+* swap happens. And also the scaling limits are related to pos
+* size, use pos size to check the limits.
+*/
/* check for crop */
if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
if (swap) {
if ((pos->h < pp->crop_min.hsize) ||
-   (sz->vsize > pp->crop_max.hsize) ||
+   (pos->h > pp->rot_max.hsize) ||
(pos->w < pp->crop_min.vsize) ||
-   (sz->hsize > pp->crop_max.vsize)) {
+   (pos->w > pp->rot_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
} else {
if ((pos->w < pp->crop_min.hsize) ||
-   (sz->hsize > pp->crop_max.hsize) ||
+   (pos->w > pp->crop_max.hsize) ||
(pos->h < pp->crop_min.vsize) ||
-   (sz->vsize > pp->crop_max.vsize)) {
+   (pos->h > pp->crop_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
@@ -1463,17 +1480,17 @@ static int gsc_ippdrv_check_property(struct device *dev,
if ((i == EXYN

[PATCH v2 3/3] drm/exynos/gsc: Add hardware rotation limits

2017-09-07 Thread Hoegeun Kwon
The gscaler has hardware rotation limits that need to be hardcoded
into driver. Distinguish them and add them to the property list.

The hardware rotation limits are related to the cropped source size.
When swap occurs, use rot_max size instead of crop_max size.

Also the scaling limits are related to pos size, use pos size to check
the limits.

Signed-off-by: Hoegeun Kwon 
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 100 +++-
 include/uapi/drm/exynos_drm.h   |   2 +
 2 files changed, 73 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 0506b2b..590a645 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -150,6 +150,15 @@ struct gsc_context {
boolsuspended;
 };
 
+/*
+ * struct gsc_driverdata - per device type driver data for init time.
+ *
+ * @rot_max: rotation max resolution.
+ */
+struct gsc_driverdata {
+   struct drm_exynos_sz rot_max;
+};
+
 /* 8-tap Filter Coefficient */
 static const int h_coef_8t[GSC_COEF_RATIO][GSC_COEF_ATTR][GSC_COEF_H_8T] = {
{   /* Ratio <= 65536 (~8:8) */
@@ -1401,6 +1410,23 @@ static int gsc_ippdrv_check_property(struct device *dev,
bool swap;
int i;
 
+   config = >config[EXYNOS_DRM_OPS_DST];
+
+   /* check for degree */
+   switch (config->degree) {
+   case EXYNOS_DRM_DEGREE_90:
+   case EXYNOS_DRM_DEGREE_270:
+   swap = true;
+   break;
+   case EXYNOS_DRM_DEGREE_0:
+   case EXYNOS_DRM_DEGREE_180:
+   swap = false;
+   break;
+   default:
+   DRM_ERROR("invalid degree.\n");
+   goto err_property;
+   }
+
for_each_ipp_ops(i) {
if ((i == EXYNOS_DRM_OPS_SRC) &&
(property->cmd == IPP_CMD_WB))
@@ -1416,21 +1442,6 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
-   /* check for degree */
-   switch (config->degree) {
-   case EXYNOS_DRM_DEGREE_90:
-   case EXYNOS_DRM_DEGREE_270:
-   swap = true;
-   break;
-   case EXYNOS_DRM_DEGREE_0:
-   case EXYNOS_DRM_DEGREE_180:
-   swap = false;
-   break;
-   default:
-   DRM_ERROR("invalid degree.\n");
-   goto err_property;
-   }
-
/* check for buffer bound */
if ((pos->x + pos->w > sz->hsize) ||
(pos->y + pos->h > sz->vsize)) {
@@ -1438,21 +1449,27 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
+   /*
+* The rotation hardware limits are related to the cropped
+* source size. So use rot_max size to check the limits when
+* swap happens. And also the scaling limits are related to pos
+* size, use pos size to check the limits.
+*/
/* check for crop */
if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
if (swap) {
if ((pos->h < pp->crop_min.hsize) ||
-   (sz->vsize > pp->crop_max.hsize) ||
+   (pos->h > pp->rot_max.hsize) ||
(pos->w < pp->crop_min.vsize) ||
-   (sz->hsize > pp->crop_max.vsize)) {
+   (pos->w > pp->rot_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
} else {
if ((pos->w < pp->crop_min.hsize) ||
-   (sz->hsize > pp->crop_max.hsize) ||
+   (pos->w > pp->crop_max.hsize) ||
(pos->h < pp->crop_min.vsize) ||
-   (sz->vsize > pp->crop_max.vsize)) {
+   (pos->h > pp->crop_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
@@ -1463,17 +1480,17 @@ static int gsc_ippdrv_check_property(struct device *dev,
if ((i == EXYNOS_DRM_OPS_DST) && (pp->scale)) {
  

[PATCH v2 0/3] drm/exynos/gsc: Support the hardware rotation limits

2017-09-07 Thread Hoegeun Kwon
Hello all,

The gscaler has hardware rotation limits. So this patch set support
the rotate hardware limits of gsc.

Changes for V2:
- Added the interface info in binding document.
- Added clean name of compatible in Exynos dts.
- Added maximum supported picture size hardcoded into driver.

Best regards,
Hoegeun

Hoegeun Kwon (3):
  [media] exynos-gsc: Add compatible for Exynos 5250 and 5420 specific
version
  ARM: dts: exynos: Add clean name of compatible.
  drm/exynos/gsc: Add hardware rotation limits

 .../devicetree/bindings/media/exynos5-gsc.txt  |   1 +
 arch/arm/boot/dts/exynos5250.dtsi  |   8 +-
 arch/arm/boot/dts/exynos5420.dtsi  |   4 +-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c| 100 +++--
 include/uapi/drm/exynos_drm.h  |   2 +
 5 files changed, 80 insertions(+), 35 deletions(-)

-- 
1.9.1



[PATCH v2 0/3] drm/exynos/gsc: Support the hardware rotation limits

2017-09-07 Thread Hoegeun Kwon
Hello all,

The gscaler has hardware rotation limits. So this patch set support
the rotate hardware limits of gsc.

Changes for V2:
- Added the interface info in binding document.
- Added clean name of compatible in Exynos dts.
- Added maximum supported picture size hardcoded into driver.

Best regards,
Hoegeun

Hoegeun Kwon (3):
  [media] exynos-gsc: Add compatible for Exynos 5250 and 5420 specific
version
  ARM: dts: exynos: Add clean name of compatible.
  drm/exynos/gsc: Add hardware rotation limits

 .../devicetree/bindings/media/exynos5-gsc.txt  |   1 +
 arch/arm/boot/dts/exynos5250.dtsi  |   8 +-
 arch/arm/boot/dts/exynos5420.dtsi  |   4 +-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c| 100 +++--
 include/uapi/drm/exynos_drm.h  |   2 +
 5 files changed, 80 insertions(+), 35 deletions(-)

-- 
1.9.1



[PATCH v2 2/3] ARM: dts: exynos: Add clean name of compatible.

2017-09-07 Thread Hoegeun Kwon
Exynos 5250 and 5420 have different hardware rotation limits. However,
currently it uses only one compatible - "exynos5-gsc". Since we have
to distinguish between these two, we add different compatible.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 arch/arm/boot/dts/exynos5250.dtsi | 8 
 arch/arm/boot/dts/exynos5420.dtsi | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 8dbeb87..f795c76 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -637,7 +637,7 @@
};
 
gsc_0:  gsc@13e0 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -647,7 +647,7 @@
};
 
gsc_1:  gsc@13e1 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -657,7 +657,7 @@
};
 
gsc_2:  gsc@13e2 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";
reg = <0x13e2 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -667,7 +667,7 @@
};
 
gsc_3:  gsc@13e3 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";
reg = <0x13e3 0x1000>;
interrupts = ;
power-domains = <_gsc>;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 02d2f89..86afe77 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -658,7 +658,7 @@
};
 
gsc_0: video-scaler@13e0 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
clocks = < CLK_GSCL0>;
@@ -668,7 +668,7 @@
};
 
gsc_1: video-scaler@13e1 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
clocks = < CLK_GSCL1>;
-- 
1.9.1



[PATCH v2 2/3] ARM: dts: exynos: Add clean name of compatible.

2017-09-07 Thread Hoegeun Kwon
Exynos 5250 and 5420 have different hardware rotation limits. However,
currently it uses only one compatible - "exynos5-gsc". Since we have
to distinguish between these two, we add different compatible.

Signed-off-by: Hoegeun Kwon 
---
 arch/arm/boot/dts/exynos5250.dtsi | 8 
 arch/arm/boot/dts/exynos5420.dtsi | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 8dbeb87..f795c76 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -637,7 +637,7 @@
};
 
gsc_0:  gsc@13e0 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -647,7 +647,7 @@
};
 
gsc_1:  gsc@13e1 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -657,7 +657,7 @@
};
 
gsc_2:  gsc@13e2 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";
reg = <0x13e2 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -667,7 +667,7 @@
};
 
gsc_3:  gsc@13e3 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";
reg = <0x13e3 0x1000>;
interrupts = ;
power-domains = <_gsc>;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 02d2f89..86afe77 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -658,7 +658,7 @@
};
 
gsc_0: video-scaler@13e0 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
clocks = < CLK_GSCL0>;
@@ -668,7 +668,7 @@
};
 
gsc_1: video-scaler@13e1 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
clocks = < CLK_GSCL1>;
-- 
1.9.1



[PATCH v2 1/3] [media] exynos-gsc: Add compatible for Exynos 5250 and 5420 specific version

2017-09-07 Thread Hoegeun Kwon
Exynos 5250 and 5420 have different hardware rotation limits.
Since we have to distinguish between these two, we add different
compatible(samsung,exynos5250-gsc and samsung,exynos5420-gsc).

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 Documentation/devicetree/bindings/media/exynos5-gsc.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/media/exynos5-gsc.txt 
b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
index 26ca25b..daa56d5 100644
--- a/Documentation/devicetree/bindings/media/exynos5-gsc.txt
+++ b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
@@ -5,6 +5,7 @@ G-Scaler is used for scaling and color space conversion on 
EXYNOS5 SoCs.
 Required properties:
 - compatible: should be "samsung,exynos5-gsc" (for Exynos 5250, 5420 and
  5422 SoCs) or "samsung,exynos5433-gsc" (Exynos 5433)
+ or "samsung,exynos5250-gsc" or "samsung,exynos5420-gsc"
 - reg: should contain G-Scaler physical address location and length.
 - interrupts: should contain G-Scaler interrupt number
 
-- 
1.9.1



[PATCH v2 1/3] [media] exynos-gsc: Add compatible for Exynos 5250 and 5420 specific version

2017-09-07 Thread Hoegeun Kwon
Exynos 5250 and 5420 have different hardware rotation limits.
Since we have to distinguish between these two, we add different
compatible(samsung,exynos5250-gsc and samsung,exynos5420-gsc).

Signed-off-by: Hoegeun Kwon 
---
 Documentation/devicetree/bindings/media/exynos5-gsc.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/media/exynos5-gsc.txt 
b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
index 26ca25b..daa56d5 100644
--- a/Documentation/devicetree/bindings/media/exynos5-gsc.txt
+++ b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
@@ -5,6 +5,7 @@ G-Scaler is used for scaling and color space conversion on 
EXYNOS5 SoCs.
 Required properties:
 - compatible: should be "samsung,exynos5-gsc" (for Exynos 5250, 5420 and
  5422 SoCs) or "samsung,exynos5433-gsc" (Exynos 5433)
+ or "samsung,exynos5250-gsc" or "samsung,exynos5420-gsc"
 - reg: should contain G-Scaler physical address location and length.
 - interrupts: should contain G-Scaler interrupt number
 
-- 
1.9.1



Re: [PATCH 3/3] drm/exynos/gsc: Add rotation hardware limits of gscaler

2017-09-06 Thread Hoegeun Kwon

On 09/04/2017 03:19 PM, Hoegeun Kwon wrote:

On 09/01/2017 04:31 PM, Marek Szyprowski wrote:

Hi Hoegeun,

On 2017-09-01 03:47, Hoegeun Kwon wrote:

The gscaler has hardware rotation limits that need to be imported from
dts. Parse them and add them to the property list.

The rotation hardware limits are related to the cropped source size.
When swap occurs, use rot_max size instead of crop_max size.

Also the scaling limits are related to post size, use pos size to
check the limits.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
  drivers/gpu/drm/exynos/exynos_drm_gsc.c | 63 
+

  include/uapi/drm/exynos_drm.h   |  2 ++
  2 files changed, 42 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c

index 0506b2b..dd9b057 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1401,6 +1401,23 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  bool swap;
  int i;
  +config = >config[EXYNOS_DRM_OPS_DST];
+
+/* check for degree */
+switch (config->degree) {
+case EXYNOS_DRM_DEGREE_90:
+case EXYNOS_DRM_DEGREE_270:
+swap = true;
+break;
+case EXYNOS_DRM_DEGREE_0:
+case EXYNOS_DRM_DEGREE_180:
+swap = false;
+break;
+default:
+DRM_ERROR("invalid degree.\n");
+goto err_property;
+}
+
  for_each_ipp_ops(i) {
  if ((i == EXYNOS_DRM_OPS_SRC) &&
  (property->cmd == IPP_CMD_WB))
@@ -1416,21 +1433,6 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  goto err_property;
  }
  -/* check for degree */
-switch (config->degree) {
-case EXYNOS_DRM_DEGREE_90:
-case EXYNOS_DRM_DEGREE_270:
-swap = true;
-break;
-case EXYNOS_DRM_DEGREE_0:
-case EXYNOS_DRM_DEGREE_180:
-swap = false;
-break;
-default:
-DRM_ERROR("invalid degree.\n");
-goto err_property;
-}
-
  /* check for buffer bound */
  if ((pos->x + pos->w > sz->hsize) ||
  (pos->y + pos->h > sz->vsize)) {
@@ -1438,21 +1440,27 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  goto err_property;
  }
  +/*
+ * The rotation hardware limits are related to the cropped
+ * source size. So use rot_max size to check the limits when
+ * swap happens. And also the scaling limits are related to 
pos

+ * size, use pos size to check the limits.
+ */
  /* check for crop */
  if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
  if (swap) {
  if ((pos->h < pp->crop_min.hsize) ||
-(sz->vsize > pp->crop_max.hsize) ||
+(pos->h > pp->rot_max.hsize) ||
  (pos->w < pp->crop_min.vsize) ||
-(sz->hsize > pp->crop_max.vsize)) {
+(pos->w > pp->rot_max.vsize)) {
  DRM_ERROR("out of crop size.\n");
  goto err_property;
  }
  } else {
  if ((pos->w < pp->crop_min.hsize) ||
-(sz->hsize > pp->crop_max.hsize) ||
+(pos->w > pp->crop_max.hsize) ||
  (pos->h < pp->crop_min.vsize) ||
-(sz->vsize > pp->crop_max.vsize)) {
+(pos->h > pp->crop_max.vsize)) {
  DRM_ERROR("out of crop size.\n");
  goto err_property;
  }
@@ -1463,17 +1471,17 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  if ((i == EXYNOS_DRM_OPS_DST) && (pp->scale)) {
  if (swap) {
  if ((pos->h < pp->scale_min.hsize) ||
-(sz->vsize > pp->scale_max.hsize) ||
+(pos->h > pp->scale_max.hsize) ||
  (pos->w < pp->scale_min.vsize) ||
-(sz->hsize > pp->scale_max.vsize)) {
+(pos->w > pp->scale_max.vsize)) {
  DRM_ERROR("out of scale size.\n");
  goto err_property;
  }
  } else {
  if ((pos->w < pp->scale_min.hsize) ||
-(sz->hsize > pp->scale_max.hsize) ||
+(pos->w > pp->scale_max.hsize) ||
  (pos->h < pp->scale_min.vsize) ||
-(sz->vsize > pp->scale_max.vsize)) {
+

Re: [PATCH 3/3] drm/exynos/gsc: Add rotation hardware limits of gscaler

2017-09-06 Thread Hoegeun Kwon

On 09/04/2017 03:19 PM, Hoegeun Kwon wrote:

On 09/01/2017 04:31 PM, Marek Szyprowski wrote:

Hi Hoegeun,

On 2017-09-01 03:47, Hoegeun Kwon wrote:

The gscaler has hardware rotation limits that need to be imported from
dts. Parse them and add them to the property list.

The rotation hardware limits are related to the cropped source size.
When swap occurs, use rot_max size instead of crop_max size.

Also the scaling limits are related to post size, use pos size to
check the limits.

Signed-off-by: Hoegeun Kwon 
---
  drivers/gpu/drm/exynos/exynos_drm_gsc.c | 63 
+

  include/uapi/drm/exynos_drm.h   |  2 ++
  2 files changed, 42 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c

index 0506b2b..dd9b057 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1401,6 +1401,23 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  bool swap;
  int i;
  +config = >config[EXYNOS_DRM_OPS_DST];
+
+/* check for degree */
+switch (config->degree) {
+case EXYNOS_DRM_DEGREE_90:
+case EXYNOS_DRM_DEGREE_270:
+swap = true;
+break;
+case EXYNOS_DRM_DEGREE_0:
+case EXYNOS_DRM_DEGREE_180:
+swap = false;
+break;
+default:
+DRM_ERROR("invalid degree.\n");
+goto err_property;
+}
+
  for_each_ipp_ops(i) {
  if ((i == EXYNOS_DRM_OPS_SRC) &&
  (property->cmd == IPP_CMD_WB))
@@ -1416,21 +1433,6 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  goto err_property;
  }
  -/* check for degree */
-switch (config->degree) {
-case EXYNOS_DRM_DEGREE_90:
-case EXYNOS_DRM_DEGREE_270:
-swap = true;
-break;
-case EXYNOS_DRM_DEGREE_0:
-case EXYNOS_DRM_DEGREE_180:
-swap = false;
-break;
-default:
-DRM_ERROR("invalid degree.\n");
-goto err_property;
-}
-
  /* check for buffer bound */
  if ((pos->x + pos->w > sz->hsize) ||
  (pos->y + pos->h > sz->vsize)) {
@@ -1438,21 +1440,27 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  goto err_property;
  }
  +/*
+ * The rotation hardware limits are related to the cropped
+ * source size. So use rot_max size to check the limits when
+ * swap happens. And also the scaling limits are related to 
pos

+ * size, use pos size to check the limits.
+ */
  /* check for crop */
  if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
  if (swap) {
  if ((pos->h < pp->crop_min.hsize) ||
-(sz->vsize > pp->crop_max.hsize) ||
+(pos->h > pp->rot_max.hsize) ||
  (pos->w < pp->crop_min.vsize) ||
-(sz->hsize > pp->crop_max.vsize)) {
+(pos->w > pp->rot_max.vsize)) {
  DRM_ERROR("out of crop size.\n");
  goto err_property;
  }
  } else {
  if ((pos->w < pp->crop_min.hsize) ||
-(sz->hsize > pp->crop_max.hsize) ||
+(pos->w > pp->crop_max.hsize) ||
  (pos->h < pp->crop_min.vsize) ||
-(sz->vsize > pp->crop_max.vsize)) {
+(pos->h > pp->crop_max.vsize)) {
  DRM_ERROR("out of crop size.\n");
  goto err_property;
  }
@@ -1463,17 +1471,17 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  if ((i == EXYNOS_DRM_OPS_DST) && (pp->scale)) {
  if (swap) {
  if ((pos->h < pp->scale_min.hsize) ||
-(sz->vsize > pp->scale_max.hsize) ||
+(pos->h > pp->scale_max.hsize) ||
  (pos->w < pp->scale_min.vsize) ||
-(sz->hsize > pp->scale_max.vsize)) {
+(pos->w > pp->scale_max.vsize)) {
  DRM_ERROR("out of scale size.\n");
  goto err_property;
  }
  } else {
  if ((pos->w < pp->scale_min.hsize) ||
-(sz->hsize > pp->scale_max.hsize) ||
+(pos->w > pp->scale_max.hsize) ||
  (pos->h < pp->scale_min.vsize) ||
-(sz->vsize > pp->scale_max.vsize)) {
+(pos->h > pp->scale_m

Re: [PATCH] drm/vblank: Fix delta_ns to an absolute value

2017-09-05 Thread Hoegeun Kwon

On 09/04/2017 04:36 PM, Daniel Vetter wrote:

On Fri, Sep 01, 2017 at 04:36:25PM +0300, Ville Syrjälä wrote:

On Fri, Sep 01, 2017 at 04:07:16PM +0900, Hoegeun Kwon wrote:

If scanout started, we should reduce etime by delta_ns. But delta_ns
is negative if scanout has not started. If delta_ns is negative,
subtraction of delta_ns from etime increases etime. This is wrong, the
etime should not be increased, so you have to make delta_ns an
absolute value.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---

Hello all,

I think that the etime should not be increased.
In cases where delta_ns is negative, if you get time again after an
interrupt call, there is a problem that the time obtained from the
interrupt becomes the future time instead of the past time.

Please let me know if this patch is wrong.

It is wrong. The timestamp corresponds to the first active pixel of the
frame/field. So while between vblank start and active start we expect
to get a timestamp that is in the future.

A bit more strict, it's up to drivers when exactly the vblank interrupt
fires. Some fire at vblank start, some at the end, some somewhen around
that. The only rule is that the vblank must not fire before the point of
no return for another page_flip call, i.e. after the vblank event goes
out, the next page_flip (or atomic ioctl) must go to the next vblank.

So yeah both positive and negative deltas make perfect sense.
-Daniel


Thanks Ville and Daniel,

Your response has been really helpful.
Thanks so much.

Best regards,
Hoegeun


Best regards,
Hoegeun

  drivers/gpu/drm/drm_vblank.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 70f2b95..a3e0176 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -684,7 +684,7 @@ bool drm_calc_vbltimestamp_from_scanoutpos(struct 
drm_device *dev,
/* Subtract time delta from raw timestamp to get final
 * vblank_time timestamp for end of vblank.
 */
-   etime = ktime_sub_ns(etime, delta_ns);
+   etime = ktime_sub_ns(etime, abs(delta_ns));
*vblank_time = ktime_to_timeval(etime);
  
  	DRM_DEBUG_VBL("crtc %u : v p(%d,%d)@ %ld.%ld -> %ld.%ld [e %d us, %d rep]\n",

--
1.9.1

___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel




Re: [PATCH] drm/vblank: Fix delta_ns to an absolute value

2017-09-05 Thread Hoegeun Kwon

On 09/04/2017 04:36 PM, Daniel Vetter wrote:

On Fri, Sep 01, 2017 at 04:36:25PM +0300, Ville Syrjälä wrote:

On Fri, Sep 01, 2017 at 04:07:16PM +0900, Hoegeun Kwon wrote:

If scanout started, we should reduce etime by delta_ns. But delta_ns
is negative if scanout has not started. If delta_ns is negative,
subtraction of delta_ns from etime increases etime. This is wrong, the
etime should not be increased, so you have to make delta_ns an
absolute value.

Signed-off-by: Hoegeun Kwon 
---

Hello all,

I think that the etime should not be increased.
In cases where delta_ns is negative, if you get time again after an
interrupt call, there is a problem that the time obtained from the
interrupt becomes the future time instead of the past time.

Please let me know if this patch is wrong.

It is wrong. The timestamp corresponds to the first active pixel of the
frame/field. So while between vblank start and active start we expect
to get a timestamp that is in the future.

A bit more strict, it's up to drivers when exactly the vblank interrupt
fires. Some fire at vblank start, some at the end, some somewhen around
that. The only rule is that the vblank must not fire before the point of
no return for another page_flip call, i.e. after the vblank event goes
out, the next page_flip (or atomic ioctl) must go to the next vblank.

So yeah both positive and negative deltas make perfect sense.
-Daniel


Thanks Ville and Daniel,

Your response has been really helpful.
Thanks so much.

Best regards,
Hoegeun


Best regards,
Hoegeun

  drivers/gpu/drm/drm_vblank.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 70f2b95..a3e0176 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -684,7 +684,7 @@ bool drm_calc_vbltimestamp_from_scanoutpos(struct 
drm_device *dev,
/* Subtract time delta from raw timestamp to get final
 * vblank_time timestamp for end of vblank.
 */
-   etime = ktime_sub_ns(etime, delta_ns);
+   etime = ktime_sub_ns(etime, abs(delta_ns));
*vblank_time = ktime_to_timeval(etime);
  
  	DRM_DEBUG_VBL("crtc %u : v p(%d,%d)@ %ld.%ld -> %ld.%ld [e %d us, %d rep]\n",

--
1.9.1

___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel




Re: [PATCH 3/3] drm/exynos/gsc: Add rotation hardware limits of gscaler

2017-09-04 Thread Hoegeun Kwon

On 09/01/2017 04:31 PM, Marek Szyprowski wrote:

Hi Hoegeun,

On 2017-09-01 03:47, Hoegeun Kwon wrote:

The gscaler has hardware rotation limits that need to be imported from
dts. Parse them and add them to the property list.

The rotation hardware limits are related to the cropped source size.
When swap occurs, use rot_max size instead of crop_max size.

Also the scaling limits are related to post size, use pos size to
check the limits.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
  drivers/gpu/drm/exynos/exynos_drm_gsc.c | 63 
+

  include/uapi/drm/exynos_drm.h   |  2 ++
  2 files changed, 42 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c

index 0506b2b..dd9b057 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1401,6 +1401,23 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  bool swap;
  int i;
  +config = >config[EXYNOS_DRM_OPS_DST];
+
+/* check for degree */
+switch (config->degree) {
+case EXYNOS_DRM_DEGREE_90:
+case EXYNOS_DRM_DEGREE_270:
+swap = true;
+break;
+case EXYNOS_DRM_DEGREE_0:
+case EXYNOS_DRM_DEGREE_180:
+swap = false;
+break;
+default:
+DRM_ERROR("invalid degree.\n");
+goto err_property;
+}
+
  for_each_ipp_ops(i) {
  if ((i == EXYNOS_DRM_OPS_SRC) &&
  (property->cmd == IPP_CMD_WB))
@@ -1416,21 +1433,6 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  goto err_property;
  }
  -/* check for degree */
-switch (config->degree) {
-case EXYNOS_DRM_DEGREE_90:
-case EXYNOS_DRM_DEGREE_270:
-swap = true;
-break;
-case EXYNOS_DRM_DEGREE_0:
-case EXYNOS_DRM_DEGREE_180:
-swap = false;
-break;
-default:
-DRM_ERROR("invalid degree.\n");
-goto err_property;
-}
-
  /* check for buffer bound */
  if ((pos->x + pos->w > sz->hsize) ||
  (pos->y + pos->h > sz->vsize)) {
@@ -1438,21 +1440,27 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  goto err_property;
  }
  +/*
+ * The rotation hardware limits are related to the cropped
+ * source size. So use rot_max size to check the limits when
+ * swap happens. And also the scaling limits are related to pos
+ * size, use pos size to check the limits.
+ */
  /* check for crop */
  if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
  if (swap) {
  if ((pos->h < pp->crop_min.hsize) ||
-(sz->vsize > pp->crop_max.hsize) ||
+(pos->h > pp->rot_max.hsize) ||
  (pos->w < pp->crop_min.vsize) ||
-(sz->hsize > pp->crop_max.vsize)) {
+(pos->w > pp->rot_max.vsize)) {
  DRM_ERROR("out of crop size.\n");
  goto err_property;
  }
  } else {
  if ((pos->w < pp->crop_min.hsize) ||
-(sz->hsize > pp->crop_max.hsize) ||
+(pos->w > pp->crop_max.hsize) ||
  (pos->h < pp->crop_min.vsize) ||
-(sz->vsize > pp->crop_max.vsize)) {
+(pos->h > pp->crop_max.vsize)) {
  DRM_ERROR("out of crop size.\n");
  goto err_property;
  }
@@ -1463,17 +1471,17 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  if ((i == EXYNOS_DRM_OPS_DST) && (pp->scale)) {
  if (swap) {
  if ((pos->h < pp->scale_min.hsize) ||
-(sz->vsize > pp->scale_max.hsize) ||
+(pos->h > pp->scale_max.hsize) ||
  (pos->w < pp->scale_min.vsize) ||
-(sz->hsize > pp->scale_max.vsize)) {
+(pos->w > pp->scale_max.vsize)) {
  DRM_ERROR("out of scale size.\n");
  goto err_property;
  }
  } else {
  if ((pos->w < pp->scale_min.hsize) ||
-(sz->hsize > pp->scale_max.hsize) ||
+(pos->w > pp->scale_max.hsize) ||
  (pos->h < pp->scale_min.vsize) ||
-(sz->vsize > pp->scale_max.vsize)) {
+(pos->h > pp->scale_max.vsize)) {

Re: [PATCH 3/3] drm/exynos/gsc: Add rotation hardware limits of gscaler

2017-09-04 Thread Hoegeun Kwon

On 09/01/2017 04:31 PM, Marek Szyprowski wrote:

Hi Hoegeun,

On 2017-09-01 03:47, Hoegeun Kwon wrote:

The gscaler has hardware rotation limits that need to be imported from
dts. Parse them and add them to the property list.

The rotation hardware limits are related to the cropped source size.
When swap occurs, use rot_max size instead of crop_max size.

Also the scaling limits are related to post size, use pos size to
check the limits.

Signed-off-by: Hoegeun Kwon 
---
  drivers/gpu/drm/exynos/exynos_drm_gsc.c | 63 
+

  include/uapi/drm/exynos_drm.h   |  2 ++
  2 files changed, 42 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c

index 0506b2b..dd9b057 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1401,6 +1401,23 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  bool swap;
  int i;
  +config = >config[EXYNOS_DRM_OPS_DST];
+
+/* check for degree */
+switch (config->degree) {
+case EXYNOS_DRM_DEGREE_90:
+case EXYNOS_DRM_DEGREE_270:
+swap = true;
+break;
+case EXYNOS_DRM_DEGREE_0:
+case EXYNOS_DRM_DEGREE_180:
+swap = false;
+break;
+default:
+DRM_ERROR("invalid degree.\n");
+goto err_property;
+}
+
  for_each_ipp_ops(i) {
  if ((i == EXYNOS_DRM_OPS_SRC) &&
  (property->cmd == IPP_CMD_WB))
@@ -1416,21 +1433,6 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  goto err_property;
  }
  -/* check for degree */
-switch (config->degree) {
-case EXYNOS_DRM_DEGREE_90:
-case EXYNOS_DRM_DEGREE_270:
-swap = true;
-break;
-case EXYNOS_DRM_DEGREE_0:
-case EXYNOS_DRM_DEGREE_180:
-swap = false;
-break;
-default:
-DRM_ERROR("invalid degree.\n");
-goto err_property;
-}
-
  /* check for buffer bound */
  if ((pos->x + pos->w > sz->hsize) ||
  (pos->y + pos->h > sz->vsize)) {
@@ -1438,21 +1440,27 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  goto err_property;
  }
  +/*
+ * The rotation hardware limits are related to the cropped
+ * source size. So use rot_max size to check the limits when
+ * swap happens. And also the scaling limits are related to pos
+ * size, use pos size to check the limits.
+ */
  /* check for crop */
  if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
  if (swap) {
  if ((pos->h < pp->crop_min.hsize) ||
-(sz->vsize > pp->crop_max.hsize) ||
+(pos->h > pp->rot_max.hsize) ||
  (pos->w < pp->crop_min.vsize) ||
-(sz->hsize > pp->crop_max.vsize)) {
+(pos->w > pp->rot_max.vsize)) {
  DRM_ERROR("out of crop size.\n");
  goto err_property;
  }
  } else {
  if ((pos->w < pp->crop_min.hsize) ||
-(sz->hsize > pp->crop_max.hsize) ||
+(pos->w > pp->crop_max.hsize) ||
  (pos->h < pp->crop_min.vsize) ||
-(sz->vsize > pp->crop_max.vsize)) {
+(pos->h > pp->crop_max.vsize)) {
  DRM_ERROR("out of crop size.\n");
  goto err_property;
  }
@@ -1463,17 +1471,17 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  if ((i == EXYNOS_DRM_OPS_DST) && (pp->scale)) {
  if (swap) {
  if ((pos->h < pp->scale_min.hsize) ||
-(sz->vsize > pp->scale_max.hsize) ||
+(pos->h > pp->scale_max.hsize) ||
  (pos->w < pp->scale_min.vsize) ||
-(sz->hsize > pp->scale_max.vsize)) {
+(pos->w > pp->scale_max.vsize)) {
  DRM_ERROR("out of scale size.\n");
  goto err_property;
  }
  } else {
  if ((pos->w < pp->scale_min.hsize) ||
-(sz->hsize > pp->scale_max.hsize) ||
+(pos->w > pp->scale_max.hsize) ||
  (pos->h < pp->scale_min.vsize) ||
-(sz->vsize > pp->scale_max.vsize)) {
+(pos->h > pp->scale_max.vsize)) {
  DRM_ERROR("o

[PATCH] drm/vblank: Fix delta_ns to an absolute value

2017-09-01 Thread Hoegeun Kwon
If scanout started, we should reduce etime by delta_ns. But delta_ns
is negative if scanout has not started. If delta_ns is negative,
subtraction of delta_ns from etime increases etime. This is wrong, the
etime should not be increased, so you have to make delta_ns an
absolute value.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---

Hello all,

I think that the etime should not be increased.
In cases where delta_ns is negative, if you get time again after an
interrupt call, there is a problem that the time obtained from the
interrupt becomes the future time instead of the past time.

Please let me know if this patch is wrong.

Best regards,
Hoegeun

 drivers/gpu/drm/drm_vblank.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 70f2b95..a3e0176 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -684,7 +684,7 @@ bool drm_calc_vbltimestamp_from_scanoutpos(struct 
drm_device *dev,
/* Subtract time delta from raw timestamp to get final
 * vblank_time timestamp for end of vblank.
 */
-   etime = ktime_sub_ns(etime, delta_ns);
+   etime = ktime_sub_ns(etime, abs(delta_ns));
*vblank_time = ktime_to_timeval(etime);
 
DRM_DEBUG_VBL("crtc %u : v p(%d,%d)@ %ld.%ld -> %ld.%ld [e %d us, %d 
rep]\n",
-- 
1.9.1



[PATCH] drm/vblank: Fix delta_ns to an absolute value

2017-09-01 Thread Hoegeun Kwon
If scanout started, we should reduce etime by delta_ns. But delta_ns
is negative if scanout has not started. If delta_ns is negative,
subtraction of delta_ns from etime increases etime. This is wrong, the
etime should not be increased, so you have to make delta_ns an
absolute value.

Signed-off-by: Hoegeun Kwon 
---

Hello all,

I think that the etime should not be increased.
In cases where delta_ns is negative, if you get time again after an
interrupt call, there is a problem that the time obtained from the
interrupt becomes the future time instead of the past time.

Please let me know if this patch is wrong.

Best regards,
Hoegeun

 drivers/gpu/drm/drm_vblank.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 70f2b95..a3e0176 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -684,7 +684,7 @@ bool drm_calc_vbltimestamp_from_scanoutpos(struct 
drm_device *dev,
/* Subtract time delta from raw timestamp to get final
 * vblank_time timestamp for end of vblank.
 */
-   etime = ktime_sub_ns(etime, delta_ns);
+   etime = ktime_sub_ns(etime, abs(delta_ns));
*vblank_time = ktime_to_timeval(etime);
 
DRM_DEBUG_VBL("crtc %u : v p(%d,%d)@ %ld.%ld -> %ld.%ld [e %d us, %d 
rep]\n",
-- 
1.9.1



[PATCH 1/3] ARM: dts: exynos: Add the hardware rotation limits for gsc

2017-08-31 Thread Hoegeun Kwon
The gscaler has maximum size of input or output rotation. Add the
hardware limits property for the gscaler rotation in the exynos5250
and exynos5420 dts.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 arch/arm/boot/dts/exynos5250.dtsi | 8 
 arch/arm/boot/dts/exynos5420.dtsi | 4 
 2 files changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 8dbeb87..d9434e0 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -643,6 +643,8 @@
power-domains = <_gsc>;
clocks = < CLK_GSCL0>;
clock-names = "gscl";
+   rot-max-hsize = <2048>;
+   rot-max-vsize = <2048>;
iommu = <_gsc0>;
};
 
@@ -653,6 +655,8 @@
power-domains = <_gsc>;
clocks = < CLK_GSCL1>;
clock-names = "gscl";
+   rot-max-hsize = <2048>;
+   rot-max-vsize = <2048>;
iommu = <_gsc1>;
};
 
@@ -663,6 +667,8 @@
power-domains = <_gsc>;
clocks = < CLK_GSCL2>;
clock-names = "gscl";
+   rot-max-hsize = <2048>;
+   rot-max-vsize = <2048>;
iommu = <_gsc2>;
};
 
@@ -673,6 +679,8 @@
power-domains = <_gsc>;
clocks = < CLK_GSCL3>;
clock-names = "gscl";
+   rot-max-hsize = <2048>;
+   rot-max-vsize = <2048>;
iommu = <_gsc3>;
};
 
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 02d2f89..0fd6be9 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -664,6 +664,8 @@
clocks = < CLK_GSCL0>;
clock-names = "gscl";
power-domains = <_pd>;
+   rot-max-hsize = <2016>;
+   rot-max-vsize = <2016>;
iommus = <_gscl0>;
};
 
@@ -674,6 +676,8 @@
clocks = < CLK_GSCL1>;
clock-names = "gscl";
power-domains = <_pd>;
+   rot-max-hsize = <2016>;
+   rot-max-vsize = <2016>;
iommus = <_gscl1>;
};
 
-- 
1.9.1



[PATCH 0/3] drm/exynos/gsc: Support the rotate hardware limits of gsc

2017-08-31 Thread Hoegeun Kwon
Hello all,

The gscaler has hardware rotation limits. So this patch set support
the rotate hardware limits of gsc.

Best regards,
Hoegeun

Hoegeun Kwon (3):
  ARM: dts: exynos: Add the hardware rotation limits for gsc
  arm64: dts: exynos: Add the hardware rotation limits for gsc
  drm/exynos/gsc: Add rotation hardware limits of gscaler

 arch/arm/boot/dts/exynos5250.dtsi  |  8 
 arch/arm/boot/dts/exynos5420.dtsi  |  4 ++
 arch/arm64/boot/dts/exynos/exynos5433.dtsi |  6 +++
 drivers/gpu/drm/exynos/exynos_drm_gsc.c| 63 +++---
 include/uapi/drm/exynos_drm.h  |  2 +
 5 files changed, 60 insertions(+), 23 deletions(-)

-- 
1.9.1



[PATCH 1/3] ARM: dts: exynos: Add the hardware rotation limits for gsc

2017-08-31 Thread Hoegeun Kwon
The gscaler has maximum size of input or output rotation. Add the
hardware limits property for the gscaler rotation in the exynos5250
and exynos5420 dts.

Signed-off-by: Hoegeun Kwon 
---
 arch/arm/boot/dts/exynos5250.dtsi | 8 
 arch/arm/boot/dts/exynos5420.dtsi | 4 
 2 files changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 8dbeb87..d9434e0 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -643,6 +643,8 @@
power-domains = <_gsc>;
clocks = < CLK_GSCL0>;
clock-names = "gscl";
+   rot-max-hsize = <2048>;
+   rot-max-vsize = <2048>;
iommu = <_gsc0>;
};
 
@@ -653,6 +655,8 @@
power-domains = <_gsc>;
clocks = < CLK_GSCL1>;
clock-names = "gscl";
+   rot-max-hsize = <2048>;
+   rot-max-vsize = <2048>;
iommu = <_gsc1>;
};
 
@@ -663,6 +667,8 @@
power-domains = <_gsc>;
clocks = < CLK_GSCL2>;
clock-names = "gscl";
+   rot-max-hsize = <2048>;
+   rot-max-vsize = <2048>;
iommu = <_gsc2>;
};
 
@@ -673,6 +679,8 @@
power-domains = <_gsc>;
clocks = < CLK_GSCL3>;
clock-names = "gscl";
+   rot-max-hsize = <2048>;
+   rot-max-vsize = <2048>;
iommu = <_gsc3>;
};
 
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 02d2f89..0fd6be9 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -664,6 +664,8 @@
clocks = < CLK_GSCL0>;
clock-names = "gscl";
power-domains = <_pd>;
+   rot-max-hsize = <2016>;
+   rot-max-vsize = <2016>;
iommus = <_gscl0>;
};
 
@@ -674,6 +676,8 @@
clocks = < CLK_GSCL1>;
clock-names = "gscl";
power-domains = <_pd>;
+   rot-max-hsize = <2016>;
+   rot-max-vsize = <2016>;
iommus = <_gscl1>;
};
 
-- 
1.9.1



[PATCH 0/3] drm/exynos/gsc: Support the rotate hardware limits of gsc

2017-08-31 Thread Hoegeun Kwon
Hello all,

The gscaler has hardware rotation limits. So this patch set support
the rotate hardware limits of gsc.

Best regards,
Hoegeun

Hoegeun Kwon (3):
  ARM: dts: exynos: Add the hardware rotation limits for gsc
  arm64: dts: exynos: Add the hardware rotation limits for gsc
  drm/exynos/gsc: Add rotation hardware limits of gscaler

 arch/arm/boot/dts/exynos5250.dtsi  |  8 
 arch/arm/boot/dts/exynos5420.dtsi  |  4 ++
 arch/arm64/boot/dts/exynos/exynos5433.dtsi |  6 +++
 drivers/gpu/drm/exynos/exynos_drm_gsc.c| 63 +++---
 include/uapi/drm/exynos_drm.h  |  2 +
 5 files changed, 60 insertions(+), 23 deletions(-)

-- 
1.9.1



[PATCH 3/3] drm/exynos/gsc: Add rotation hardware limits of gscaler

2017-08-31 Thread Hoegeun Kwon
The gscaler has hardware rotation limits that need to be imported from
dts. Parse them and add them to the property list.

The rotation hardware limits are related to the cropped source size.
When swap occurs, use rot_max size instead of crop_max size.

Also the scaling limits are related to post size, use pos size to
check the limits.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 63 +
 include/uapi/drm/exynos_drm.h   |  2 ++
 2 files changed, 42 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 0506b2b..dd9b057 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1401,6 +1401,23 @@ static int gsc_ippdrv_check_property(struct device *dev,
bool swap;
int i;
 
+   config = >config[EXYNOS_DRM_OPS_DST];
+
+   /* check for degree */
+   switch (config->degree) {
+   case EXYNOS_DRM_DEGREE_90:
+   case EXYNOS_DRM_DEGREE_270:
+   swap = true;
+   break;
+   case EXYNOS_DRM_DEGREE_0:
+   case EXYNOS_DRM_DEGREE_180:
+   swap = false;
+   break;
+   default:
+   DRM_ERROR("invalid degree.\n");
+   goto err_property;
+   }
+
for_each_ipp_ops(i) {
if ((i == EXYNOS_DRM_OPS_SRC) &&
(property->cmd == IPP_CMD_WB))
@@ -1416,21 +1433,6 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
-   /* check for degree */
-   switch (config->degree) {
-   case EXYNOS_DRM_DEGREE_90:
-   case EXYNOS_DRM_DEGREE_270:
-   swap = true;
-   break;
-   case EXYNOS_DRM_DEGREE_0:
-   case EXYNOS_DRM_DEGREE_180:
-   swap = false;
-   break;
-   default:
-   DRM_ERROR("invalid degree.\n");
-   goto err_property;
-   }
-
/* check for buffer bound */
if ((pos->x + pos->w > sz->hsize) ||
(pos->y + pos->h > sz->vsize)) {
@@ -1438,21 +1440,27 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
+   /*
+* The rotation hardware limits are related to the cropped
+* source size. So use rot_max size to check the limits when
+* swap happens. And also the scaling limits are related to pos
+* size, use pos size to check the limits.
+*/
/* check for crop */
if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
if (swap) {
if ((pos->h < pp->crop_min.hsize) ||
-   (sz->vsize > pp->crop_max.hsize) ||
+   (pos->h > pp->rot_max.hsize) ||
(pos->w < pp->crop_min.vsize) ||
-   (sz->hsize > pp->crop_max.vsize)) {
+   (pos->w > pp->rot_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
} else {
if ((pos->w < pp->crop_min.hsize) ||
-   (sz->hsize > pp->crop_max.hsize) ||
+   (pos->w > pp->crop_max.hsize) ||
(pos->h < pp->crop_min.vsize) ||
-   (sz->vsize > pp->crop_max.vsize)) {
+   (pos->h > pp->crop_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
@@ -1463,17 +1471,17 @@ static int gsc_ippdrv_check_property(struct device *dev,
if ((i == EXYNOS_DRM_OPS_DST) && (pp->scale)) {
if (swap) {
if ((pos->h < pp->scale_min.hsize) ||
-   (sz->vsize > pp->scale_max.hsize) ||
+   (pos->h > pp->scale_max.hsize) ||
(pos->w < pp->scale_min.vsize) ||
-  

[PATCH 2/3] arm64: dts: exynos: Add the hardware rotation limits for gsc

2017-08-31 Thread Hoegeun Kwon
The gscaler has maximum size of input or output rotation. Add the
hardware limits property for the gscaler rotation in the exynos5433
dts.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 7fe994b..57c9997 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -891,6 +891,8 @@
 <_gscl CLK_ACLK_GSCL0>,
 <_gscl CLK_ACLK_XIU_GSCLX>,
 <_gscl CLK_ACLK_GSCLBEND_333>;
+   rot-max-hsize = <2047>;
+   rot-max-vsize = <2047>;
iommus = <_gscl0>;
};
 
@@ -904,6 +906,8 @@
 <_gscl CLK_ACLK_GSCL1>,
 <_gscl CLK_ACLK_XIU_GSCLX>,
 <_gscl CLK_ACLK_GSCLBEND_333>;
+   rot-max-hsize = <2047>;
+   rot-max-vsize = <2047>;
iommus = <_gscl1>;
};
 
@@ -917,6 +921,8 @@
 <_gscl CLK_ACLK_GSCL2>,
 <_gscl CLK_ACLK_XIU_GSCLX>,
 <_gscl CLK_ACLK_GSCLBEND_333>;
+   rot-max-hsize = <2047>;
+   rot-max-vsize = <2047>;
iommus = <_gscl2>;
};
 
-- 
1.9.1



[PATCH 3/3] drm/exynos/gsc: Add rotation hardware limits of gscaler

2017-08-31 Thread Hoegeun Kwon
The gscaler has hardware rotation limits that need to be imported from
dts. Parse them and add them to the property list.

The rotation hardware limits are related to the cropped source size.
When swap occurs, use rot_max size instead of crop_max size.

Also the scaling limits are related to post size, use pos size to
check the limits.

Signed-off-by: Hoegeun Kwon 
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 63 +
 include/uapi/drm/exynos_drm.h   |  2 ++
 2 files changed, 42 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 0506b2b..dd9b057 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1401,6 +1401,23 @@ static int gsc_ippdrv_check_property(struct device *dev,
bool swap;
int i;
 
+   config = >config[EXYNOS_DRM_OPS_DST];
+
+   /* check for degree */
+   switch (config->degree) {
+   case EXYNOS_DRM_DEGREE_90:
+   case EXYNOS_DRM_DEGREE_270:
+   swap = true;
+   break;
+   case EXYNOS_DRM_DEGREE_0:
+   case EXYNOS_DRM_DEGREE_180:
+   swap = false;
+   break;
+   default:
+   DRM_ERROR("invalid degree.\n");
+   goto err_property;
+   }
+
for_each_ipp_ops(i) {
if ((i == EXYNOS_DRM_OPS_SRC) &&
(property->cmd == IPP_CMD_WB))
@@ -1416,21 +1433,6 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
-   /* check for degree */
-   switch (config->degree) {
-   case EXYNOS_DRM_DEGREE_90:
-   case EXYNOS_DRM_DEGREE_270:
-   swap = true;
-   break;
-   case EXYNOS_DRM_DEGREE_0:
-   case EXYNOS_DRM_DEGREE_180:
-   swap = false;
-   break;
-   default:
-   DRM_ERROR("invalid degree.\n");
-   goto err_property;
-   }
-
/* check for buffer bound */
if ((pos->x + pos->w > sz->hsize) ||
(pos->y + pos->h > sz->vsize)) {
@@ -1438,21 +1440,27 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
+   /*
+* The rotation hardware limits are related to the cropped
+* source size. So use rot_max size to check the limits when
+* swap happens. And also the scaling limits are related to pos
+* size, use pos size to check the limits.
+*/
/* check for crop */
if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
if (swap) {
if ((pos->h < pp->crop_min.hsize) ||
-   (sz->vsize > pp->crop_max.hsize) ||
+   (pos->h > pp->rot_max.hsize) ||
(pos->w < pp->crop_min.vsize) ||
-   (sz->hsize > pp->crop_max.vsize)) {
+   (pos->w > pp->rot_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
} else {
if ((pos->w < pp->crop_min.hsize) ||
-   (sz->hsize > pp->crop_max.hsize) ||
+   (pos->w > pp->crop_max.hsize) ||
(pos->h < pp->crop_min.vsize) ||
-   (sz->vsize > pp->crop_max.vsize)) {
+   (pos->h > pp->crop_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
@@ -1463,17 +1471,17 @@ static int gsc_ippdrv_check_property(struct device *dev,
if ((i == EXYNOS_DRM_OPS_DST) && (pp->scale)) {
if (swap) {
if ((pos->h < pp->scale_min.hsize) ||
-   (sz->vsize > pp->scale_max.hsize) ||
+   (pos->h > pp->scale_max.hsize) ||
(pos->w < pp->scale_min.vsize) ||
-

[PATCH 2/3] arm64: dts: exynos: Add the hardware rotation limits for gsc

2017-08-31 Thread Hoegeun Kwon
The gscaler has maximum size of input or output rotation. Add the
hardware limits property for the gscaler rotation in the exynos5433
dts.

Signed-off-by: Hoegeun Kwon 
---
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 7fe994b..57c9997 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -891,6 +891,8 @@
 <_gscl CLK_ACLK_GSCL0>,
 <_gscl CLK_ACLK_XIU_GSCLX>,
 <_gscl CLK_ACLK_GSCLBEND_333>;
+   rot-max-hsize = <2047>;
+   rot-max-vsize = <2047>;
iommus = <_gscl0>;
};
 
@@ -904,6 +906,8 @@
 <_gscl CLK_ACLK_GSCL1>,
 <_gscl CLK_ACLK_XIU_GSCLX>,
 <_gscl CLK_ACLK_GSCLBEND_333>;
+   rot-max-hsize = <2047>;
+   rot-max-vsize = <2047>;
iommus = <_gscl1>;
};
 
@@ -917,6 +921,8 @@
 <_gscl CLK_ACLK_GSCL2>,
 <_gscl CLK_ACLK_XIU_GSCLX>,
 <_gscl CLK_ACLK_GSCLBEND_333>;
+   rot-max-hsize = <2047>;
+   rot-max-vsize = <2047>;
iommus = <_gscl2>;
};
 
-- 
1.9.1



Re: [PATCH v4 3/3] ARM: dts: exynos: Remove the display-timing and delay from rinato dts

2017-08-28 Thread Hoegeun Kwon

Hi Krzysztof,

The driver has been merged into exynos-drm-misc.
Could you please check this patch(3/3).

Best regards,
Hoegeun

On 07/13/2017 11:20 AM, Hoegeun Kwon wrote:

The display-timing and delay are included in the panel driver. So it
should be removed in dts.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
  arch/arm/boot/dts/exynos3250-rinato.dts | 22 --
  1 file changed, 22 deletions(-)

diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 443e0c9..6b70c8d 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -242,28 +242,6 @@
vci-supply = <_reg>;
reset-gpios = < 1 GPIO_ACTIVE_LOW>;
te-gpios = < 6 GPIO_ACTIVE_HIGH>;
-   power-on-delay= <30>;
-   power-off-delay= <120>;
-   reset-delay = <5>;
-   init-delay = <100>;
-   flip-horizontal;
-   flip-vertical;
-   panel-width-mm = <29>;
-   panel-height-mm = <29>;
-
-   display-timings {
-   timing-0 {
-   clock-frequency = <460>;
-   hactive = <320>;
-   vactive = <320>;
-   hfront-porch = <1>;
-   hback-porch = <1>;
-   hsync-len = <1>;
-   vfront-porch = <150>;
-   vback-porch = <1>;
-   vsync-len = <2>;
-   };
-   };
  
  		port {

dsi_in: endpoint {




Re: [PATCH v4 3/3] ARM: dts: exynos: Remove the display-timing and delay from rinato dts

2017-08-28 Thread Hoegeun Kwon

Hi Krzysztof,

The driver has been merged into exynos-drm-misc.
Could you please check this patch(3/3).

Best regards,
Hoegeun

On 07/13/2017 11:20 AM, Hoegeun Kwon wrote:

The display-timing and delay are included in the panel driver. So it
should be removed in dts.

Signed-off-by: Hoegeun Kwon 
---
  arch/arm/boot/dts/exynos3250-rinato.dts | 22 --
  1 file changed, 22 deletions(-)

diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 443e0c9..6b70c8d 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -242,28 +242,6 @@
vci-supply = <_reg>;
reset-gpios = < 1 GPIO_ACTIVE_LOW>;
te-gpios = < 6 GPIO_ACTIVE_HIGH>;
-   power-on-delay= <30>;
-   power-off-delay= <120>;
-   reset-delay = <5>;
-   init-delay = <100>;
-   flip-horizontal;
-   flip-vertical;
-   panel-width-mm = <29>;
-   panel-height-mm = <29>;
-
-   display-timings {
-   timing-0 {
-   clock-frequency = <460>;
-   hactive = <320>;
-   vactive = <320>;
-   hfront-porch = <1>;
-   hback-porch = <1>;
-   hsync-len = <1>;
-   vfront-porch = <150>;
-   vback-porch = <1>;
-   vsync-len = <2>;
-   };
-   };
  
  		port {

dsi_in: endpoint {




Re: [PATCH v4 0/3] Add support for the s6e63j0x03 panel on Rinato board

2017-07-31 Thread Hoegeun Kwon

Dear Thierry,

Could you please check these patches.

Best regards,
Hoegeun


On 07/13/2017 11:20 AM, Hoegeun Kwon wrote:

Hi Andrzej,

Thank you for your review.

The purpose of this patch is add support for s6e63j0x03 AMOLED panel
on the rinato board(Samsung Galaxy Gear 2).

Changes for V4:
- Added Reviewed-by: Andrzej Hajda <a.ha...@samsung.com> (2/3 patch).
- Fixed the style of macro function.

Changes for V3:
- Applied patch 'ARM: dts: exynos: Fix the active of reset gpios from rinato 
dts' (v2 3/4)
- Remove the unnecessary define ('MIN_BRIGHTNESS')
- Removed explicit casting.
- Removed violation of kernel coding style.

Changes for V2:
- Added the interface info in binding document.
- Added Reviewed-by: Andrzej Hajda <a.ha...@samsung.com> (1/3 patch).
- Added Acked-by: Rob Herring <r...@kernel.org> (1/3 patch).
- Fixed the tristate of config from video mode to command mode.
- Fixed the reset gpios from active high to low from rinato dts.
- Fixed a lot of things in panel driver, reflect Andrzej's review.

Best regards,
Hoegeun

Hoegeun Kwon (3):
   dt-bindings: Add support for samsung s6e63j0x03 panel binding
   drm/panel: Add support for s6e63j0x03 panel driver
   ARM: dts: exynos: Remove the display-timing and delay from rinato dts

  .../bindings/display/panel/samsung,s6e63j0x03.txt  |  24 +
  arch/arm/boot/dts/exynos3250-rinato.dts|  22 -
  drivers/gpu/drm/panel/Kconfig  |   7 +
  drivers/gpu/drm/panel/Makefile |   1 +
  drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c   | 532 +
  5 files changed, 564 insertions(+), 22 deletions(-)
  create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
  create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c





Re: [PATCH v4 0/3] Add support for the s6e63j0x03 panel on Rinato board

2017-07-31 Thread Hoegeun Kwon

Dear Thierry,

Could you please check these patches.

Best regards,
Hoegeun


On 07/13/2017 11:20 AM, Hoegeun Kwon wrote:

Hi Andrzej,

Thank you for your review.

The purpose of this patch is add support for s6e63j0x03 AMOLED panel
on the rinato board(Samsung Galaxy Gear 2).

Changes for V4:
- Added Reviewed-by: Andrzej Hajda  (2/3 patch).
- Fixed the style of macro function.

Changes for V3:
- Applied patch 'ARM: dts: exynos: Fix the active of reset gpios from rinato 
dts' (v2 3/4)
- Remove the unnecessary define ('MIN_BRIGHTNESS')
- Removed explicit casting.
- Removed violation of kernel coding style.

Changes for V2:
- Added the interface info in binding document.
- Added Reviewed-by: Andrzej Hajda  (1/3 patch).
- Added Acked-by: Rob Herring  (1/3 patch).
- Fixed the tristate of config from video mode to command mode.
- Fixed the reset gpios from active high to low from rinato dts.
- Fixed a lot of things in panel driver, reflect Andrzej's review.

Best regards,
Hoegeun

Hoegeun Kwon (3):
   dt-bindings: Add support for samsung s6e63j0x03 panel binding
   drm/panel: Add support for s6e63j0x03 panel driver
   ARM: dts: exynos: Remove the display-timing and delay from rinato dts

  .../bindings/display/panel/samsung,s6e63j0x03.txt  |  24 +
  arch/arm/boot/dts/exynos3250-rinato.dts|  22 -
  drivers/gpu/drm/panel/Kconfig  |   7 +
  drivers/gpu/drm/panel/Makefile |   1 +
  drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c   | 532 +
  5 files changed, 564 insertions(+), 22 deletions(-)
  create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
  create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c





[PATCH v4 2/3] drm/panel: Add support for s6e63j0x03 panel driver

2017-07-12 Thread Hoegeun Kwon
This patch adds MIPI-DSI based S6E63J0X03 AMOLED LCD panel driver
which uses mipi_dsi bus to communicate with panel. The panel has
320×320 resolution in 1.63" physical panel. This panel is used in
Samsung Galaxy Gear 2.

Signed-off-by: Inki Dae <inki@samsung.com>
Signed-off-by: Hyungwon Hwang <human.hw...@samsung.com>
Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
---
 drivers/gpu/drm/panel/Kconfig|   7 +
 drivers/gpu/drm/panel/Makefile   |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 532 +++
 3 files changed, 540 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index d84a031..bc69bca 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -80,6 +80,13 @@ config DRM_PANEL_SAMSUNG_S6E3HA2
depends on BACKLIGHT_CLASS_DEVICE
select VIDEOMODE_HELPERS
 
+config DRM_PANEL_SAMSUNG_S6E63J0X03
+   tristate "Samsung S6E63J0X03 DSI command mode panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   select VIDEOMODE_HELPERS
+
 config DRM_PANEL_SAMSUNG_S6E8AA0
tristate "Samsung S6E8AA0 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 9f6610d..42d2e29 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
+obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03) += panel-samsung-s6e63j0x03.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
new file mode 100644
index 000..aeb32aa
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
@@ -0,0 +1,532 @@
+/*
+ * MIPI-DSI based S6E63J0X03 AMOLED lcd 1.63 inch panel driver.
+ *
+ * Copyright (c) 2014-2017 Samsung Electronics Co., Ltd
+ *
+ * Inki Dae <inki@samsung.com>
+ * Hoegeun Kwon <hoegeun.k...@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MCS_LEVEL2_KEY 0xf0
+#define MCS_MTP_KEY0xf1
+#define MCS_MTP_SET3   0xd4
+
+#define MAX_BRIGHTNESS 100
+#define DEFAULT_BRIGHTNESS 80
+
+#define NUM_GAMMA_STEPS9
+#define GAMMA_CMD_CNT  28
+
+#define FIRST_COLUMN 20
+
+struct s6e63j0x03 {
+   struct device *dev;
+   struct drm_panel panel;
+   struct backlight_device *bl_dev;
+
+   struct regulator_bulk_data supplies[2];
+   struct gpio_desc *reset_gpio;
+};
+
+static const struct drm_display_mode default_mode = {
+   .clock = 4649,
+   .hdisplay = 320,
+   .hsync_start = 320 + 1,
+   .hsync_end = 320 + 1 + 1,
+   .htotal = 320 + 1 + 1 + 1,
+   .vdisplay = 320,
+   .vsync_start = 320 + 150,
+   .vsync_end = 320 + 150 + 1,
+   .vtotal = 320 + 150 + 1 + 2,
+   .vrefresh = 30,
+   .flags = 0,
+};
+
+static const unsigned char gamma_tbl[NUM_GAMMA_STEPS][GAMMA_CMD_CNT] = {
+   {   /* Gamma 10 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x7f, 0x7f, 0x7f, 0x52, 0x6b, 0x6f, 0x26,
+   0x28, 0x2d, 0x28, 0x26, 0x27, 0x33, 0x34, 0x32, 0x36, 0x36,
+   0x35, 0x00, 0xab, 0x00, 0xae, 0x00, 0xbf
+   },
+   {   /* gamma 30 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x70, 0x7f, 0x7f, 0x4e, 0x64, 0x69, 0x26,
+   0x27, 0x2a, 0x28, 0x29, 0x27, 0x31, 0x32, 0x31, 0x35, 0x34,
+   0x35, 0x00, 0xc4, 0x00, 0xca, 0x00, 0xdc
+   },
+   {   /* gamma 60 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x65, 0x7b, 0x7d, 0x5f, 0x67, 0x68, 0x2a,
+   0x28, 0x29, 0x28, 0x2a, 0x27, 0x31, 0x2f, 0x30, 0x34, 0x33,
+   0x34, 0x00, 0xd9, 0x00, 0xe4, 0x00, 0xf5
+   },
+   {   /* gamma 90 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x4d, 0x6f, 0x71, 0x67, 0x6a, 0x6c, 0x29,
+   0x28, 0x28, 0x28, 0x29, 0x27, 0x30, 0x2e, 0x30, 0x32, 0x31,
+   0x31, 0x00, 0xea, 0

[PATCH v4 2/3] drm/panel: Add support for s6e63j0x03 panel driver

2017-07-12 Thread Hoegeun Kwon
This patch adds MIPI-DSI based S6E63J0X03 AMOLED LCD panel driver
which uses mipi_dsi bus to communicate with panel. The panel has
320×320 resolution in 1.63" physical panel. This panel is used in
Samsung Galaxy Gear 2.

Signed-off-by: Inki Dae 
Signed-off-by: Hyungwon Hwang 
Signed-off-by: Hoegeun Kwon 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/panel/Kconfig|   7 +
 drivers/gpu/drm/panel/Makefile   |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 532 +++
 3 files changed, 540 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index d84a031..bc69bca 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -80,6 +80,13 @@ config DRM_PANEL_SAMSUNG_S6E3HA2
depends on BACKLIGHT_CLASS_DEVICE
select VIDEOMODE_HELPERS
 
+config DRM_PANEL_SAMSUNG_S6E63J0X03
+   tristate "Samsung S6E63J0X03 DSI command mode panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   select VIDEOMODE_HELPERS
+
 config DRM_PANEL_SAMSUNG_S6E8AA0
tristate "Samsung S6E8AA0 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 9f6610d..42d2e29 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
+obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03) += panel-samsung-s6e63j0x03.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
new file mode 100644
index 000..aeb32aa
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
@@ -0,0 +1,532 @@
+/*
+ * MIPI-DSI based S6E63J0X03 AMOLED lcd 1.63 inch panel driver.
+ *
+ * Copyright (c) 2014-2017 Samsung Electronics Co., Ltd
+ *
+ * Inki Dae 
+ * Hoegeun Kwon 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MCS_LEVEL2_KEY 0xf0
+#define MCS_MTP_KEY0xf1
+#define MCS_MTP_SET3   0xd4
+
+#define MAX_BRIGHTNESS 100
+#define DEFAULT_BRIGHTNESS 80
+
+#define NUM_GAMMA_STEPS9
+#define GAMMA_CMD_CNT  28
+
+#define FIRST_COLUMN 20
+
+struct s6e63j0x03 {
+   struct device *dev;
+   struct drm_panel panel;
+   struct backlight_device *bl_dev;
+
+   struct regulator_bulk_data supplies[2];
+   struct gpio_desc *reset_gpio;
+};
+
+static const struct drm_display_mode default_mode = {
+   .clock = 4649,
+   .hdisplay = 320,
+   .hsync_start = 320 + 1,
+   .hsync_end = 320 + 1 + 1,
+   .htotal = 320 + 1 + 1 + 1,
+   .vdisplay = 320,
+   .vsync_start = 320 + 150,
+   .vsync_end = 320 + 150 + 1,
+   .vtotal = 320 + 150 + 1 + 2,
+   .vrefresh = 30,
+   .flags = 0,
+};
+
+static const unsigned char gamma_tbl[NUM_GAMMA_STEPS][GAMMA_CMD_CNT] = {
+   {   /* Gamma 10 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x7f, 0x7f, 0x7f, 0x52, 0x6b, 0x6f, 0x26,
+   0x28, 0x2d, 0x28, 0x26, 0x27, 0x33, 0x34, 0x32, 0x36, 0x36,
+   0x35, 0x00, 0xab, 0x00, 0xae, 0x00, 0xbf
+   },
+   {   /* gamma 30 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x70, 0x7f, 0x7f, 0x4e, 0x64, 0x69, 0x26,
+   0x27, 0x2a, 0x28, 0x29, 0x27, 0x31, 0x32, 0x31, 0x35, 0x34,
+   0x35, 0x00, 0xc4, 0x00, 0xca, 0x00, 0xdc
+   },
+   {   /* gamma 60 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x65, 0x7b, 0x7d, 0x5f, 0x67, 0x68, 0x2a,
+   0x28, 0x29, 0x28, 0x2a, 0x27, 0x31, 0x2f, 0x30, 0x34, 0x33,
+   0x34, 0x00, 0xd9, 0x00, 0xe4, 0x00, 0xf5
+   },
+   {   /* gamma 90 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x4d, 0x6f, 0x71, 0x67, 0x6a, 0x6c, 0x29,
+   0x28, 0x28, 0x28, 0x29, 0x27, 0x30, 0x2e, 0x30, 0x32, 0x31,
+   0x31, 0x00, 0xea, 0x00, 0xf6, 0x01, 0x09
+   },
+   {   /* gamma 120 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x3d, 0x66, 0x68, 0x69, 0x69, 0x69, 0x28,
+  

[PATCH v4 1/3] dt-bindings: Add support for samsung s6e63j0x03 panel binding

2017-07-12 Thread Hoegeun Kwon
The Samsung s6e63j0x03 is a 1.63" 320x320 AMOLED panel connected using
MIPI-DSI interfaces.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
Acked-by: Rob Herring <r...@kernel.org>
---
 .../bindings/display/panel/samsung,s6e63j0x03.txt  | 24 ++
 1 file changed, 24 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt 
b/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
new file mode 100644
index 000..3f1a839
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
@@ -0,0 +1,24 @@
+Samsung S6E63J0X03 1.63" 320x320 AMOLED panel (interface: MIPI-DSI command 
mode)
+
+Required properties:
+  - compatible: "samsung,s6e63j0x03"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: I/O voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpios: a GPIO spec for the reset pin (active low)
+  - te-gpios: a GPIO spec for the tearing effect synchronization signal
+gpio pin (active high)
+
+Example:
+ {
+   ...
+
+   panel@0 {
+   compatible = "samsung,s6e63j0x03";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 1 GPIO_ACTIVE_LOW>;
+   te-gpios = < 6 GPIO_ACTIVE_HIGH>;
+   };
+};
-- 
1.9.1



[PATCH v4 1/3] dt-bindings: Add support for samsung s6e63j0x03 panel binding

2017-07-12 Thread Hoegeun Kwon
The Samsung s6e63j0x03 is a 1.63" 320x320 AMOLED panel connected using
MIPI-DSI interfaces.

Signed-off-by: Hoegeun Kwon 
Reviewed-by: Andrzej Hajda 
Acked-by: Rob Herring 
---
 .../bindings/display/panel/samsung,s6e63j0x03.txt  | 24 ++
 1 file changed, 24 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt 
b/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
new file mode 100644
index 000..3f1a839
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
@@ -0,0 +1,24 @@
+Samsung S6E63J0X03 1.63" 320x320 AMOLED panel (interface: MIPI-DSI command 
mode)
+
+Required properties:
+  - compatible: "samsung,s6e63j0x03"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: I/O voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpios: a GPIO spec for the reset pin (active low)
+  - te-gpios: a GPIO spec for the tearing effect synchronization signal
+gpio pin (active high)
+
+Example:
+ {
+   ...
+
+   panel@0 {
+   compatible = "samsung,s6e63j0x03";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 1 GPIO_ACTIVE_LOW>;
+   te-gpios = < 6 GPIO_ACTIVE_HIGH>;
+   };
+};
-- 
1.9.1



[PATCH v4 3/3] ARM: dts: exynos: Remove the display-timing and delay from rinato dts

2017-07-12 Thread Hoegeun Kwon
The display-timing and delay are included in the panel driver. So it
should be removed in dts.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
 arch/arm/boot/dts/exynos3250-rinato.dts | 22 --
 1 file changed, 22 deletions(-)

diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 443e0c9..6b70c8d 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -242,28 +242,6 @@
vci-supply = <_reg>;
reset-gpios = < 1 GPIO_ACTIVE_LOW>;
te-gpios = < 6 GPIO_ACTIVE_HIGH>;
-   power-on-delay= <30>;
-   power-off-delay= <120>;
-   reset-delay = <5>;
-   init-delay = <100>;
-   flip-horizontal;
-   flip-vertical;
-   panel-width-mm = <29>;
-   panel-height-mm = <29>;
-
-   display-timings {
-   timing-0 {
-   clock-frequency = <460>;
-   hactive = <320>;
-   vactive = <320>;
-   hfront-porch = <1>;
-   hback-porch = <1>;
-   hsync-len = <1>;
-   vfront-porch = <150>;
-   vback-porch = <1>;
-   vsync-len = <2>;
-   };
-   };
 
port {
dsi_in: endpoint {
-- 
1.9.1



[PATCH v4 3/3] ARM: dts: exynos: Remove the display-timing and delay from rinato dts

2017-07-12 Thread Hoegeun Kwon
The display-timing and delay are included in the panel driver. So it
should be removed in dts.

Signed-off-by: Hoegeun Kwon 
---
 arch/arm/boot/dts/exynos3250-rinato.dts | 22 --
 1 file changed, 22 deletions(-)

diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 443e0c9..6b70c8d 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -242,28 +242,6 @@
vci-supply = <_reg>;
reset-gpios = < 1 GPIO_ACTIVE_LOW>;
te-gpios = < 6 GPIO_ACTIVE_HIGH>;
-   power-on-delay= <30>;
-   power-off-delay= <120>;
-   reset-delay = <5>;
-   init-delay = <100>;
-   flip-horizontal;
-   flip-vertical;
-   panel-width-mm = <29>;
-   panel-height-mm = <29>;
-
-   display-timings {
-   timing-0 {
-   clock-frequency = <460>;
-   hactive = <320>;
-   vactive = <320>;
-   hfront-porch = <1>;
-   hback-porch = <1>;
-   hsync-len = <1>;
-   vfront-porch = <150>;
-   vback-porch = <1>;
-   vsync-len = <2>;
-   };
-   };
 
port {
dsi_in: endpoint {
-- 
1.9.1



[PATCH v4 0/3] Add support for the s6e63j0x03 panel on Rinato board

2017-07-12 Thread Hoegeun Kwon
Hi Andrzej,

Thank you for your review.

The purpose of this patch is add support for s6e63j0x03 AMOLED panel
on the rinato board(Samsung Galaxy Gear 2).

Changes for V4:
- Added Reviewed-by: Andrzej Hajda <a.ha...@samsung.com> (2/3 patch).
- Fixed the style of macro function.

Changes for V3:
- Applied patch 'ARM: dts: exynos: Fix the active of reset gpios from rinato 
dts' (v2 3/4)
- Remove the unnecessary define ('MIN_BRIGHTNESS')
- Removed explicit casting.
- Removed violation of kernel coding style.

Changes for V2:
- Added the interface info in binding document.
- Added Reviewed-by: Andrzej Hajda <a.ha...@samsung.com> (1/3 patch).
- Added Acked-by: Rob Herring <r...@kernel.org> (1/3 patch).
- Fixed the tristate of config from video mode to command mode.
- Fixed the reset gpios from active high to low from rinato dts.
- Fixed a lot of things in panel driver, reflect Andrzej's review.

Best regards,
Hoegeun

Hoegeun Kwon (3):
  dt-bindings: Add support for samsung s6e63j0x03 panel binding
  drm/panel: Add support for s6e63j0x03 panel driver
  ARM: dts: exynos: Remove the display-timing and delay from rinato dts

 .../bindings/display/panel/samsung,s6e63j0x03.txt  |  24 +
 arch/arm/boot/dts/exynos3250-rinato.dts|  22 -
 drivers/gpu/drm/panel/Kconfig  |   7 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c   | 532 +
 5 files changed, 564 insertions(+), 22 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c

-- 
1.9.1



[PATCH v4 0/3] Add support for the s6e63j0x03 panel on Rinato board

2017-07-12 Thread Hoegeun Kwon
Hi Andrzej,

Thank you for your review.

The purpose of this patch is add support for s6e63j0x03 AMOLED panel
on the rinato board(Samsung Galaxy Gear 2).

Changes for V4:
- Added Reviewed-by: Andrzej Hajda  (2/3 patch).
- Fixed the style of macro function.

Changes for V3:
- Applied patch 'ARM: dts: exynos: Fix the active of reset gpios from rinato 
dts' (v2 3/4)
- Remove the unnecessary define ('MIN_BRIGHTNESS')
- Removed explicit casting.
- Removed violation of kernel coding style.

Changes for V2:
- Added the interface info in binding document.
- Added Reviewed-by: Andrzej Hajda  (1/3 patch).
- Added Acked-by: Rob Herring  (1/3 patch).
- Fixed the tristate of config from video mode to command mode.
- Fixed the reset gpios from active high to low from rinato dts.
- Fixed a lot of things in panel driver, reflect Andrzej's review.

Best regards,
Hoegeun

Hoegeun Kwon (3):
  dt-bindings: Add support for samsung s6e63j0x03 panel binding
  drm/panel: Add support for s6e63j0x03 panel driver
  ARM: dts: exynos: Remove the display-timing and delay from rinato dts

 .../bindings/display/panel/samsung,s6e63j0x03.txt  |  24 +
 arch/arm/boot/dts/exynos3250-rinato.dts|  22 -
 drivers/gpu/drm/panel/Kconfig  |   7 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c   | 532 +
 5 files changed, 564 insertions(+), 22 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c

-- 
1.9.1



Re: [PATCH v2] ASoC: samsung: i2s: Support more resolution rates

2017-07-12 Thread Hoegeun Kwon

Hi Jaechul,

On 07/07/2017 10:31 AM, Jaechul Lee wrote:

This driver can support more frequencies over 96KHz. There are no reasons
to limit the frequency range below 96KHz. If codecs/amps or something else
can't support higher resolution rates, the constraints would be set rates
properly because each drivers have its own limits.

I added the 'pcm_rates' field to the dai_data to be set rates by the
compatibilities. As a result, rates will be set each devices respectively.
For example of exynos5433, rates will be set from 8KHz to 192KHz.

Signed-off-by: Jaechul Lee <jcsing@samsung.com>


Reviewed-by: Hoegeun Kwon <hoegeun.k...@samsung.com>

Best regards,
Hoegeun


---
v2:
  - changed the name of variable to pcm_rates.
  - removed duplicated code.
  - modified commit message.
---
  sound/soc/samsung/i2s.c | 20 +---
  1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index af3ba4d4ccc5..c9f87f7bae99 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -50,6 +50,7 @@ struct samsung_i2s_variant_regs {
  
  struct samsung_i2s_dai_data {

u32 quirks;
+   unsigned int pcm_rates;
const struct samsung_i2s_variant_regs *i2s_variant_regs;
  };
  
@@ -1076,13 +1077,13 @@ static const struct snd_soc_component_driver samsung_i2s_component = {

.name   = "samsung-i2s",
  };
  
-#define SAMSUNG_I2S_RATES	SNDRV_PCM_RATE_8000_96000

-
  #define SAMSUNG_I2S_FMTS  (SNDRV_PCM_FMTBIT_S8 | \
SNDRV_PCM_FMTBIT_S16_LE | \
SNDRV_PCM_FMTBIT_S24_LE)
  
-static struct i2s_dai *i2s_alloc_dai(struct platform_device *pdev, bool sec)

+static struct i2s_dai *i2s_alloc_dai(struct platform_device *pdev,
+   const struct samsung_i2s_dai_data *i2s_dai_data,
+   bool sec)
  {
struct i2s_dai *i2s;
  
@@ -1101,13 +1102,13 @@ static struct i2s_dai *i2s_alloc_dai(struct platform_device *pdev, bool sec)

i2s->i2s_dai_drv.resume = i2s_resume;
i2s->i2s_dai_drv.playback.channels_min = 1;
i2s->i2s_dai_drv.playback.channels_max = 2;
-   i2s->i2s_dai_drv.playback.rates = SAMSUNG_I2S_RATES;
+   i2s->i2s_dai_drv.playback.rates = i2s_dai_data->pcm_rates;
i2s->i2s_dai_drv.playback.formats = SAMSUNG_I2S_FMTS;
  
  	if (!sec) {

i2s->i2s_dai_drv.capture.channels_min = 1;
i2s->i2s_dai_drv.capture.channels_max = 2;
-   i2s->i2s_dai_drv.capture.rates = SAMSUNG_I2S_RATES;
+   i2s->i2s_dai_drv.capture.rates = i2s_dai_data->pcm_rates;
i2s->i2s_dai_drv.capture.formats = SAMSUNG_I2S_FMTS;
}
return i2s;
@@ -1242,7 +1243,7 @@ static int samsung_i2s_probe(struct platform_device *pdev)
i2s_dai_data = (struct samsung_i2s_dai_data *)
platform_get_device_id(pdev)->driver_data;
  
-	pri_dai = i2s_alloc_dai(pdev, false);

+   pri_dai = i2s_alloc_dai(pdev, i2s_dai_data, false);
if (!pri_dai) {
dev_err(>dev, "Unable to alloc I2S_pri\n");
return -ENOMEM;
@@ -1316,7 +1317,7 @@ static int samsung_i2s_probe(struct platform_device *pdev)
goto err_disable_clk;
  
  	if (quirks & QUIRK_SEC_DAI) {

-   sec_dai = i2s_alloc_dai(pdev, true);
+   sec_dai = i2s_alloc_dai(pdev, i2s_dai_data, true);
if (!sec_dai) {
dev_err(>dev, "Unable to alloc I2S_sec\n");
ret = -ENOMEM;
@@ -1452,29 +1453,34 @@ static const struct samsung_i2s_variant_regs 
i2sv5_i2s1_regs = {
  
  static const struct samsung_i2s_dai_data i2sv3_dai_type = {

.quirks = QUIRK_NO_MUXPSR,
+   .pcm_rates = SNDRV_PCM_RATE_8000_96000,
.i2s_variant_regs = _regs,
  };
  
  static const struct samsung_i2s_dai_data i2sv5_dai_type = {

.quirks = QUIRK_PRI_6CHAN | QUIRK_SEC_DAI | QUIRK_NEED_RSTCLR |
QUIRK_SUPPORTS_IDMA,
+   .pcm_rates = SNDRV_PCM_RATE_8000_96000,
.i2s_variant_regs = _regs,
  };
  
  static const struct samsung_i2s_dai_data i2sv6_dai_type = {

.quirks = QUIRK_PRI_6CHAN | QUIRK_SEC_DAI | QUIRK_NEED_RSTCLR |
QUIRK_SUPPORTS_TDM | QUIRK_SUPPORTS_IDMA,
+   .pcm_rates = SNDRV_PCM_RATE_8000_96000,
.i2s_variant_regs = _regs,
  };
  
  static const struct samsung_i2s_dai_data i2sv7_dai_type = {

.quirks = QUIRK_PRI_6CHAN | QUIRK_SEC_DAI | QUIRK_NEED_RSTCLR |
QUIRK_SUPPORTS_TDM,
+   .pcm_rates = SNDRV_PCM_RATE_8000_192000,
.i2s_variant_regs = _regs,
  };
  
  static const struct samsung_i2s_dai_data i2sv5_dai_type_i2s1 = {

.quirks = QUIRK_PRI_6CHAN | QUIRK_NEED_RSTCLR,
+   .pcm_rates = SNDRV_PCM_RATE_8000_96000,
.i2s_variant_regs = _i2s1_regs,
  };
  




Re: [PATCH v2] ASoC: samsung: i2s: Support more resolution rates

2017-07-12 Thread Hoegeun Kwon

Hi Jaechul,

On 07/07/2017 10:31 AM, Jaechul Lee wrote:

This driver can support more frequencies over 96KHz. There are no reasons
to limit the frequency range below 96KHz. If codecs/amps or something else
can't support higher resolution rates, the constraints would be set rates
properly because each drivers have its own limits.

I added the 'pcm_rates' field to the dai_data to be set rates by the
compatibilities. As a result, rates will be set each devices respectively.
For example of exynos5433, rates will be set from 8KHz to 192KHz.

Signed-off-by: Jaechul Lee 


Reviewed-by: Hoegeun Kwon 

Best regards,
Hoegeun


---
v2:
  - changed the name of variable to pcm_rates.
  - removed duplicated code.
  - modified commit message.
---
  sound/soc/samsung/i2s.c | 20 +---
  1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index af3ba4d4ccc5..c9f87f7bae99 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -50,6 +50,7 @@ struct samsung_i2s_variant_regs {
  
  struct samsung_i2s_dai_data {

u32 quirks;
+   unsigned int pcm_rates;
const struct samsung_i2s_variant_regs *i2s_variant_regs;
  };
  
@@ -1076,13 +1077,13 @@ static const struct snd_soc_component_driver samsung_i2s_component = {

.name   = "samsung-i2s",
  };
  
-#define SAMSUNG_I2S_RATES	SNDRV_PCM_RATE_8000_96000

-
  #define SAMSUNG_I2S_FMTS  (SNDRV_PCM_FMTBIT_S8 | \
SNDRV_PCM_FMTBIT_S16_LE | \
SNDRV_PCM_FMTBIT_S24_LE)
  
-static struct i2s_dai *i2s_alloc_dai(struct platform_device *pdev, bool sec)

+static struct i2s_dai *i2s_alloc_dai(struct platform_device *pdev,
+   const struct samsung_i2s_dai_data *i2s_dai_data,
+   bool sec)
  {
struct i2s_dai *i2s;
  
@@ -1101,13 +1102,13 @@ static struct i2s_dai *i2s_alloc_dai(struct platform_device *pdev, bool sec)

i2s->i2s_dai_drv.resume = i2s_resume;
i2s->i2s_dai_drv.playback.channels_min = 1;
i2s->i2s_dai_drv.playback.channels_max = 2;
-   i2s->i2s_dai_drv.playback.rates = SAMSUNG_I2S_RATES;
+   i2s->i2s_dai_drv.playback.rates = i2s_dai_data->pcm_rates;
i2s->i2s_dai_drv.playback.formats = SAMSUNG_I2S_FMTS;
  
  	if (!sec) {

i2s->i2s_dai_drv.capture.channels_min = 1;
i2s->i2s_dai_drv.capture.channels_max = 2;
-   i2s->i2s_dai_drv.capture.rates = SAMSUNG_I2S_RATES;
+   i2s->i2s_dai_drv.capture.rates = i2s_dai_data->pcm_rates;
i2s->i2s_dai_drv.capture.formats = SAMSUNG_I2S_FMTS;
}
return i2s;
@@ -1242,7 +1243,7 @@ static int samsung_i2s_probe(struct platform_device *pdev)
i2s_dai_data = (struct samsung_i2s_dai_data *)
platform_get_device_id(pdev)->driver_data;
  
-	pri_dai = i2s_alloc_dai(pdev, false);

+   pri_dai = i2s_alloc_dai(pdev, i2s_dai_data, false);
if (!pri_dai) {
dev_err(>dev, "Unable to alloc I2S_pri\n");
return -ENOMEM;
@@ -1316,7 +1317,7 @@ static int samsung_i2s_probe(struct platform_device *pdev)
goto err_disable_clk;
  
  	if (quirks & QUIRK_SEC_DAI) {

-   sec_dai = i2s_alloc_dai(pdev, true);
+   sec_dai = i2s_alloc_dai(pdev, i2s_dai_data, true);
if (!sec_dai) {
dev_err(>dev, "Unable to alloc I2S_sec\n");
ret = -ENOMEM;
@@ -1452,29 +1453,34 @@ static const struct samsung_i2s_variant_regs 
i2sv5_i2s1_regs = {
  
  static const struct samsung_i2s_dai_data i2sv3_dai_type = {

.quirks = QUIRK_NO_MUXPSR,
+   .pcm_rates = SNDRV_PCM_RATE_8000_96000,
.i2s_variant_regs = _regs,
  };
  
  static const struct samsung_i2s_dai_data i2sv5_dai_type = {

.quirks = QUIRK_PRI_6CHAN | QUIRK_SEC_DAI | QUIRK_NEED_RSTCLR |
QUIRK_SUPPORTS_IDMA,
+   .pcm_rates = SNDRV_PCM_RATE_8000_96000,
.i2s_variant_regs = _regs,
  };
  
  static const struct samsung_i2s_dai_data i2sv6_dai_type = {

.quirks = QUIRK_PRI_6CHAN | QUIRK_SEC_DAI | QUIRK_NEED_RSTCLR |
QUIRK_SUPPORTS_TDM | QUIRK_SUPPORTS_IDMA,
+   .pcm_rates = SNDRV_PCM_RATE_8000_96000,
.i2s_variant_regs = _regs,
  };
  
  static const struct samsung_i2s_dai_data i2sv7_dai_type = {

.quirks = QUIRK_PRI_6CHAN | QUIRK_SEC_DAI | QUIRK_NEED_RSTCLR |
QUIRK_SUPPORTS_TDM,
+   .pcm_rates = SNDRV_PCM_RATE_8000_192000,
.i2s_variant_regs = _regs,
  };
  
  static const struct samsung_i2s_dai_data i2sv5_dai_type_i2s1 = {

.quirks = QUIRK_PRI_6CHAN | QUIRK_NEED_RSTCLR,
+   .pcm_rates = SNDRV_PCM_RATE_8000_96000,
.i2s_variant_regs = _i2s1_regs,
  };
  




Re: [PATCH v3 2/3] drm/panel: Add support for s6e63j0x03 panel driver

2017-07-12 Thread Hoegeun Kwon

Hi Andrzej,

Could you please check this patch?

Best regards,
Hoegeun


On 06/27/2017 11:11 AM, Hoegeun Kwon wrote:

This patch adds MIPI-DSI based S6E63J0X03 AMOLED LCD panel driver
which uses mipi_dsi bus to communicate with panel. The panel has
320×320 resolution in 1.63" physical panel. This panel is used in
Samsung Galaxy Gear 2.

Signed-off-by: Inki Dae <inki@samsung.com>
Signed-off-by: Hyungwon Hwang <human.hw...@samsung.com>
Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---
  drivers/gpu/drm/panel/Kconfig|   7 +
  drivers/gpu/drm/panel/Makefile   |   1 +
  drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 540 +++
  3 files changed, 548 insertions(+)
  create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 3e29a99..3f4afde 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -68,6 +68,13 @@ config DRM_PANEL_SAMSUNG_S6E3HA2
depends on DRM_MIPI_DSI
select VIDEOMODE_HELPERS
  
+config DRM_PANEL_SAMSUNG_S6E63J0X03

+   tristate "Samsung S6E63J0X03 DSI command mode panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   select VIDEOMODE_HELPERS
+
  config DRM_PANEL_SAMSUNG_S6E8AA0
tristate "Samsung S6E8AA0 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 292b3c7..f028269 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
  obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
  obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
  obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
+obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03) += panel-samsung-s6e63j0x03.o
  obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
  obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
  obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
new file mode 100644
index 000..c3d1b5d
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
@@ -0,0 +1,540 @@
+/*
+ * MIPI-DSI based S6E63J0X03 AMOLED lcd 1.63 inch panel driver.
+ *
+ * Copyright (c) 2014-2017 Samsung Electronics Co., Ltd
+ *
+ * Inki Dae <inki@samsung.com>
+ * Hoegeun Kwon <hoegeun.k...@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MCS_LEVEL2_KEY 0xf0
+#define MCS_MTP_KEY0xf1
+#define MCS_MTP_SET3   0xd4
+
+#define MAX_BRIGHTNESS 100
+#define DEFAULT_BRIGHTNESS 80
+
+#define NUM_GAMMA_STEPS9
+#define GAMMA_CMD_CNT  28
+
+#define FIRST_COLUMN 20
+
+struct s6e63j0x03 {
+   struct device *dev;
+   struct drm_panel panel;
+   struct backlight_device *bl_dev;
+
+   struct regulator_bulk_data supplies[2];
+   struct gpio_desc *reset_gpio;
+};
+
+static const struct drm_display_mode default_mode = {
+   .clock = 4649,
+   .hdisplay = 320,
+   .hsync_start = 320 + 1,
+   .hsync_end = 320 + 1 + 1,
+   .htotal = 320 + 1 + 1 + 1,
+   .vdisplay = 320,
+   .vsync_start = 320 + 150,
+   .vsync_end = 320 + 150 + 1,
+   .vtotal = 320 + 150 + 1 + 2,
+   .vrefresh = 30,
+   .flags = 0,
+};
+
+static const unsigned char gamma_tbl[NUM_GAMMA_STEPS][GAMMA_CMD_CNT] = {
+   {   /* Gamma 10 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x7f, 0x7f, 0x7f, 0x52, 0x6b, 0x6f, 0x26,
+   0x28, 0x2d, 0x28, 0x26, 0x27, 0x33, 0x34, 0x32, 0x36, 0x36,
+   0x35, 0x00, 0xab, 0x00, 0xae, 0x00, 0xbf
+   },
+   {   /* gamma 30 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x70, 0x7f, 0x7f, 0x4e, 0x64, 0x69, 0x26,
+   0x27, 0x2a, 0x28, 0x29, 0x27, 0x31, 0x32, 0x31, 0x35, 0x34,
+   0x35, 0x00, 0xc4, 0x00, 0xca, 0x00, 0xdc
+   },
+   {   /* gamma 60 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x65, 0x7b, 0x7d, 0x5f, 0x67, 0x68, 0x2a,
+   0x28, 0x29, 0x28, 0x2a, 0x27, 0x31, 0x2f, 0x30, 0x34, 0x33,
+   0x34, 0x00, 0xd9, 0x00, 0xe4, 0x00, 0xf5
+   },
+   {   /* gamma 90 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x4d, 0x6f, 0x71, 0x67, 0x6a, 0x6c, 0x29,
+   0x28, 0x28, 0x28, 0x29, 0

Re: [PATCH v3 2/3] drm/panel: Add support for s6e63j0x03 panel driver

2017-07-12 Thread Hoegeun Kwon

Hi Andrzej,

Could you please check this patch?

Best regards,
Hoegeun


On 06/27/2017 11:11 AM, Hoegeun Kwon wrote:

This patch adds MIPI-DSI based S6E63J0X03 AMOLED LCD panel driver
which uses mipi_dsi bus to communicate with panel. The panel has
320×320 resolution in 1.63" physical panel. This panel is used in
Samsung Galaxy Gear 2.

Signed-off-by: Inki Dae 
Signed-off-by: Hyungwon Hwang 
Signed-off-by: Hoegeun Kwon 
---
  drivers/gpu/drm/panel/Kconfig|   7 +
  drivers/gpu/drm/panel/Makefile   |   1 +
  drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 540 +++
  3 files changed, 548 insertions(+)
  create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 3e29a99..3f4afde 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -68,6 +68,13 @@ config DRM_PANEL_SAMSUNG_S6E3HA2
depends on DRM_MIPI_DSI
select VIDEOMODE_HELPERS
  
+config DRM_PANEL_SAMSUNG_S6E63J0X03

+   tristate "Samsung S6E63J0X03 DSI command mode panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   select VIDEOMODE_HELPERS
+
  config DRM_PANEL_SAMSUNG_S6E8AA0
tristate "Samsung S6E8AA0 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 292b3c7..f028269 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
  obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
  obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
  obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
+obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03) += panel-samsung-s6e63j0x03.o
  obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
  obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
  obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
new file mode 100644
index 000..c3d1b5d
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
@@ -0,0 +1,540 @@
+/*
+ * MIPI-DSI based S6E63J0X03 AMOLED lcd 1.63 inch panel driver.
+ *
+ * Copyright (c) 2014-2017 Samsung Electronics Co., Ltd
+ *
+ * Inki Dae 
+ * Hoegeun Kwon 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MCS_LEVEL2_KEY 0xf0
+#define MCS_MTP_KEY0xf1
+#define MCS_MTP_SET3   0xd4
+
+#define MAX_BRIGHTNESS 100
+#define DEFAULT_BRIGHTNESS 80
+
+#define NUM_GAMMA_STEPS9
+#define GAMMA_CMD_CNT  28
+
+#define FIRST_COLUMN 20
+
+struct s6e63j0x03 {
+   struct device *dev;
+   struct drm_panel panel;
+   struct backlight_device *bl_dev;
+
+   struct regulator_bulk_data supplies[2];
+   struct gpio_desc *reset_gpio;
+};
+
+static const struct drm_display_mode default_mode = {
+   .clock = 4649,
+   .hdisplay = 320,
+   .hsync_start = 320 + 1,
+   .hsync_end = 320 + 1 + 1,
+   .htotal = 320 + 1 + 1 + 1,
+   .vdisplay = 320,
+   .vsync_start = 320 + 150,
+   .vsync_end = 320 + 150 + 1,
+   .vtotal = 320 + 150 + 1 + 2,
+   .vrefresh = 30,
+   .flags = 0,
+};
+
+static const unsigned char gamma_tbl[NUM_GAMMA_STEPS][GAMMA_CMD_CNT] = {
+   {   /* Gamma 10 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x7f, 0x7f, 0x7f, 0x52, 0x6b, 0x6f, 0x26,
+   0x28, 0x2d, 0x28, 0x26, 0x27, 0x33, 0x34, 0x32, 0x36, 0x36,
+   0x35, 0x00, 0xab, 0x00, 0xae, 0x00, 0xbf
+   },
+   {   /* gamma 30 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x70, 0x7f, 0x7f, 0x4e, 0x64, 0x69, 0x26,
+   0x27, 0x2a, 0x28, 0x29, 0x27, 0x31, 0x32, 0x31, 0x35, 0x34,
+   0x35, 0x00, 0xc4, 0x00, 0xca, 0x00, 0xdc
+   },
+   {   /* gamma 60 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x65, 0x7b, 0x7d, 0x5f, 0x67, 0x68, 0x2a,
+   0x28, 0x29, 0x28, 0x2a, 0x27, 0x31, 0x2f, 0x30, 0x34, 0x33,
+   0x34, 0x00, 0xd9, 0x00, 0xe4, 0x00, 0xf5
+   },
+   {   /* gamma 90 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x4d, 0x6f, 0x71, 0x67, 0x6a, 0x6c, 0x29,
+   0x28, 0x28, 0x28, 0x29, 0x27, 0x30, 0x2e, 0x30, 0x32, 0x31,
+   0x31, 0x00, 0xea, 0x00, 0xf6, 0x01, 0x09
+   },
+   {   /* gamma 120 */
+  

Re: [PATCH v4] drm/exynos/dsi: Remove error handling for bridge_node DT parsing

2017-07-05 Thread Hoegeun Kwon

Hi Inki,

Could you check this patch? :D

Best regards,
Hoegeun

On 06/21/2017 07:51 PM, Hoegeun Kwon wrote:

Remove the error handling of bridge_node because the bridge_node is
optional.

For example, In case of Exynos SoC, a bridge device such as mDNIe and
MIC could be placed between Display Controller and MIPI DSI device but
the bridge device is optional.

Signed-off-by: Hoegeun Kwon <hoegeun.k...@samsung.com>
---

Hi all,

Thanks for Krzysztof's advice.

Changes for V4:
- Fixed the word('optional') from commit message.

Changes for V3:
- Removed the word('required') from commit message.

Changes for V2:
- Modified the commit message in more detail than before.

Best regards,
Hoegeun

  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 --
  1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index a11b795..6ee0dac 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1651,8 +1651,6 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
return ret;
  
  	dsi->bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);

-   if (!dsi->bridge_node)
-   return -EINVAL;
  
  	return 0;

  }




Re: [PATCH v4] drm/exynos/dsi: Remove error handling for bridge_node DT parsing

2017-07-05 Thread Hoegeun Kwon

Hi Inki,

Could you check this patch? :D

Best regards,
Hoegeun

On 06/21/2017 07:51 PM, Hoegeun Kwon wrote:

Remove the error handling of bridge_node because the bridge_node is
optional.

For example, In case of Exynos SoC, a bridge device such as mDNIe and
MIC could be placed between Display Controller and MIPI DSI device but
the bridge device is optional.

Signed-off-by: Hoegeun Kwon 
---

Hi all,

Thanks for Krzysztof's advice.

Changes for V4:
- Fixed the word('optional') from commit message.

Changes for V3:
- Removed the word('required') from commit message.

Changes for V2:
- Modified the commit message in more detail than before.

Best regards,
Hoegeun

  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 --
  1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index a11b795..6ee0dac 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1651,8 +1651,6 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
return ret;
  
  	dsi->bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);

-   if (!dsi->bridge_node)
-   return -EINVAL;
  
  	return 0;

  }




  1   2   3   4   >