[PATCH v2] ARM: dts: da850: add the mstpri and ddrctl nodes

[David Lechner]

On 11/15/2016 05:00 AM, Bartosz Golaszewski wrote:
> Add the nodes for the MSTPRI configuration and DDR2/mDDR memory
> controller drivers to da850.dtsi.
>
> Signed-off-by: Bartosz Golaszewski 
> ---
> v1 -> v2:
> - moved the priority controller node above the cfgchip node
> - renamed added nodes to better reflect their purpose
>
>  arch/arm/boot/dts/da850.dtsi | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index 1bb1f6d..412eec6 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -210,6 +210,10 @@
>   };
>
>   };
> + prictrl: priority-controller at 14110 {
> + compatible = "ti,da850-mstpri";
> + reg = <0x14110 0x0c>;

I think we should add status = "disabled"; here and let boards opt in.

> + };
>   cfgchip: chip-controller at 1417c {
>   compatible = "ti,da830-cfgchip", "syscon", "simple-mfd";
>   reg = <0x1417c 0x14>;
> @@ -451,4 +455,8 @@
> 1 0 0x6800 0x8000>;
>   status = "disabled";
>   };
> + memctrl: memory-controller at b000 {
> + compatible = "ti,da850-ddr-controller";
> + reg = <0xb000 0xe8>;

same here. status = "disabled";

> + };
>  };
>

[PATCH v2] ARM: dts: da850: add the mstpri and ddrctl nodes

[David Lechner]

On 11/23/2016 04:27 AM, Bartosz Golaszewski wrote:
> 2016-11-22 23:23 GMT+01:00 David Lechner :
>> On 11/15/2016 05:00 AM, Bartosz Golaszewski wrote:
>>>
>>> Add the nodes for the MSTPRI configuration and DDR2/mDDR memory
>>> controller drivers to da850.dtsi.
>>>
>>> Signed-off-by: Bartosz Golaszewski 
>>> ---
>>> v1 -> v2:
>>> - moved the priority controller node above the cfgchip node
>>> - renamed added nodes to better reflect their purpose
>>>
>>>  arch/arm/boot/dts/da850.dtsi | 8 
>>>  1 file changed, 8 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>> index 1bb1f6d..412eec6 100644
>>> --- a/arch/arm/boot/dts/da850.dtsi
>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>> @@ -210,6 +210,10 @@
>>> };
>>>
>>> };
>>> +   prictrl: priority-controller at 14110 {
>>> +   compatible = "ti,da850-mstpri";
>>> +   reg = <0x14110 0x0c>;
>>
>>
>> I think we should add status = "disabled"; here and let boards opt in.
>>
>>> +   };
>>> cfgchip: chip-controller at 1417c {
>>> compatible = "ti,da830-cfgchip", "syscon",
>>> "simple-mfd";
>>> reg = <0x1417c 0x14>;
>>> @@ -451,4 +455,8 @@
>>>   1 0 0x6800 0x8000>;
>>> status = "disabled";
>>> };
>>> +   memctrl: memory-controller at b000 {
>>> +   compatible = "ti,da850-ddr-controller";
>>> +   reg = <0xb000 0xe8>;
>>
>>
>> same here. status = "disabled";
>>
>>> +   };
>>>  };
>>>
>
> Hi David,
>
> I did that initially[1][2] and it was rejected by Kevin[3] and Laurent[4].
>
> FYI this patch has already been queued by Sekhar.

Thanks. I did not see those threads.

FYI to maintainers, having these enabled by default causes error 
messages in the kernel log for other boards that are not supported by 
the drivers. Since there is only one board that is supported and soon to 
be 2 that are not, I would rather have this disabled by default to avoid 
the error messages.

>
> Best regards,
> Bartosz Golaszewski
>
> [1] https://www.spinics.net/lists/arm-kernel/msg539638.html
> [2] http://www.spinics.net/lists/devicetree/msg148575.html
> [3] http://www.spinics.net/lists/devicetree/msg148667.html
> [4] http://www.spinics.net/lists/devicetree/msg148655.html
>

[PATCH v2] ARM: dts: da850: add the mstpri and ddrctl nodes

[David Lechner]

On 11/23/2016 04:32 PM, Kevin Hilman wrote:
> David Lechner  writes:
>
>> On 11/23/2016 04:27 AM, Bartosz Golaszewski wrote:
>>> 2016-11-22 23:23 GMT+01:00 David Lechner :
>>>> On 11/15/2016 05:00 AM, Bartosz Golaszewski wrote:
>>>>>
>>>>> Add the nodes for the MSTPRI configuration and DDR2/mDDR memory
>>>>> controller drivers to da850.dtsi.
>>>>>
>>>>> Signed-off-by: Bartosz Golaszewski 
>>>>> ---
>>>>> v1 -> v2:
>>>>> - moved the priority controller node above the cfgchip node
>>>>> - renamed added nodes to better reflect their purpose
>>>>>
>>>>>  arch/arm/boot/dts/da850.dtsi | 8 
>>>>>  1 file changed, 8 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>>>> index 1bb1f6d..412eec6 100644
>>>>> --- a/arch/arm/boot/dts/da850.dtsi
>>>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>>>> @@ -210,6 +210,10 @@
>>>>> };
>>>>>
>>>>> };
>>>>> +   prictrl: priority-controller at 14110 {
>>>>> +   compatible = "ti,da850-mstpri";
>>>>> +   reg = <0x14110 0x0c>;
>>>>
>>>>
>>>> I think we should add status = "disabled"; here and let boards opt in.
>>>>
>>>>> +   };
>>>>> cfgchip: chip-controller at 1417c {
>>>>> compatible = "ti,da830-cfgchip", "syscon",
>>>>> "simple-mfd";
>>>>> reg = <0x1417c 0x14>;
>>>>> @@ -451,4 +455,8 @@
>>>>>   1 0 0x6800 0x8000>;
>>>>> status = "disabled";
>>>>> };
>>>>> +   memctrl: memory-controller at b000 {
>>>>> +   compatible = "ti,da850-ddr-controller";
>>>>> +   reg = <0xb000 0xe8>;
>>>>
>>>>
>>>> same here. status = "disabled";
>>>>
>>>>> +   };
>>>>>  };
>>>>>
>>>
>>> Hi David,
>>>
>>> I did that initially[1][2] and it was rejected by Kevin[3] and Laurent[4].
>>>
>>> FYI this patch has already been queued by Sekhar.
>>
>> Thanks. I did not see those threads.
>>
>> FYI to maintainers, having these enabled by default causes error
>> messages in the kernel log for other boards that are not supported by
>> the drivers.
>
> Then the driver is too noisy and should be cleaned up.
>
>> Since there is only one board that is supported and soon
>> to be 2 that are not, I would rather have this disabled by default to
>> avoid the error messages.
>
> IMO, what exactly are the error messages? Sounds like the driver is
> being too verbose, and calling things errors that are not really errors.

It is just one line per driver.

dev_err(dev, "no master priorities defined for this board\n");

and

dev_err(dev, "no settings defined for this board\n");


Since "ti,da850-lcdk" is the only board supported in these drivers, all 
other boards will see these error messages.

Also, these modules will be loaded and taking up memory on boards that 
don't use them. This not really a big deal and they can be explicitly 
disabled, so maybe it was not worth mentioning.


>
> Kevin
>

[PATCH v2] drm/fb-helper: pass physical dimensions to fbdev

[David Lechner]

The fbdev subsystem has a place for physical dimensions (width and height
in mm) that is readable by userspace. Since DRM also knows these
dimensions, pass this information to the fbdev device.

Signed-off-by: David Lechner <da...@lechnology.com>
---

v1 changes (from RFC):
* Use loop to get info from first connected connector instead of just the
  first connector.

v2 changes:
* Update width in height in drm_setup_crtcs() also to handle hotplug events.


As mentioned in the comments below, drm_setup_crtcs() can't set these values
during init because the data structure hasn't been allocated yet, so we end up
doing the same thing in two different places.


 drivers/gpu/drm/drm_fb_helper.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index b2a01d1..7813b86 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1884,6 +1884,7 @@ void drm_fb_helper_fill_var(struct fb_info *info, struct 
drm_fb_helper *fb_helpe
uint32_t fb_width, uint32_t fb_height)
 {
struct drm_framebuffer *fb = fb_helper->fb;
+   int i;
 
info->pseudo_palette = fb_helper->pseudo_palette;
info->var.xres_virtual = fb->width;
@@ -1896,6 +1897,18 @@ void drm_fb_helper_fill_var(struct fb_info *info, struct 
drm_fb_helper *fb_helpe
info->var.height = -1;
info->var.width = -1;
 
+   drm_fb_helper_for_each_connector(fb_helper, i) {
+   struct drm_connector *connector =
+   fb_helper->connector_info[i]->connector;
+
+   /* use the first connected connector for the physical 
dimensions */
+   if (connector->status == connector_status_connected) {
+   info->var.height = connector->display_info.width_mm;
+   info->var.width = connector->display_info.height_mm;
+   break;
+   }
+   }
+
switch (fb->format->depth) {
case 8:
info->var.red.offset = 0;
@@ -2355,6 +2368,7 @@ static void drm_setup_crtcs(struct drm_fb_helper 
*fb_helper,
struct drm_display_mode **modes;
struct drm_fb_offset *offsets;
bool *enabled;
+   bool var_updated = false;
int i;
 
DRM_DEBUG_KMS("\n");
@@ -2429,6 +2443,23 @@ static void drm_setup_crtcs(struct drm_fb_helper 
*fb_helper,
modeset->fb = fb_helper->fb;
modeset->x = offset->x;
modeset->y = offset->y;
+
+   /*
+* During init, drm_setup_crtcs() is called before the
+* fbdev is allocated, so this only affects hotplug
+* events.
+* Only the info from the first connected connector is
+* used.
+*/
+   if (!var_updated && fb_helper->fbdev &&
+   connector->status == connector_status_connected) {
+   struct fb_var_screeninfo *var =
+   _helper->fbdev->var;
+
+   var->width = connector->display_info.width_mm;
+   var->height = connector->display_info.height_mm;
+   var_updated = true;
+   }
}
}
 out:
-- 
2.7.4

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

Re: [PATCH] drm/fb-helper: pass physical dimensions to fbdev

[David Lechner]

On 08/02/2017 06:28 PM, Daniel Vetter wrote:

On Wed, Aug 2, 2017 at 6:37 PM, David Lechner <da...@lechnology.com> wrote:

On 08/02/2017 04:46 AM, Daniel Vetter wrote:


On Tue, Aug 01, 2017 at 10:26:41AM -0500, David Lechner wrote:


The fbdev subsystem has a place for physical dimensions (width and height
in mm) that is readable by userspace. Since DRM also knows these
dimensions, pass this information to the fbdev device.

Signed-off-by: David Lechner <da...@lechnology.com>



Still in the wrong function. Also please add some notation about what you
changed when resubmitting a patch (it took me a while to remember that I
replied to you already). That makes patch reviewing more efficient.



Sorry for being so dense. :-/

I did read your first reply at least 10 times. All of the terminology is
foreign to me, but after sleeping on it a few days, I think it is slowly
soaking into my brain.


No problem, the code is fairly convoluted. One more question on your
v3: From reading fbdev code I don't see any place that overwrites the
physical dimensions except the fill_var helper function (which is
called deep down from register_framebuffer). If we entirely remove the
var.width/height assignments from that (including the -1 default) and
move all of it into setup_crtcs, would that work?



I tried that, but in my case, drm_setup_crtcs() is only called once 
before the fbdev is allocated. So, I got a kernel oops from 
dereferencing a null pointer, which is why there is a null check for 
fb_helper->fbdev as part of the if statement I added there. Since 
drm_setup_crtcs() is not called again, the var.width and height are 
never set.


I also noticed that there is another similar workaround/code duplication 
for the framebuffer not being allocated in the first call to 
drm_setup_crtcs() seen at the end of drm_fb_helper_single_fb_probe().




I kinda don't like have the same logic in 2 completely different
places, once for driver load and once for hotplug handling. That tends
to cause bugs (because then no one bothers to test hotplug handling or
the boot-up case properly).



Would it be possible to split drm_setup_crtcs() into two functions, a 
top half and a bottom half. During init (pseudo-code)...


drm_begin_setup_crtcs()
drm_fb_helper_single_fb_probe()
drm_finish_setup_crtcs()

and during hotplug event, just...

drm_begin_setup_crtcs()
drm_finish_crtcs_bottom_half()

I think it could solve both cases.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 2/2] drm/fb-helper: pass physical dimensions to fbdev

[David Lechner]

The fbdev subsystem has a place for physical dimensions (width and height
in mm) that is readable by userspace. Since DRM also knows these
dimensions, pass this information to the fbdev device.

This has to be done in drm_setup_crtcs_fb() instead of drm_setup_crtcs()
because fb_helper->fbdev may be NULL in drm_setup_crtcs().

Signed-off-by: David Lechner <da...@lechnology.com>
---
 drivers/gpu/drm/drm_fb_helper.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 24a721a..a98bf86 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1882,8 +1882,6 @@ void drm_fb_helper_fill_var(struct fb_info *info, struct 
drm_fb_helper *fb_helpe
info->var.xoffset = 0;
info->var.yoffset = 0;
info->var.activate = FB_ACTIVATE_NOW;
-   info->var.height = -1;
-   info->var.width = -1;
 
switch (fb->format->depth) {
case 8:
@@ -2435,11 +2433,24 @@ static void drm_setup_crtcs(struct drm_fb_helper 
*fb_helper,
  */
 static void drm_setup_crtcs_fb(struct drm_fb_helper *fb_helper)
 {
+   struct fb_info *info = fb_helper->fbdev;
int i;
 
for (i = 0; i < fb_helper->crtc_count; i++)
if (fb_helper->crtc_info[i].mode_set.num_connectors)
fb_helper->crtc_info[i].mode_set.fb = fb_helper->fb;
+
+   drm_fb_helper_for_each_connector(fb_helper, i) {
+   struct drm_connector *connector =
+   fb_helper->connector_info[i]->connector;
+
+   /* use first connected connector for the physical dimensions */
+   if (connector->status == connector_status_connected) {
+   info->var.height = connector->display_info.width_mm;
+   info->var.width = connector->display_info.height_mm;
+   break;
+   }
+   }
 }
 
 /* Note: Drops fb_helper->lock before returning. */
-- 
2.7.4

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

[PATCH v3 0/2] drm/fb-helper: pass physical dimensions to fbdev

[David Lechner]

v1 changes (from RFC):
* Use loop to get info from first connected connector instead of just the
  first connector.

v2 changes:
* Update width in height in drm_setup_crtcs() also to handle hotplug events.

v3 changes:
* Add new patch to handle post-fb allocation crcts setup.
* Use new drm_setup_crtcs_fb() function from new patch to avoid duplication
  of code.

David Lechner (2):
  drm/fb-helper: add new drm_setup_crtcs_fb() function
  drm/fb-helper: pass physical dimensions to fbdev

 drivers/gpu/drm/drm_fb_helper.c | 45 -
 1 file changed, 31 insertions(+), 14 deletions(-)

-- 
2.7.4

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

[PATCH v3 1/2] drm/fb-helper: add new drm_setup_crtcs_fb() function

[David Lechner]

This adds a new drm_setup_crtcs_fb() function to handle the parts of
drm_setup_crtcs() that touch fb_helper->fb and fb_helper->fbdev. When
drm_setup_crtcs() is called during initialization, these fields are NULL
because they have not been allocated yet.

There is currently a hack at the end of drm_fb_helper_single_fb_probe()
that sets fb_helper->fb, so it is moved to the new drm_setup_crtcs_fb()
function.

This is also done in preparation for addition setup that requires access
to fb_helper->fbdev.

Signed-off-by: David Lechner <da...@lechnology.com>
---
 drivers/gpu/drm/drm_fb_helper.c | 30 ++
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index b2a01d1..24a721a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1821,17 +1821,6 @@ static int drm_fb_helper_single_fb_probe(struct 
drm_fb_helper *fb_helper,
if (ret < 0)
return ret;
 
-   /*
-* Set the fb pointer - usually drm_setup_crtcs does this for hotplug
-* events, but at init time drm_setup_crtcs needs to be called before
-* the fb is allocated (since we need to figure out the desired size of
-* the fb before we can allocate it ...). Hence we need to fix things up
-* here again.
-*/
-   for (i = 0; i < fb_helper->crtc_count; i++)
-   if (fb_helper->crtc_info[i].mode_set.num_connectors)
-   fb_helper->crtc_info[i].mode_set.fb = fb_helper->fb;
-
return 0;
 }
 
@@ -2426,7 +2415,6 @@ static void drm_setup_crtcs(struct drm_fb_helper 
*fb_helper,
   
fb_crtc->desired_mode);
drm_connector_get(connector);
modeset->connectors[modeset->num_connectors++] = 
connector;
-   modeset->fb = fb_helper->fb;
modeset->x = offset->x;
modeset->y = offset->y;
}
@@ -2438,6 +2426,22 @@ static void drm_setup_crtcs(struct drm_fb_helper 
*fb_helper,
kfree(enabled);
 }
 
+/*
+ * This is a continuation of drm_setup_crtcs() that sets up anything related
+ * to the framebuffer. During initialization, drm_setup_crtcs() is called 
before
+ * the framebuffer has been allocated (fb_helper->fb and fb_helper->fbdev).
+ * So, any setup that touches those fields needs to be done here instead of in
+ * drm_setup_crtcs().
+ */
+static void drm_setup_crtcs_fb(struct drm_fb_helper *fb_helper)
+{
+   int i;
+
+   for (i = 0; i < fb_helper->crtc_count; i++)
+   if (fb_helper->crtc_info[i].mode_set.num_connectors)
+   fb_helper->crtc_info[i].mode_set.fb = fb_helper->fb;
+}
+
 /* Note: Drops fb_helper->lock before returning. */
 static int
 __drm_fb_helper_initial_config_and_unlock(struct drm_fb_helper *fb_helper,
@@ -2463,6 +2467,7 @@ __drm_fb_helper_initial_config_and_unlock(struct 
drm_fb_helper *fb_helper,
 
return ret;
}
+   drm_setup_crtcs_fb(fb_helper);
 
fb_helper->deferred_setup = false;
 
@@ -2591,6 +2596,7 @@ int drm_fb_helper_hotplug_event(struct drm_fb_helper 
*fb_helper)
DRM_DEBUG_KMS("\n");
 
drm_setup_crtcs(fb_helper, fb_helper->fb->width, fb_helper->fb->height);
+   drm_setup_crtcs_fb(fb_helper);
mutex_unlock(_helper->lock);
 
drm_fb_helper_set_par(fb_helper->fbdev);
-- 
2.7.4

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

Re: Monochrome/greyscale and software dithering in the kernel

[David Lechner]

On 08/03/2017 09:58 AM, Noralf Trønnes wrote:

Hi,

The tinydrm/repaper driver is monochrome, but I have just used an
emulation format XRGB, since monochrome support is scarce in
userspace. I'm using ITU BT.601 to convert from rgb to greyscale and
then use the msb for monochrome.

Now I'm asked if we can implement Floyd–Steinberg dithering in the driver
to make it more useful, so userspace can work reasonably well with
default tools/libs. I did have that in the first stage of the driver
development, but decided against it, since I figured this was the
responsibility of userspace not the kernel. But personally it doesn't
really matter to me either way.

So the question is, can I say yes to such an addition?



IMHO, if we add monochorme/grayscale support to DRM, then I think using 
dithering for the "compatibility mode" XRGB emulation would be a 
good idea. But until then, I don't think I would like it because unless 
you are displaying photos it will probably causes some noticeable 
distortion.

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

Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display

[David Lechner]

On 08/03/2017 09:07 AM, Noralf Trønnes wrote:


Den 02.08.2017 00.26, skrev David Lechner:

On 08/01/2017 01:08 PM, Noralf Trønnes wrote:

(cc: Daniel Vetter)


Den 01.08.2017 18.51, skrev David Lechner:

On 07/30/2017 12:14 PM, Noralf Trønnes wrote:


Den 29.07.2017 21.40, skrev David Lechner:

On 07/29/2017 02:17 PM, David Lechner wrote:
The goal of this series is to get the built-in LCD of the LEGO 
MINDSTORMS EV3
working. But, most of the content here is building up the 
infrastructure to do

that.



Some general comments/questions:

I have noticed that DRM doesn't really have support for monochrome 
displays. I'm guessing that is because no one really uses them 
anymore?




The repaper driver was the first monochrome drm driver and I chose to
present it to userspace as XRGB and convert it to monochrome.
The reason for this is that everything, libraries, apps, plymouth 
(boot

splash, no rgb565) supports it. I didn't see any point in adding a new
monochrome drm format that didn't have, or probably wouldn't get
userspace support (by libraries at least). The application of course
needs to know this to get a good result.

tinydrm_xrgb_to_gray8() does the conversion:
https://cgit.freedesktop.org/drm/drm-misc/commit/drivers/gpu/drm/tinydrm?id=379ea9a1a59a5a32c8db6f164e80a3fd00cb3781 



The LEGO EV3 display is just an LCD (not the backlit kind). It has 
two modes of operation. It can to 2bbp grayscale or it can do 1bpp 
monochrome. The grayscale isn't the best (looks splotchy in 
places), so it would be nice to be able to choose between these 
two modes. How would I implement something like that?




Do you expect anyone to use grayscale if it doesn't look good?
Maybe better to add it later if there's a demand for it.


I don't expect many people to use it at all. The people that do will 
be hackers like me that want to see what it is capable of, so I 
think I will keep it grayscale by default.




It looks like the best way to satisfy your needs is to add specific 
formats.


Video for Linux have these:

include/uapi/linux/videodev2.h

/* Grey formats */
#define V4L2_PIX_FMT_GREYv4l2_fourcc('G', 'R', 'E', 'Y') /* 8 
Greyscale */
#define V4L2_PIX_FMT_Y4  v4l2_fourcc('Y', '0', '4', ' ') /* 4 
Greyscale */
#define V4L2_PIX_FMT_Y6  v4l2_fourcc('Y', '0', '6', ' ') /* 6 
Greyscale */
#define V4L2_PIX_FMT_Y10 v4l2_fourcc('Y', '1', '0', ' ') /* 10 
Greyscale */
#define V4L2_PIX_FMT_Y12 v4l2_fourcc('Y', '1', '2', ' ') /* 12 
Greyscale */
#define V4L2_PIX_FMT_Y16 v4l2_fourcc('Y', '1', '6', ' ') /* 16 
Greyscale */
#define V4L2_PIX_FMT_Y16_BE  v4l2_fourcc_be('Y', '1', '6', ' ') /* 16 
Greyscale BE  */



Maybe we can add formats like these:

include/uapi/drm/drm_fourcc.h

#define DRM_FORMAT_MONOfourcc_code('Y', '0', '1', ' ') /* [0] 
Monochrome */

or
#define DRM_FORMAT_Y1fourcc_code('Y', '0', '1', ' ') /* [0] 
Monochrome */


#define DRM_FORMAT_Y2fourcc_code('Y', '0', '2', ' ') /* [1:0] 
Greyscale */


Daniel, what do you think?


2 of the first 3 tinydrm drivers are monochrome (and I would like to 
write a driver for the Seeed/Grove I2C OLED displays which are also 
monochrome), so I think the 1bpp modes would definitely be useful.


David, I'm curious about those displays what controller/interface they use.
I have been hoping that it would be possible to use regmap as an
abstraction for many of these controllers and their registers.


The particular display I have is this one: 
http://wiki.seeed.cc/Grove-OLED_Display_1.12inch/


It looks like it uses a command/data scheme like the MIPI displays, but 
doesn't use any of the standard values for the commands. The controller 
can do parallel, SPI and I2C, but the display I have is wired for I2C.




For MIPI DCS it wasn't possible because it's command oriented with
arguments. Since zero arguments is possible, a register with no value
is nonsense, even though the regmap implementation happily let me do it.
There's also the problem that regmap doesn't support registers with
different widths. Which is a problem if all registers are 8-bit wide,
except the GRAM register being 16-bit on RGB565 formats.

regmap is especially helpful with controllers that also have
gpios/keypad/touch/pwm, since the mfd (multi function device) subsystem
has good support for sharing regmaps between drivers. Multi function
devices are split into several drivers.

Noralf.



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

[PATCH v2 3/4] ARM: dts: da850-lego-ev3: Add node for LCD display

[David Lechner]

This adds a new node for the LEGO MINDSTORMS EV3 LCD display.

Signed-off-by: David Lechner <da...@lechnology.com>
---
 arch/arm/boot/dts/da850-lego-ev3.dts | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/da850-lego-ev3.dts 
b/arch/arm/boot/dts/da850-lego-ev3.dts
index 45983c0..249b317 100644
--- a/arch/arm/boot/dts/da850-lego-ev3.dts
+++ b/arch/arm/boot/dts/da850-lego-ev3.dts
@@ -249,6 +249,15 @@
0x4c 0x0080 0x00f0
>;
};
+
+   ev3_lcd_pins: pinmux_lcd {
+   pinctrl-single,bits = <
+   /* SIMO, GP2[11], GP2[12], CLK */
+   0x14 0x00188100 0x0000
+   /* GP5[0] */
+   0x30 0x8000 0xf000
+   >;
+   };
 };
 
  {
@@ -357,6 +366,21 @@
};
 };
 
+ {
+   status = "okay";
+   pinctrl-0 = <_lcd_pins>;
+   pinctrl-names = "default";
+   cs-gpios = < 44 GPIO_ACTIVE_LOW>;
+
+   display@0{
+   compatible = "lego,ev3-lcd";
+   reg = <0>;
+   spi-max-frequency = <1000>;
+   dc-gpios = < 43 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 80 GPIO_ACTIVE_HIGH>;
+   };
+};
+
  {
status = "okay";
 };
-- 
2.7.4

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

[PATCH v2 2/4] drm/tinydrm: add support for LEGO MINDSTORMS EV3 LCD

[David Lechner]

LEGO MINDSTORMS EV3 has an LCD with a ST7586 controller. This adds a new
module for the ST7586 controller with parameters for the EV3 LCD display.

Signed-off-by: David Lechner <da...@lechnology.com>
---
 .../devicetree/bindings/display/st7586.txt |  26 +
 drivers/gpu/drm/tinydrm/Kconfig|  10 +
 drivers/gpu/drm/tinydrm/Makefile   |   1 +
 drivers/gpu/drm/tinydrm/st7586.c   | 579 +
 include/drm/tinydrm/st7586.h   |  34 ++
 5 files changed, 650 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/st7586.txt
 create mode 100644 drivers/gpu/drm/tinydrm/st7586.c
 create mode 100644 include/drm/tinydrm/st7586.h

diff --git a/Documentation/devicetree/bindings/display/st7586.txt 
b/Documentation/devicetree/bindings/display/st7586.txt
new file mode 100644
index 000..acf784aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/st7586.txt
@@ -0,0 +1,26 @@
+Sitronix ST7586 display panel
+
+Required properties:
+- compatible:  "lego,ev3-lcd".
+
+The node for this driver must be a child node of a SPI controller, hence
+all mandatory properties described in ../spi/spi-bus.txt must be specified.
+
+Optional properties:
+- dc-gpios:D/C pin. The presence/absence of this GPIO determines
+   the panel interface mode (IM[3:0] pins):
+   - present: IM=x110 4-wire 8-bit data serial interface
+   - absent:  IM=x101 3-wire 9-bit data serial interface
+- reset-gpios: Reset pin
+- power-supply:A regulator node for the supply voltage.
+- backlight:   phandle of the backlight device attached to the panel
+- rotation:panel rotation in degrees counter clockwise (0,90,180,270)
+
+Example:
+   display@0{
+   compatible = "lego,ev3-lcd";
+   reg = <0>;
+   spi-max-frequency = <1000>;
+   dc-gpios = < 43 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 80 GPIO_ACTIVE_HIGH>;
+   };
diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index f17c3ca..2e790e7 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -32,3 +32,13 @@ config TINYDRM_REPAPER
  2.71" TFT EPD Panel (E2271CS021)
 
  If M is selected the module will be called repaper.
+
+config TINYDRM_ST7586
+   tristate "DRM support for Sitronix ST7586 display panels"
+   depends on DRM_TINYDRM && SPI
+   select TINYDRM_MIPI_DBI
+   help
+ DRM driver for the following Sitronix ST7586 panels:
+ * LEGO MINDSTORMS EV3
+
+ If M is selected the module will be called st7586.
diff --git a/drivers/gpu/drm/tinydrm/Makefile b/drivers/gpu/drm/tinydrm/Makefile
index 95bb4d4..0c184bd 100644
--- a/drivers/gpu/drm/tinydrm/Makefile
+++ b/drivers/gpu/drm/tinydrm/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_TINYDRM_MIPI_DBI)  += mipi-dbi.o
 # Displays
 obj-$(CONFIG_TINYDRM_MI0283QT) += mi0283qt.o
 obj-$(CONFIG_TINYDRM_REPAPER)  += repaper.o
+obj-$(CONFIG_TINYDRM_ST7586)   += st7586.o
diff --git a/drivers/gpu/drm/tinydrm/st7586.c b/drivers/gpu/drm/tinydrm/st7586.c
new file mode 100644
index 000..6093021
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/st7586.c
@@ -0,0 +1,579 @@
+/*
+ * DRM driver for Sitronix ST7586 panels
+ *
+ * Copyright 2017 David Lechner <da...@lechnology.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+static inline u8 st7586_rgb565_to_gray2(u16 rgb)
+{
+   u8 r = (rgb & 0xf800) >> 11;
+   u8 g = (rgb & 0x07e0) >> 5;
+   u8 b = rgb & 0x001f;
+   /* ITU BT.601: Y = 0.299 R + 0.587 G + 0.114 B */
+   /* g is already * 2 because it is 6-bit */
+   u8 gray5 = (3 * r + 3 * g + b) / 10;
+
+   return gray5 >> 3;
+}
+
+static void st7586_from_rgb565(u8 *dst, void *vaddr,
+  struct drm_framebuffer *fb,
+  struct drm_clip_rect *clip)
+{
+   size_t len;
+   unsigned int x, y;
+   u16 *src, *buf;
+   u8 val;
+
+   /* 3 pixels per byte, so grow clip to nearest multiple of 3 */
+   clip->x1 = clip->x1 / 3 * 3;
+   clip->x2 = (clip->x2 + 2) / 3 * 3;
+   len = (clip->x2 - clip->x1) * sizeof(u16);
+
+   buf = kmalloc(len, GFP_KERNEL);
+   if (!buf)
+   return;
+
+   for (y = clip->y1; y < clip->y2; y++) {
+   src = vaddr + (y * fb->pitches[0]);
+   src += clip->x1;
+ 

[PATCH v2 0/4] Support for LEGO MINDSTORMS EV3 LCD display

[David Lechner]

The goal of this series is to get the built-in LCD of the LEGO MINDSTORMS EV3
working.

v2 changes:
* Wrote a new driver for ST7586 instead of combining it with existing drivers
* Don't touch MIPI DBI code (other than the patch suggested by Noralf)
* New defconfig patch


David Lechner (4):
  drm/tinydrm: remove call to mipi_dbi_init() from mipi_dbi_spi_init()
  drm/tinydrm: add support for LEGO MINDSTORMS EV3 LCD
  ARM: dts: da850-lego-ev3: Add node for LCD display
  ARM: davinci_all_defconfig: enable tinydrm and ST7586

 .../devicetree/bindings/display/st7586.txt |  26 +
 arch/arm/boot/dts/da850-lego-ev3.dts   |  24 +
 arch/arm/configs/davinci_all_defconfig |   2 +
 drivers/gpu/drm/tinydrm/Kconfig|  10 +
 drivers/gpu/drm/tinydrm/Makefile   |   1 +
 drivers/gpu/drm/tinydrm/mi0283qt.c |   8 +-
 drivers/gpu/drm/tinydrm/mipi-dbi.c |  17 +-
 drivers/gpu/drm/tinydrm/st7586.c   | 579 +
 include/drm/tinydrm/mipi-dbi.h |   6 +-
 include/drm/tinydrm/st7586.h   |  34 ++
 10 files changed, 688 insertions(+), 19 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/st7586.txt
 create mode 100644 drivers/gpu/drm/tinydrm/st7586.c
 create mode 100644 include/drm/tinydrm/st7586.h

-- 
2.7.4

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

[PATCH v2 4/4] ARM: davinci_all_defconfig: enable tinydrm and ST7586

[David Lechner]

This enables the tinydrm and ST7586 panel modules used by the display
on LEGO MINDSTORMS EV3.

Signed-off-by: David Lechner <da...@lechnology.com>
---
 arch/arm/configs/davinci_all_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/davinci_all_defconfig 
b/arch/arm/configs/davinci_all_defconfig
index 06e2e2a..27d9720 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -143,6 +143,8 @@ CONFIG_VIDEO_ADV7343=m
 CONFIG_DRM=m
 CONFIG_DRM_TILCDC=m
 CONFIG_DRM_DUMB_VGA_DAC=m
+CONFIG_DRM_TINYDRM=m
+CONFIG_TINYDRM_ST7586=m
 CONFIG_FB=y
 CONFIG_FIRMWARE_EDID=y
 CONFIG_FB_DA8XX=y
-- 
2.7.4

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

[PATCH v2 1/4] drm/tinydrm: remove call to mipi_dbi_init() from mipi_dbi_spi_init()

[David Lechner]

This removes the call to mipi_dbi_init() from mipi_dbi_spi_init() so that
drivers can have a driver-specific implementation if needed.

Also fixed order of @dc parameter in the doc comment.

Suggested-by: Noralf Trønnes <nor...@tronnes.org>
Signed-off-by: David Lechner <da...@lechnology.com>
---
 drivers/gpu/drm/tinydrm/mi0283qt.c |  8 ++--
 drivers/gpu/drm/tinydrm/mipi-dbi.c | 17 +
 include/drm/tinydrm/mipi-dbi.h |  6 +-
 3 files changed, 12 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 482ff1c3..7e5bb7d 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -195,8 +195,12 @@ static int mi0283qt_probe(struct spi_device *spi)
 
device_property_read_u32(dev, "rotation", );
 
-   ret = mipi_dbi_spi_init(spi, mipi, dc, _pipe_funcs,
-   _driver, _mode, rotation);
+   ret = mipi_dbi_spi_init(spi, mipi, dc);
+   if (ret)
+   return ret;
+
+   ret = mipi_dbi_init(>dev, mipi, _pipe_funcs,
+   _driver, _mode, rotation);
if (ret)
return ret;
 
diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index e10fa4b..cba9784 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -777,15 +777,12 @@ static int mipi_dbi_typec3_command(struct mipi_dbi *mipi, 
u8 cmd,
 /**
  * mipi_dbi_spi_init - Initialize MIPI DBI SPI interfaced controller
  * @spi: SPI device
- * @dc: D/C gpio (optional)
  * @mipi: _dbi structure to initialize
- * @pipe_funcs: Display pipe functions
- * @driver: DRM driver
- * @mode: Display mode
- * @rotation: Initial rotation in degrees Counter Clock Wise
+ * @dc: D/C gpio (optional)
  *
  * This function sets _dbi->command, enables >read_commands for the
- * usual read commands and initializes @mipi using mipi_dbi_init().
+ * usual read commands. It should be followed by a call to mipi_dbi_init() or
+ * a driver-specific init.
  *
  * If @dc is set, a Type C Option 3 interface is assumed, if not
  * Type C Option 1.
@@ -800,11 +797,7 @@ static int mipi_dbi_typec3_command(struct mipi_dbi *mipi, 
u8 cmd,
  * Zero on success, negative error code on failure.
  */
 int mipi_dbi_spi_init(struct spi_device *spi, struct mipi_dbi *mipi,
- struct gpio_desc *dc,
- const struct drm_simple_display_pipe_funcs *pipe_funcs,
- struct drm_driver *driver,
- const struct drm_display_mode *mode,
- unsigned int rotation)
+ struct gpio_desc *dc)
 {
size_t tx_size = tinydrm_spi_max_transfer_size(spi, 0);
struct device *dev = >dev;
@@ -850,7 +843,7 @@ int mipi_dbi_spi_init(struct spi_device *spi, struct 
mipi_dbi *mipi,
return -ENOMEM;
}
 
-   return mipi_dbi_init(dev, mipi, pipe_funcs, driver, mode, rotation);
+   return 0;
 }
 EXPORT_SYMBOL(mipi_dbi_spi_init);
 
diff --git a/include/drm/tinydrm/mipi-dbi.h b/include/drm/tinydrm/mipi-dbi.h
index d137b16..83346dd 100644
--- a/include/drm/tinydrm/mipi-dbi.h
+++ b/include/drm/tinydrm/mipi-dbi.h
@@ -62,11 +62,7 @@ mipi_dbi_from_tinydrm(struct tinydrm_device *tdev)
 }
 
 int mipi_dbi_spi_init(struct spi_device *spi, struct mipi_dbi *mipi,
- struct gpio_desc *dc,
- const struct drm_simple_display_pipe_funcs *pipe_funcs,
- struct drm_driver *driver,
- const struct drm_display_mode *mode,
- unsigned int rotation);
+ struct gpio_desc *dc);
 int mipi_dbi_init(struct device *dev, struct mipi_dbi *mipi,
  const struct drm_simple_display_pipe_funcs *pipe_funcs,
  struct drm_driver *driver,
-- 
2.7.4

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

[PATCH] drm/tinydrm: mipi-dbi: Fix unbalanced DMA access

[David Lechner]

If we return here and import_attach is true, then dma_buf_end_cpu_access()
will not be called balance dma_buf_begin_cpu_access().

Fix by setting ret instead of returning.

Signed-off-by: David Lechner <da...@lechnology.com>
---
 drivers/gpu/drm/tinydrm/mipi-dbi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index c83eeb7..e10fa4b 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -183,7 +183,8 @@ static int mipi_dbi_buf_copy(void *dst, struct 
drm_framebuffer *fb,
dev_err_once(fb->dev->dev, "Format is not supported: %s\n",
 drm_get_format_name(fb->format->format,
 _name));
-   return -EINVAL;
+   ret = -EINVAL;
+   break;
}
 
if (import_attach)
-- 
2.7.4

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

Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display

[David Lechner]

On 08/01/2017 01:08 PM, Noralf Trønnes wrote:

(cc: Daniel Vetter)


Den 01.08.2017 18.51, skrev David Lechner:

On 07/30/2017 12:14 PM, Noralf Trønnes wrote:


Den 29.07.2017 21.40, skrev David Lechner:

On 07/29/2017 02:17 PM, David Lechner wrote:
The goal of this series is to get the built-in LCD of the LEGO 
MINDSTORMS EV3
working. But, most of the content here is building up the 
infrastructure to do

that.



Some general comments/questions:

I have noticed that DRM doesn't really have support for monochrome 
displays. I'm guessing that is because no one really uses them anymore?




The repaper driver was the first monochrome drm driver and I chose to
present it to userspace as XRGB and convert it to monochrome.
The reason for this is that everything, libraries, apps, plymouth (boot
splash, no rgb565) supports it. I didn't see any point in adding a new
monochrome drm format that didn't have, or probably wouldn't get
userspace support (by libraries at least). The application of course
needs to know this to get a good result.

tinydrm_xrgb_to_gray8() does the conversion:
https://cgit.freedesktop.org/drm/drm-misc/commit/drivers/gpu/drm/tinydrm?id=379ea9a1a59a5a32c8db6f164e80a3fd00cb3781 



The LEGO EV3 display is just an LCD (not the backlit kind). It has 
two modes of operation. It can to 2bbp grayscale or it can do 1bpp 
monochrome. The grayscale isn't the best (looks splotchy in places), 
so it would be nice to be able to choose between these two modes. 
How would I implement something like that?




Do you expect anyone to use grayscale if it doesn't look good?
Maybe better to add it later if there's a demand for it.


I don't expect many people to use it at all. The people that do will 
be hackers like me that want to see what it is capable of, so I think 
I will keep it grayscale by default.




It looks like the best way to satisfy your needs is to add specific 
formats.


Video for Linux have these:

include/uapi/linux/videodev2.h

/* Grey formats */
#define V4L2_PIX_FMT_GREYv4l2_fourcc('G', 'R', 'E', 'Y') /*  8 
Greyscale */
#define V4L2_PIX_FMT_Y4  v4l2_fourcc('Y', '0', '4', ' ') /*  4 
Greyscale */
#define V4L2_PIX_FMT_Y6  v4l2_fourcc('Y', '0', '6', ' ') /*  6 
Greyscale */
#define V4L2_PIX_FMT_Y10 v4l2_fourcc('Y', '1', '0', ' ') /* 10 
Greyscale */
#define V4L2_PIX_FMT_Y12 v4l2_fourcc('Y', '1', '2', ' ') /* 12 
Greyscale */
#define V4L2_PIX_FMT_Y16 v4l2_fourcc('Y', '1', '6', ' ') /* 16 
Greyscale */
#define V4L2_PIX_FMT_Y16_BE  v4l2_fourcc_be('Y', '1', '6', ' ') /* 16 
Greyscale BE  */



Maybe we can add formats like these:

include/uapi/drm/drm_fourcc.h

#define DRM_FORMAT_MONOfourcc_code('Y', '0', '1', ' ') /* [0] 
Monochrome */

or
#define DRM_FORMAT_Y1fourcc_code('Y', '0', '1', ' ') /* [0] 
Monochrome */


#define DRM_FORMAT_Y2fourcc_code('Y', '0', '2', ' ') /* [1:0] 
Greyscale */


Daniel, what do you think?


2 of the first 3 tinydrm drivers are monochrome (and I would like to 
write a driver for the Seeed/Grove I2C OLED displays which are also 
monochrome), so I think the 1bpp modes would definitely be useful. I 
think there is enough userspace code still around that knows about 
FB_VISUAL_MONO01 and FB_VISUAL_MONO10 that could use these.


I don't think a Y02 mode would be useful though. There is pretty much 
nothing out there (that I could find) that uses such a mode.


A Y08 mode for 8bpp grayscale would be useful though. This is another 
more commonly used format.






Also, how can I indicate to userspace that this display really is 
monochrome/grayscale since the reported color depth 16bpp?




There isn't unless we add formats for it.
Since this display is in a Lego piece, doesn't it have custom userspace
that already know it's monochrome?


The official LEGO software is like this, yes. But I am working on a 
project that supports other LEGO compatible devices that have color 
screens, so the same software needs to be able to detect at runtime 
which type of screen it is using. Currently I have a plain fbdev 
driver that provides FB_VISUAL_MONO10 for the EV3 display and so the 
software knows when it has a monochrome screen and when it doesn't. 
But since plain fbdev drivers can't be accepted into mainline, I need 
to find a different way to detect what type of screen this is so that 
my graphics library can treat it differently.





You can tell userspace about the preferred bitdepth:
drm->mode_config.preferred_depth


Noralf.



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

Re: [PATCH] drm/tinydrm: mipi-dbi: Fix unbalanced DMA access

[David Lechner]

On 08/01/2017 03:14 PM, David Lechner wrote:

If we return here and import_attach is true, then dma_buf_end_cpu_access()
will not be called balance dma_buf_begin_cpu_access().

Fix by setting ret instead of returning.

Signed-off-by: David Lechner <da...@lechnology.com>
---
  drivers/gpu/drm/tinydrm/mipi-dbi.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index c83eeb7..e10fa4b 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -183,7 +183,8 @@ static int mipi_dbi_buf_copy(void *dst, struct 
drm_framebuffer *fb,
dev_err_once(fb->dev->dev, "Format is not supported: %s\n",
 drm_get_format_name(fb->format->format,
 _name));
-   return -EINVAL;
+   ret = -EINVAL;
+   break;
}
  
  	if (import_attach)





I just realized that the next line here can mask ret.


if (import_attach)
ret = dma_buf_end_cpu_access(import_attach->dmabuf,
 DMA_FROM_DEVICE);

So, we should either ignore the return value from 
dma_buf_end_cpu_access() always or add some logic to ignore it if ret is 
already an error.


In some of the other patches I have been sending, we have the same 
situation. I those, I have opted to just ignore the return value from 
dma_buf_end_cpu_access(). e.g...



if (import_attach)
dma_buf_end_cpu_access(import_attach->dmabuf, DMA_FROM_DEVICE);

Is this a reasonable thing to do?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 6/6] ARM: davinci_all_defconfig: enable tinydrm and ST7586

[David Lechner]

This enables the tinydrm and ST7586 panel modules used by the display
on LEGO MINDSTORMS EV3.

Signed-off-by: David Lechner <da...@lechnology.com>
---
 arch/arm/configs/davinci_all_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/davinci_all_defconfig 
b/arch/arm/configs/davinci_all_defconfig
index 06e2e2a..27d9720 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -143,6 +143,8 @@ CONFIG_VIDEO_ADV7343=m
 CONFIG_DRM=m
 CONFIG_DRM_TILCDC=m
 CONFIG_DRM_DUMB_VGA_DAC=m
+CONFIG_DRM_TINYDRM=m
+CONFIG_TINYDRM_ST7586=m
 CONFIG_FB=y
 CONFIG_FIRMWARE_EDID=y
 CONFIG_FB_DA8XX=y
-- 
2.7.4

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

[PATCH v3 2/6] drm/tinydrm: generalize tinydrm_xrgb8888_to_gray8()

[David Lechner]

This adds parameters for vaddr and clip to tinydrm_xrgb_to_gray8() to
make it more generic.

dma_buf_{begin,end}_cpu_access() are moved out to the repaper driver.

Signed-off-by: David Lechner <da...@lechnology.com>
---
 drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 35 ++
 drivers/gpu/drm/tinydrm/repaper.c  | 21 +++-
 include/drm/tinydrm/tinydrm-helpers.h  |  3 ++-
 3 files changed, 35 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index 75808bb..5915ba8 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -185,7 +185,9 @@ EXPORT_SYMBOL(tinydrm_xrgb_to_rgb565);
 /**
  * tinydrm_xrgb_to_gray8 - Convert XRGB to grayscale
  * @dst: 8-bit grayscale destination buffer
+ * @vaddr: XRGB source buffer
  * @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
  *
  * Drm doesn't have native monochrome or grayscale support.
  * Such drivers can announce the commonly supported XR24 format to userspace
@@ -199,12 +201,11 @@ EXPORT_SYMBOL(tinydrm_xrgb_to_rgb565);
  * Returns:
  * Zero on success, negative error code on failure.
  */
-int tinydrm_xrgb_to_gray8(u8 *dst, struct drm_framebuffer *fb)
+int tinydrm_xrgb_to_gray8(u8 *dst, void *vaddr, struct drm_framebuffer *fb,
+ struct drm_clip_rect *clip)
 {
-   struct drm_gem_cma_object *cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
-   struct dma_buf_attachment *import_attach = cma_obj->base.import_attach;
-   unsigned int x, y, pitch = fb->pitches[0];
-   int ret = 0;
+   unsigned int len = (clip->x2 - clip->x1) * sizeof(u32);
+   unsigned int x, y;
void *buf;
u32 *src;
 
@@ -214,22 +215,16 @@ int tinydrm_xrgb_to_gray8(u8 *dst, struct 
drm_framebuffer *fb)
 * The cma memory is write-combined so reads are uncached.
 * Speed up by fetching one line at a time.
 */
-   buf = kmalloc(pitch, GFP_KERNEL);
+   buf = kmalloc(len, GFP_KERNEL);
if (!buf)
return -ENOMEM;
 
-   if (import_attach) {
-   ret = dma_buf_begin_cpu_access(import_attach->dmabuf,
-  DMA_FROM_DEVICE);
-   if (ret)
-   goto err_free;
-   }
-
-   for (y = 0; y < fb->height; y++) {
-   src = cma_obj->vaddr + (y * pitch);
-   memcpy(buf, src, pitch);
+   for (y = clip->y1; y < clip->y2; y++) {
+   src = vaddr + (y * fb->pitches[0]);
+   src += clip->x1;
+   memcpy(buf, src, len);
src = buf;
-   for (x = 0; x < fb->width; x++) {
+   for (x = clip->x1; x < clip->x2; x++) {
u8 r = (*src & 0x00ff) >> 16;
u8 g = (*src & 0xff00) >> 8;
u8 b =  *src & 0x00ff;
@@ -240,13 +235,9 @@ int tinydrm_xrgb_to_gray8(u8 *dst, struct 
drm_framebuffer *fb)
}
}
 
-   if (import_attach)
-   ret = dma_buf_end_cpu_access(import_attach->dmabuf,
-DMA_FROM_DEVICE);
-err_free:
kfree(buf);
 
-   return ret;
+   return 0;
 }
 EXPORT_SYMBOL(tinydrm_xrgb_to_gray8);
 
diff --git a/drivers/gpu/drm/tinydrm/repaper.c 
b/drivers/gpu/drm/tinydrm/repaper.c
index 3343d3f..d34cd9b 100644
--- a/drivers/gpu/drm/tinydrm/repaper.c
+++ b/drivers/gpu/drm/tinydrm/repaper.c
@@ -18,6 +18,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -525,11 +526,20 @@ static int repaper_fb_dirty(struct drm_framebuffer *fb,
struct drm_clip_rect *clips,
unsigned int num_clips)
 {
+   struct drm_gem_cma_object *cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
+   struct dma_buf_attachment *import_attach = cma_obj->base.import_attach;
struct tinydrm_device *tdev = fb->dev->dev_private;
struct repaper_epd *epd = epd_from_tinydrm(tdev);
+   struct drm_clip_rect clip;
u8 *buf = NULL;
int ret = 0;
 
+   /* repaper can't do partial updates */
+   clip.x1 = 0;
+   clip.x2 = fb->width;
+   clip.y1 = 0;
+   clip.y2 = fb->height;
+
mutex_lock(>dirty_lock);
 
if (!epd->enabled)
@@ -550,7 +560,16 @@ static int repaper_fb_dirty(struct drm_framebuffer *fb,
goto out_unlock;
}
 
-   ret = tinydrm_xrgb_to_gray8(buf, fb);
+   if (import_attach) {
+   ret = dma_buf_begin_cpu_access(import_attach->dmabuf,
+  DMA_FROM_DEVICE);
+   if (ret)
+   goto out_un

[PATCH v3 3/6] dt-bindings: add binding for Sitronix ST7586 display panels

[David Lechner]

This adds a new binding for Sitronix ST7586 display panels.

Using lego as the vendor prefix in the compatible string because the display
panel I am working with is an integral part of the LEGO MINDSTORMS EV3.

Signed-off-by: David Lechner <da...@lechnology.com>
---
 .../bindings/display/sitronix,st7586.txt   | 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/sitronix,st7586.txt

diff --git a/Documentation/devicetree/bindings/display/sitronix,st7586.txt 
b/Documentation/devicetree/bindings/display/sitronix,st7586.txt
new file mode 100644
index 000..dfb0b7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sitronix,st7586.txt
@@ -0,0 +1,26 @@
+Sitronix ST7586 display panel
+
+Required properties:
+- compatible:  "lego,ev3-lcd".
+
+The node for this driver must be a child node of a SPI controller, hence
+all mandatory properties described in ../spi/spi-bus.txt must be specified.
+
+Optional properties:
+- dc-gpios:D/C pin. The presence/absence of this GPIO determines
+   the panel interface operation mode (IF[3:1] pins):
+   - present: IF=011 4-wire 8-bit data serial interface
+   - absent:  IF=010 3-wire 9-bit data serial interface
+- reset-gpios: Reset pin
+- power-supply:A regulator node for the supply voltage.
+- backlight:   phandle of the backlight device attached to the panel
+- rotation:panel rotation in degrees counter clockwise (0,90,180,270)
+
+Example:
+   display@0{
+   compatible = "lego,ev3-lcd";
+   reg = <0>;
+   spi-max-frequency = <1000>;
+   dc-gpios = < 43 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 80 GPIO_ACTIVE_HIGH>;
+   };
-- 
2.7.4

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

[PATCH v3 5/6] ARM: dts: da850-lego-ev3: Add node for LCD display

[David Lechner]

This adds a new node for the LEGO MINDSTORMS EV3 LCD display.

Signed-off-by: David Lechner <da...@lechnology.com>
---
 arch/arm/boot/dts/da850-lego-ev3.dts | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/da850-lego-ev3.dts 
b/arch/arm/boot/dts/da850-lego-ev3.dts
index 45983c0..249b317 100644
--- a/arch/arm/boot/dts/da850-lego-ev3.dts
+++ b/arch/arm/boot/dts/da850-lego-ev3.dts
@@ -249,6 +249,15 @@
0x4c 0x0080 0x00f0
>;
};
+
+   ev3_lcd_pins: pinmux_lcd {
+   pinctrl-single,bits = <
+   /* SIMO, GP2[11], GP2[12], CLK */
+   0x14 0x00188100 0x0000
+   /* GP5[0] */
+   0x30 0x8000 0xf000
+   >;
+   };
 };
 
  {
@@ -357,6 +366,21 @@
};
 };
 
+ {
+   status = "okay";
+   pinctrl-0 = <_lcd_pins>;
+   pinctrl-names = "default";
+   cs-gpios = < 44 GPIO_ACTIVE_LOW>;
+
+   display@0{
+   compatible = "lego,ev3-lcd";
+   reg = <0>;
+   spi-max-frequency = <1000>;
+   dc-gpios = < 43 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 80 GPIO_ACTIVE_HIGH>;
+   };
+};
+
  {
status = "okay";
 };
-- 
2.7.4

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

[PATCH v3 4/6] drm/tinydrm: add support for LEGO MINDSTORMS EV3 LCD

[David Lechner]

LEGO MINDSTORMS EV3 has an LCD with a ST7586 controller. This adds a new
module for the ST7586 controller with parameters for the LEGO MINDSTORMS
EV3 LCD display.

Signed-off-by: David Lechner <da...@lechnology.com>
---
 MAINTAINERS  |   6 +
 drivers/gpu/drm/tinydrm/Kconfig  |  10 +
 drivers/gpu/drm/tinydrm/Makefile |   1 +
 drivers/gpu/drm/tinydrm/st7586.c | 466 +++
 4 files changed, 483 insertions(+)
 create mode 100644 drivers/gpu/drm/tinydrm/st7586.c

diff --git a/MAINTAINERS b/MAINTAINERS
index a1e772e..9643f95 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4365,6 +4365,12 @@ S:   Maintained
 F: drivers/gpu/drm/tinydrm/repaper.c
 F: Documentation/devicetree/bindings/display/repaper.txt
 
+DRM DRIVER FOR SITRONIX ST7586 PANELS
+M: David Lechner <da...@lechnology.com>
+S: Maintained
+F: drivers/gpu/drm/tinydrm/st7586.c
+F: Documentation/devicetree/bindings/display/st7586.txt
+
 DRM DRIVER FOR RAGE 128 VIDEO CARDS
 S: Orphan / Obsolete
 F: drivers/gpu/drm/r128/
diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index f17c3ca..2e790e7 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -32,3 +32,13 @@ config TINYDRM_REPAPER
  2.71" TFT EPD Panel (E2271CS021)
 
  If M is selected the module will be called repaper.
+
+config TINYDRM_ST7586
+   tristate "DRM support for Sitronix ST7586 display panels"
+   depends on DRM_TINYDRM && SPI
+   select TINYDRM_MIPI_DBI
+   help
+ DRM driver for the following Sitronix ST7586 panels:
+ * LEGO MINDSTORMS EV3
+
+ If M is selected the module will be called st7586.
diff --git a/drivers/gpu/drm/tinydrm/Makefile b/drivers/gpu/drm/tinydrm/Makefile
index 95bb4d4..0c184bd 100644
--- a/drivers/gpu/drm/tinydrm/Makefile
+++ b/drivers/gpu/drm/tinydrm/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_TINYDRM_MIPI_DBI)  += mipi-dbi.o
 # Displays
 obj-$(CONFIG_TINYDRM_MI0283QT) += mi0283qt.o
 obj-$(CONFIG_TINYDRM_REPAPER)  += repaper.o
+obj-$(CONFIG_TINYDRM_ST7586)   += st7586.o
diff --git a/drivers/gpu/drm/tinydrm/st7586.c b/drivers/gpu/drm/tinydrm/st7586.c
new file mode 100644
index 000..11e226d
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/st7586.c
@@ -0,0 +1,466 @@
+/*
+ * DRM driver for Sitronix ST7586 panels
+ *
+ * Copyright 2017 David Lechner <da...@lechnology.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+/* controller-specific commands */
+#define ST7586_DISP_MODE_GRAY  0x38
+#define ST7586_DISP_MODE_MONO  0x39
+#define ST7586_ENABLE_DDRAM0x3a
+#define ST7586_SET_DISP_DUTY   0xb0
+#define ST7586_SET_PART_DISP   0xb4
+#define ST7586_SET_NLINE_INV   0xb5
+#define ST7586_SET_VOP 0xc0
+#define ST7586_SET_BIAS_SYSTEM 0xc3
+#define ST7586_SET_BOOST_LEVEL 0xc4
+#define ST7586_SET_VOP_OFFSET  0xc7
+#define ST7586_ENABLE_ANALOG   0xd0
+#define ST7586_AUTO_READ_CTRL  0xd7
+#define ST7586_OTP_RW_CTRL 0xe0
+#define ST7586_OTP_CTRL_OUT0xe1
+#define ST7586_OTP_READ0xe3
+
+#define ST7586_DISP_CTRL_MXBIT(6)
+#define ST7586_DISP_CTRL_MYBIT(7)
+
+static void st7586_xrgb_to_gray332(u8 *dst, void *vaddr,
+  struct drm_framebuffer *fb,
+  struct drm_clip_rect *clip)
+{
+   size_t len = (clip->x2 - clip->x1) * (clip->y2 - clip->y1);
+   unsigned int x, y;
+   u8 *src, *buf, val;
+
+   /* 3 pixels per byte, so grow clip to nearest multiple of 3 */
+   clip->x1 = clip->x1 / 3 * 3;
+   clip->x2 = (clip->x2 + 2) / 3 * 3;
+
+   buf = kmalloc(len, GFP_KERNEL);
+   if (!buf)
+   return;
+
+   tinydrm_xrgb_to_gray8(buf, vaddr, fb, clip);
+   src = buf;
+
+   for (y = clip->y1; y < clip->y2; y++) {
+   for (x = clip->x1; x < clip->x2; x += 3) {
+   val = *src++ & 0xc0;
+   if (val & 0xc0)
+   val |= 0x20;
+   val |= (*src++ & 0xc0) >> 3;
+   if (val & 0x18)
+   val |= 0x04;
+   val |= *src++ >> 6;
+   *dst++ = ~val;
+   }
+   }
+
+   /* now adjust the clip so it applies to dst */
+   clip->x1 /= 3;
+   clip->x2 /= 3;
+
+   kfree(buf);
+}
+
+static int st7586_buf_copy(void *dst, struct drm_framebuffer *fb,
+ 

[PATCH v3 0/6] Support for LEGO MINDSTORMS EV3 LCD display

[David Lechner]

The goal of this series is to get the built-in LCD of the LEGO MINDSTORMS EV3
working.

v2 changes:
* Wrote a new driver for ST7586 instead of combining it with existing drivers
* Don't touch MIPI DBI code (other than the patch suggested by Noralf)
* New defconfig patch

v3 changes:
* New patch to generalize tinydrm_xrgb_to_gray8() so that it can be reused.
* Device tree bindings in separate patch.
* Fixed incorrect device tree binding pin descriptions.
* Added MAINTAINERS entry for drivers/gpu/drm/tinydrm/st7586.c.
* Removed "mipi_dbi_" from function names in st7586.c.
* Moved init and fini to pipe_enable and pipe_disable ops.
* Dropped RGB565 format.
* Made adjustments for the fact the controller cannot be read via SPI.
* Dropped st7586.h - values moved into st7586.c.

David Lechner (6):
  drm/tinydrm: remove call to mipi_dbi_init() from mipi_dbi_spi_init()
  drm/tinydrm: generalize tinydrm_xrgb_to_gray8()
  dt-bindings: add binding for Sitronix ST7586 display panels
  drm/tinydrm: add support for LEGO MINDSTORMS EV3 LCD
  ARM: dts: da850-lego-ev3: Add node for LCD display
  ARM: davinci_all_defconfig: enable tinydrm and ST7586

 .../bindings/display/sitronix,st7586.txt   |  26 ++
 MAINTAINERS|   6 +
 arch/arm/boot/dts/da850-lego-ev3.dts   |  24 ++
 arch/arm/configs/davinci_all_defconfig |   2 +
 drivers/gpu/drm/tinydrm/Kconfig|  10 +
 drivers/gpu/drm/tinydrm/Makefile   |   1 +
 drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c |  35 +-
 drivers/gpu/drm/tinydrm/mi0283qt.c |   8 +-
 drivers/gpu/drm/tinydrm/mipi-dbi.c |  17 +-
 drivers/gpu/drm/tinydrm/repaper.c  |  21 +-
 drivers/gpu/drm/tinydrm/st7586.c   | 466 +
 include/drm/tinydrm/mipi-dbi.h |   6 +-
 include/drm/tinydrm/tinydrm-helpers.h  |   3 +-
 13 files changed, 582 insertions(+), 43 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/sitronix,st7586.txt
 create mode 100644 drivers/gpu/drm/tinydrm/st7586.c

-- 
2.7.4

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

[PATCH v3 1/6] drm/tinydrm: remove call to mipi_dbi_init() from mipi_dbi_spi_init()

[David Lechner]

This removes the call to mipi_dbi_init() from mipi_dbi_spi_init() so that
drivers can have a driver-specific implementation if needed.

Suggested-by: Noralf Trønnes <nor...@tronnes.org>
Signed-off-by: David Lechner <da...@lechnology.com>
Reviewed-by: Noralf Trønnes <nor...@tronnes.org>
---
 drivers/gpu/drm/tinydrm/mi0283qt.c |  8 ++--
 drivers/gpu/drm/tinydrm/mipi-dbi.c | 17 +
 include/drm/tinydrm/mipi-dbi.h |  6 +-
 3 files changed, 12 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 482ff1c3..7e5bb7d 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -195,8 +195,12 @@ static int mi0283qt_probe(struct spi_device *spi)
 
device_property_read_u32(dev, "rotation", );
 
-   ret = mipi_dbi_spi_init(spi, mipi, dc, _pipe_funcs,
-   _driver, _mode, rotation);
+   ret = mipi_dbi_spi_init(spi, mipi, dc);
+   if (ret)
+   return ret;
+
+   ret = mipi_dbi_init(>dev, mipi, _pipe_funcs,
+   _driver, _mode, rotation);
if (ret)
return ret;
 
diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index e10fa4b..cba9784 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -777,15 +777,12 @@ static int mipi_dbi_typec3_command(struct mipi_dbi *mipi, 
u8 cmd,
 /**
  * mipi_dbi_spi_init - Initialize MIPI DBI SPI interfaced controller
  * @spi: SPI device
- * @dc: D/C gpio (optional)
  * @mipi: _dbi structure to initialize
- * @pipe_funcs: Display pipe functions
- * @driver: DRM driver
- * @mode: Display mode
- * @rotation: Initial rotation in degrees Counter Clock Wise
+ * @dc: D/C gpio (optional)
  *
  * This function sets _dbi->command, enables >read_commands for the
- * usual read commands and initializes @mipi using mipi_dbi_init().
+ * usual read commands. It should be followed by a call to mipi_dbi_init() or
+ * a driver-specific init.
  *
  * If @dc is set, a Type C Option 3 interface is assumed, if not
  * Type C Option 1.
@@ -800,11 +797,7 @@ static int mipi_dbi_typec3_command(struct mipi_dbi *mipi, 
u8 cmd,
  * Zero on success, negative error code on failure.
  */
 int mipi_dbi_spi_init(struct spi_device *spi, struct mipi_dbi *mipi,
- struct gpio_desc *dc,
- const struct drm_simple_display_pipe_funcs *pipe_funcs,
- struct drm_driver *driver,
- const struct drm_display_mode *mode,
- unsigned int rotation)
+ struct gpio_desc *dc)
 {
size_t tx_size = tinydrm_spi_max_transfer_size(spi, 0);
struct device *dev = >dev;
@@ -850,7 +843,7 @@ int mipi_dbi_spi_init(struct spi_device *spi, struct 
mipi_dbi *mipi,
return -ENOMEM;
}
 
-   return mipi_dbi_init(dev, mipi, pipe_funcs, driver, mode, rotation);
+   return 0;
 }
 EXPORT_SYMBOL(mipi_dbi_spi_init);
 
diff --git a/include/drm/tinydrm/mipi-dbi.h b/include/drm/tinydrm/mipi-dbi.h
index d137b16..83346dd 100644
--- a/include/drm/tinydrm/mipi-dbi.h
+++ b/include/drm/tinydrm/mipi-dbi.h
@@ -62,11 +62,7 @@ mipi_dbi_from_tinydrm(struct tinydrm_device *tdev)
 }
 
 int mipi_dbi_spi_init(struct spi_device *spi, struct mipi_dbi *mipi,
- struct gpio_desc *dc,
- const struct drm_simple_display_pipe_funcs *pipe_funcs,
- struct drm_driver *driver,
- const struct drm_display_mode *mode,
- unsigned int rotation);
+ struct gpio_desc *dc);
 int mipi_dbi_init(struct device *dev, struct mipi_dbi *mipi,
  const struct drm_simple_display_pipe_funcs *pipe_funcs,
  struct drm_driver *driver,
-- 
2.7.4

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

Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display

[David Lechner]

On 08/03/2017 03:11 PM, Noralf Trønnes wrote:


Den 03.08.2017 19.11, skrev Andy Shevchenko:

On Thu, Aug 3, 2017 at 8:09 PM, Andy Shevchenko
<andy.shevche...@gmail.com> wrote:
On Thu, Aug 3, 2017 at 6:18 PM, David Lechner <da...@lechnology.com> 
wrote:



The particular display I have is this one:
http://wiki.seeed.cc/Grove-OLED_Display_1.12inch/

It looks like it uses a command/data scheme like the MIPI displays, but
doesn't use any of the standard values for the commands. The 
controller can

do parallel, SPI and I2C, but the display I have is wired for I2C.

It looks very similar to ssd1306. Some description refers to ssd1308.

http://www.mouser.com/catalog/specsheets/Seeed_104030008.pdf



That pdf refers to another one: 
http://wiki.seeed.cc/Grove-OLED_Display_0.96inch/
There's an fbdev driver that supports ssd1305, ssd1306, ssd1307 and 
ssd1309:
https://www.kernel.org/doc/Documentation/devicetree/bindings/display/ssd1307fb.txt 

http://elixir.free-electrons.com/linux/latest/source/drivers/video/fbdev/ssd1307fb.c 


Maybe the ssd1308 will work with that driver...



The display I have uses a ssd1327 controller. It is 16-bit grayscale. 
The ssd130x are all 1-bit monochrome. So, probably more like the ssd1325 
driver in fbftf.

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

Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display

[David Lechner]

On 08/03/2017 08:08 PM, David Lechner wrote:

On 08/03/2017 03:11 PM, Noralf Trønnes wrote:


Den 03.08.2017 19.11, skrev Andy Shevchenko:

On Thu, Aug 3, 2017 at 8:09 PM, Andy Shevchenko
<andy.shevche...@gmail.com> wrote:
On Thu, Aug 3, 2017 at 6:18 PM, David Lechner <da...@lechnology.com> 
wrote:



The particular display I have is this one:
http://wiki.seeed.cc/Grove-OLED_Display_1.12inch/

It looks like it uses a command/data scheme like the MIPI displays, 
but
doesn't use any of the standard values for the commands. The 
controller can

do parallel, SPI and I2C, but the display I have is wired for I2C.

It looks very similar to ssd1306. Some description refers to ssd1308.

http://www.mouser.com/catalog/specsheets/Seeed_104030008.pdf



That pdf refers to another one: 
http://wiki.seeed.cc/Grove-OLED_Display_0.96inch/
There's an fbdev driver that supports ssd1305, ssd1306, ssd1307 and 
ssd1309:
https://www.kernel.org/doc/Documentation/devicetree/bindings/display/ssd1307fb.txt 

http://elixir.free-electrons.com/linux/latest/source/drivers/video/fbdev/ssd1307fb.c 


Maybe the ssd1308 will work with that driver...



The display I have uses a ssd1327 controller. It is 16-bit grayscale. 
The ssd130x are all 1-bit monochrome. So, probably more like the ssd1325 
driver in fbftf.


correction, 4-bit grayscale
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 3/6] dt-bindings: add binding for Sitronix ST7586 display panels

[David Lechner]

On 08/04/2017 02:39 PM, Laurent Pinchart wrote:

Hi David,

On Friday 04 Aug 2017 10:51:37 David Lechner wrote:

On 08/04/2017 09:54 AM, Laurent Pinchart wrote:

On Thursday 03 Aug 2017 17:33:47 David Lechner wrote:

This adds a new binding for Sitronix ST7586 display panels.

Using lego as the vendor prefix in the compatible string because the
display panel I am working with is an integral part of the LEGO
MINDSTORMS EV3.

Signed-off-by: David Lechner <da...@lechnology.com>
---

   .../bindings/display/sitronix,st7586.txt   | 26
   +++
   1 file changed, 26 insertions(+)
   create mode 100644

Documentation/devicetree/bindings/display/sitronix,st7586.txt

diff --git
a/Documentation/devicetree/bindings/display/sitronix,st7586.txt
b/Documentation/devicetree/bindings/display/sitronix,st7586.txt new file
mode 100644
index 000..dfb0b7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sitronix,st7586.txt
@@ -0,0 +1,26 @@
+Sitronix ST7586 display panel
+
+Required properties:
+- compatible:  "lego,ev3-lcd".
+
+The node for this driver must be a child node of a SPI controller, hence
+all mandatory properties described in ../spi/spi-bus.txt must be
specified. +
+Optional properties:
+- dc-gpios:D/C pin. The presence/absence of this GPIO determines
+   the panel interface operation mode (IF[3:1] pins):
+   - present: IF=011 4-wire 8-bit data serial interface
+   - absent:  IF=010 3-wire 9-bit data serial interface


How does this work ? Do you have a single GPIO on your system connected to
IF[1], with IF[3:2] hardwired to 01 ?


LEGO has not made the internals of the display publicly available, so I
cannot say for sure. But I assume that IF[3:1] is hardwired to 011. This
causes pin D1 to assigned to the signal A0, which is what we are calling
the dc gpio here.

If IF[3:1] were hardwired to 010, then pin D1 would be not not used and
there would be no A0 signal.

So, basically, we can infer the state of IF[3:1] by the fact that we
have a dc pin or not.


OK, now I understand what you mean. Maybe you should phrase it a bit
differently to make it clearer ? How about

dc-gpios: Specified or the GPIO connected to the panel's D/C pin (also called
A0). The property is required when the panel operates in 4-wire mode (IF[3:1]
= 011) and prohibited when the panel operates in 3-wire mode (IF[3:1] = 010).


Yes, this is more clear. Thank you for the suggestion.



By the way, if the signal is named A0, why don't you call the property a0-
gpios ?


I consider "dc-gpios" to be a generic name since it is used by many 
different panels. But I would be OK with calling it "a0-gpios" as well. 
It will just require more explanation that this is the A0 *signal* and 
not the A0 *pin*. The actual pin used is labeled *D1* on the controller.


On the other hand, it is labeled as A0 on LEGO's schematic, so perhaps 
a0 is better.





+- reset-gpios: Reset pin
+- power-supply:A regulator node for the supply voltage.
+- backlight:   phandle of the backlight device attached to the panel
+- rotation:panel rotation in degrees counter clockwise

(0,90,180,270)


Please use the OF graph DT bindings (a.k.a. ports) to describe the
connection between the panel and its source.


I am afraid that I do not understand this request. What would the source
of the panel be? There is nothing like a SoC LCD controller that is
driving this panel.


My bad, I should have read the panel datasheet before replying :-S Please
ignore this comment.


+Example:
+   display@0{
+   compatible = "lego,ev3-lcd";
+   reg = <0>;
+   spi-max-frequency = <1000>;
+   dc-gpios = < 43 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 80 GPIO_ACTIVE_HIGH>;
+   };




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

[RFC] drm/fb: Propagate physical display dimensions to fbdev

[David Lechner]

fbdev has a place for the physical width and height of a display. I would
like to have this information available to userspace. This patch works for me,
but I have a strong suspicion that this is not the "right way".

Any suggestions on how to get the proper struct drm_display_info here
rather than assuming the first connector one is valid? I don't see an obvious
way to do this.
---
 drivers/gpu/drm/drm_fb_helper.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 574af01..ff422da 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1768,8 +1768,14 @@ void drm_fb_helper_fill_var(struct fb_info *info, struct 
drm_fb_helper *fb_helpe
info->var.xoffset = 0;
info->var.yoffset = 0;
info->var.activate = FB_ACTIVATE_NOW;
-   info->var.height = -1;
-   info->var.width = -1;
+
+   if (fb_helper->connector_count) {
+   info->var.height = 
fb_helper->connector_info[0]->connector->display_info.width_mm;
+   info->var.width = 
fb_helper->connector_info[0]->connector->display_info.height_mm;
+   } else {
+   info->var.height = -1;
+   info->var.width = -1;
+   }
 
switch (fb->format->depth) {
case 8:
-- 
2.7.4

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

[PATCH] drm/fb-helper: pass physical dimensions to fbdev

[David Lechner]

The fbdev subsystem has a place for physical dimensions (width and height
in mm) that is readable by userspace. Since DRM also knows these
dimensions, pass this information to the fbdev device.

Signed-off-by: David Lechner <da...@lechnology.com>
---
 drivers/gpu/drm/drm_fb_helper.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 574af01..07a6621 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1759,6 +1759,7 @@ void drm_fb_helper_fill_var(struct fb_info *info, struct 
drm_fb_helper *fb_helpe
uint32_t fb_width, uint32_t fb_height)
 {
struct drm_framebuffer *fb = fb_helper->fb;
+   int i;
 
info->pseudo_palette = fb_helper->pseudo_palette;
info->var.xres_virtual = fb->width;
@@ -1771,6 +1772,18 @@ void drm_fb_helper_fill_var(struct fb_info *info, struct 
drm_fb_helper *fb_helpe
info->var.height = -1;
info->var.width = -1;
 
+   drm_fb_helper_for_each_connector(fb_helper, i) {
+   struct drm_connector *connector =
+   fb_helper->connector_info[i]->connector;
+
+   /* use the first connected connector for the physical 
dimensions */
+   if (connector->status == connector_status_connected) {
+   info->var.height = connector->display_info.width_mm;
+   info->var.width = connector->display_info.height_mm;
+   break;
+   }
+   }
+
switch (fb->format->depth) {
case 8:
info->var.red.offset = 0;
-- 
2.7.4

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

Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display

[David Lechner]

On 07/30/2017 12:14 PM, Noralf Trønnes wrote:


Den 29.07.2017 21.40, skrev David Lechner:

On 07/29/2017 02:17 PM, David Lechner wrote:
The goal of this series is to get the built-in LCD of the LEGO 
MINDSTORMS EV3
working. But, most of the content here is building up the 
infrastructure to do

that.



Some general comments/questions:

I have noticed that DRM doesn't really have support for monochrome 
displays. I'm guessing that is because no one really uses them anymore?




The repaper driver was the first monochrome drm driver and I chose to
present it to userspace as XRGB and convert it to monochrome.
The reason for this is that everything, libraries, apps, plymouth (boot
splash, no rgb565) supports it. I didn't see any point in adding a new
monochrome drm format that didn't have, or probably wouldn't get
userspace support (by libraries at least). The application of course
needs to know this to get a good result.

tinydrm_xrgb_to_gray8() does the conversion:
https://cgit.freedesktop.org/drm/drm-misc/commit/drivers/gpu/drm/tinydrm?id=379ea9a1a59a5a32c8db6f164e80a3fd00cb3781 



The LEGO EV3 display is just an LCD (not the backlit kind). It has two 
modes of operation. It can to 2bbp grayscale or it can do 1bpp 
monochrome. The grayscale isn't the best (looks splotchy in places), 
so it would be nice to be able to choose between these two modes. How 
would I implement something like that?




Do you expect anyone to use grayscale if it doesn't look good?
Maybe better to add it later if there's a demand for it.


I don't expect many people to use it at all. The people that do will be 
hackers like me that want to see what it is capable of, so I think I 
will keep it grayscale by default.




Also, how can I indicate to userspace that this display really is 
monochrome/grayscale since the reported color depth 16bpp?




There isn't unless we add formats for it.
Since this display is in a Lego piece, doesn't it have custom userspace
that already know it's monochrome?


The official LEGO software is like this, yes. But I am working on a 
project that supports other LEGO compatible devices that have color 
screens, so the same software needs to be able to detect at runtime 
which type of screen it is using. Currently I have a plain fbdev driver 
that provides FB_VISUAL_MONO10 for the EV3 display and so the software 
knows when it has a monochrome screen and when it doesn't. But since 
plain fbdev drivers can't be accepted into mainline, I need to find a 
different way to detect what type of screen this is so that my graphics 
library can treat it differently.




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

Re: [PATCH] drm/fb-helper: pass physical dimensions to fbdev

[David Lechner]

On 08/02/2017 04:46 AM, Daniel Vetter wrote:

On Tue, Aug 01, 2017 at 10:26:41AM -0500, David Lechner wrote:

The fbdev subsystem has a place for physical dimensions (width and height
in mm) that is readable by userspace. Since DRM also knows these
dimensions, pass this information to the fbdev device.

Signed-off-by: David Lechner <da...@lechnology.com>


Still in the wrong function. Also please add some notation about what you
changed when resubmitting a patch (it took me a while to remember that I
replied to you already). That makes patch reviewing more efficient.



Sorry for being so dense. :-/

I did read your first reply at least 10 times. All of the terminology is 
foreign to me, but after sleeping on it a few days, I think it is slowly 
soaking into my brain.


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

Re: [PATCH v2 2/4] drm/tinydrm: add support for LEGO MINDSTORMS EV3 LCD

[David Lechner]

On 08/02/2017 08:03 AM, Noralf Trønnes wrote:



Please use tinydrm_xrgb_to_gray8().


I considered this, but is seems excessive to loop through the entire fb 
twice just to make a 4x6 cursor blink.



You should use this function to enable the regulator and init the
controller. Don't look at mi0283qt it should have been fixed.


ACK. But this is why I was not keen on writing a standalone driver. I 
know some things about kernel development, but not everything. How am I 
supposed to know what is OK to copy from other drivers and what is not? 
And if I am going to be put down as the maintainer of this driver, it 
bothers me that I don't know so much about how it all works.




Why 2 emulation formats?
I chose DRM_FORMAT_XRGB since I expected everything to support it.
Please use only that.


Because my graphics library currently does not work with XRGB. ;-)

I can fix the graphics library and drop the RGB565 format in the kernel 
driver.



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

Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display

[David Lechner]

On 08/02/2017 03:05 AM, Noralf Trønnes wrote:


Den 02.08.2017 00.26, skrev David Lechner:

On 08/01/2017 01:08 PM, Noralf Trønnes wrote:

(cc: Daniel Vetter)


Den 01.08.2017 18.51, skrev David Lechner:

On 07/30/2017 12:14 PM, Noralf Trønnes wrote:


Den 29.07.2017 21.40, skrev David Lechner:

On 07/29/2017 02:17 PM, David Lechner wrote:
The goal of this series is to get the built-in LCD of the LEGO 
MINDSTORMS EV3
working. But, most of the content here is building up the 
infrastructure to do

that.



Some general comments/questions:

I have noticed that DRM doesn't really have support for monochrome 
displays. I'm guessing that is because no one really uses them 
anymore?




The repaper driver was the first monochrome drm driver and I chose to
present it to userspace as XRGB and convert it to monochrome.
The reason for this is that everything, libraries, apps, plymouth 
(boot

splash, no rgb565) supports it. I didn't see any point in adding a new
monochrome drm format that didn't have, or probably wouldn't get
userspace support (by libraries at least). The application of course
needs to know this to get a good result.

tinydrm_xrgb_to_gray8() does the conversion:
https://cgit.freedesktop.org/drm/drm-misc/commit/drivers/gpu/drm/tinydrm?id=379ea9a1a59a5a32c8db6f164e80a3fd00cb3781 



The LEGO EV3 display is just an LCD (not the backlit kind). It has 
two modes of operation. It can to 2bbp grayscale or it can do 1bpp 
monochrome. The grayscale isn't the best (looks splotchy in 
places), so it would be nice to be able to choose between these 
two modes. How would I implement something like that?




Do you expect anyone to use grayscale if it doesn't look good?
Maybe better to add it later if there's a demand for it.


I don't expect many people to use it at all. The people that do will 
be hackers like me that want to see what it is capable of, so I 
think I will keep it grayscale by default.




It looks like the best way to satisfy your needs is to add specific 
formats.


Video for Linux have these:

include/uapi/linux/videodev2.h

/* Grey formats */
#define V4L2_PIX_FMT_GREYv4l2_fourcc('G', 'R', 'E', 'Y') /* 8 
Greyscale */
#define V4L2_PIX_FMT_Y4  v4l2_fourcc('Y', '0', '4', ' ') /* 4 
Greyscale */
#define V4L2_PIX_FMT_Y6  v4l2_fourcc('Y', '0', '6', ' ') /* 6 
Greyscale */
#define V4L2_PIX_FMT_Y10 v4l2_fourcc('Y', '1', '0', ' ') /* 10 
Greyscale */
#define V4L2_PIX_FMT_Y12 v4l2_fourcc('Y', '1', '2', ' ') /* 12 
Greyscale */
#define V4L2_PIX_FMT_Y16 v4l2_fourcc('Y', '1', '6', ' ') /* 16 
Greyscale */
#define V4L2_PIX_FMT_Y16_BE  v4l2_fourcc_be('Y', '1', '6', ' ') /* 16 
Greyscale BE  */



Maybe we can add formats like these:

include/uapi/drm/drm_fourcc.h

#define DRM_FORMAT_MONOfourcc_code('Y', '0', '1', ' ') /* [0] 
Monochrome */

or
#define DRM_FORMAT_Y1fourcc_code('Y', '0', '1', ' ') /* [0] 
Monochrome */


#define DRM_FORMAT_Y2fourcc_code('Y', '0', '2', ' ') /* [1:0] 
Greyscale */


Daniel, what do you think?


2 of the first 3 tinydrm drivers are monochrome (and I would like to 
write a driver for the Seeed/Grove I2C OLED displays which are also 
monochrome), so I think the 1bpp modes would definitely be useful. I 
think there is enough userspace code still around that knows about 
FB_VISUAL_MONO01 and FB_VISUAL_MONO10 that could use these.




Can you elaborate, would you use the display trough monochrome fbdev
or through drm?


I have a small collection of programs and libraries that work using 
monochrome fbdev. I would like to just keep using them without having to 
convert everything to drm.



I don't think a Y02 mode would be useful though. There is pretty much 
nothing out there (that I could find) that uses such a mode.


A Y08 mode for 8bpp grayscale would be useful though. This is another 
more commonly used format.




Another source of fourcc's is FFmpeg which has these:

 { AV_PIX_FMT_GRAY8,MKTAG('Y', '8', '0', '0') },
 { AV_PIX_FMT_GRAY8,MKTAG('Y', '8', ' ', ' ') },
 { AV_PIX_FMT_GRAY8,   MKTAG('G', 'R', 'E', 'Y') },

 { AV_PIX_FMT_MONOWHITE,MKTAG('B', '1', 'W', '0') },
 { AV_PIX_FMT_MONOBLACK,MKTAG('B', '0', 'W', '1') },

AV_PIX_FMT_GRAY8
Y , 8bpp.
AV_PIX_FMT_MONOWHITE
Y , 1bpp, 0 is white, 1 is black,
 in each byte pixels are ordered from the msb to the lsb.
AV_PIX_FMT_MONOBLACK
Y , 1bpp, 0 is black, 1 is white,
 in each byte pixels are ordered from the msb to the lsb.


__drm_format_info() provides details about formats:
 { .format = DRM_FORMAT_MONO,.depth = 1,  .num_planes = 1, .cpp 
= { 0, 0, 0 }, .hsub = 1, .vsub = 1 },
 { .format = DRM_FORMAT_GREY,.depth = 8,  .num_planes = 1, .cpp 
= { 1, 0, 0 }, .hsub = 1, .vsub = 1 },


framebuffer_check() and drm_fb_cma_create_with_funcs() use cpp for
validation and they don't expect it to be zero.


Noralf.





Also, how can I indicate to userspace that this display really is 
monochrome/grayscale

[PATCH] drm/fb: Fix pointer dereference before null check.

[David Lechner]

fb_crtc is used before a null check, so move the use after the null check.

This was just identified by inspection. I haven't actually observed a crash
here, so it is possible that the null check could be unnecessary.

Signed-off-by: David Lechner <da...@lechnology.com>
---
 drivers/gpu/drm/drm_fb_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 2cc28f0..2d3f93e 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2424,9 +2424,9 @@ static void drm_setup_crtcs(struct drm_fb_helper 
*fb_helper,
struct drm_display_mode *mode = modes[i];
struct drm_fb_helper_crtc *fb_crtc = crtcs[i];
struct drm_fb_offset *offset = [i];
-   struct drm_mode_set *modeset = _crtc->mode_set;
 
if (mode && fb_crtc) {
+   struct drm_mode_set *modeset = _crtc->mode_set;
struct drm_connector *connector =
fb_helper->connector_info[i]->connector;
 
-- 
2.7.4

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

Re: [PATCH v1 1/2] uapi: drm: Add fourcc codes needed by Xilinx Video IP

[David Lechner]

On 08/07/2017 10:13 AM, Philipp Zabel wrote:

Hi Jeffrey,

On Fri, 2017-08-04 at 11:49 -0700, Jeffrey Mouroux wrote:

The Xilinx Video Mixer andn Xilinx Video Framebuffer DMA IP
support video memory formats that are not represented in the
current DRM fourcc library.  This patch adds those missing
fourcc codes.

Signed-off-by: Jeffrey Mouroux 
---
  include/uapi/drm/drm_fourcc.h | 9 +
  1 file changed, 9 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index ef20abb..3e80130 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -112,6 +112,14 @@
  #define DRM_FORMAT_VYUY   fourcc_code('V', 'Y', 'U', 'Y') /* 
[31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
  
  #define DRM_FORMAT_AYUV		fourcc_code('A', 'Y', 'U', 'V') /* [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */

+#define DRM_FORMAT_AVUYfourcc_code('A', 'V', 'U', 'Y') /* 
[31:0] A:Cr:Cb:Y 8:8:8:8 little endian */
+#define DRM_FORMAT_VUY888  fourcc_code('V', 'U', '2', '4') /* [23:0] 
Cr:Cb:Y little endian */
+#define DRM_FORMAT_XVUYfourcc_code('X', 'V', '2', '4') /* [31:0] 
x:Cr:Cb:Y 8:8:8:8 little endian */
+#define DRM_FORMAT_XVUY2101010 fourcc_code('X', 'V', '3', '0') /* [31:0] 
x:Cr:Cb:Y 2:10:10:10 little endian */
+
+/* Grey scale */
+#define DRM_FORMAT_Y8  fourcc_code('G', 'R', 'E', 'Y') /* 8  Greyscale 
*/


That would be useful for me as well.


I'm also interested in 8-bit grayscale. I applied these patches then 
naively tried to add support for DRM_FORMAT_Y8 to a driver I am working on.


diff --git a/drivers/gpu/drm/tinydrm/st7586.c 
b/drivers/gpu/drm/tinydrm/st7586.c

index 1b39d3f..f6db7be 100644
--- a/drivers/gpu/drm/tinydrm/st7586.c
+++ b/drivers/gpu/drm/tinydrm/st7586.c
@@ -56,6 +56,34 @@

 static const u8 st7586_lookup[] = { 0x7, 0x4, 0x2, 0x0 };

+static void st7586_gray8_to_gray332(u8 *dst, void *vaddr,
+   struct drm_framebuffer *fb,
+   struct drm_clip_rect *clip)
+{
...
+}
+
 static void st7586_xrgb_to_gray332(u8 *dst, void *vaddr,
   struct drm_framebuffer *fb,
   struct drm_clip_rect *clip)
@@ -98,7 +126,14 @@ static int st7586_buf_copy(void *dst, struct 
drm_framebuffer *fb,

return ret;
}

-   st7586_xrgb_to_gray332(dst, src, fb, clip);
+   switch(fb->format->format) {
+   case DRM_FORMAT_Y8:
+   st7586_gray8_to_gray332(dst, src, fb, clip);
+   break;
+   case DRM_FORMAT_XRGB:
+   st7586_xrgb_to_gray332(dst, src, fb, clip);
+   break;
+   }

if (import_attach)
ret = dma_buf_end_cpu_access(import_attach->dmabuf,
@@ -260,6 +295,7 @@ static void st7586_pipe_disable(struct 
drm_simple_display_pipe *pipe)

 }

 static const u32 st7586_formats[] = {
+   DRM_FORMAT_Y8,
DRM_FORMAT_XRGB,
 };

@@ -290,7 +326,7 @@ static int st7586_init(struct device *dev, struct 
mipi_dbi *mipi,

if (ret)
return ret;

-   tdev->drm->mode_config.preferred_depth = 32;
+   tdev->drm->mode_config.preferred_depth = 8;
mipi->rotation = rotation;

drm_mode_config_reset(tdev->drm);


But it just caused a crash. (Note: had to set fb.lockless_register_fb=1 
in the kernel command line to get stack trace.)



Console: switching to colour frame buffer device 22x16
Unable to handle kernel paging request at virtual address c4bd4158
pgd = c2e0c000
[c4bd4158] *pgd=c2dfd811, *pte=, *ppte=
Internal error: Oops: 7 [#1] PREEMPT ARM
Modules linked in: st7586(+) mipi_dbi tinydrm drm_kms_helper syscopyarea 
sysfill
rect sysimgblt fb_sys_fops ofpart drm backlight m25p80 spi_nor 
ti_ads7950 indust
rialio_triggered_buffer mtd da8xx kfifo_buf phy_generic pwm_beeper 
ohci_da8xx mu
sb_hdrc ohci_hcd usbcore pwm_tiehrpwm davinci_wdt phy_da8xx_usb 
pinctrl_da850_pu
pd rtc_omap leds_gpio led_class lego_ev3_battery industrialio tun 
libcomposite c

onfigfs udc_core usb_common autofs4
CPU: 0 PID: 126 Comm: systemd-udevd Tainted: GW 
4.13.0-rc2-dlech-e

v3+ #486
Hardware name: Generic DA850/OMAP-L138/AM18x
task: c3afd4a0 task.stack: c2d36000
PC is at sys_imageblit+0x278/0x4c8 [sysimgblt]
LR is at 0xc4bd3f40
pc : []lr : []psr: 2013
sp : c2d37810  ip :   fp : c2d37864
r10: 0008  r9 : 0018  r8 : c4bd3f40
r7 : c2d26a42  r6 :   r5 : 0007  r4 : 0008
r3 : 0010  r2 : c4bd4158  r1 : 00b0  r0 : 
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 0005317f  Table: c2e0c000  DAC: 0051
Process systemd-udevd (pid: 126, stack limit = 0xc2d36190)
Stack: (0xc2d37810 to 0xc2d38000)
7800: 02c8 00b2 c4bd4158 
0016
7820:  c2d26a42 c2d378e8 0010 0010 c4bd4158 bf1e6154 

Re: [PATCH v5] drm/fb-helper: pass physical dimensions to fbdev

[David Lechner]

On 08/04/2017 11:25 AM, David Lechner wrote:

The fbdev subsystem has a place for physical dimensions (width and height
in mm) that is readable by userspace. Since DRM also knows these
dimensions, pass this information to the fbdev device.

This has to be done in drm_setup_crtcs_fb() instead of drm_setup_crtcs()
because fb_helper->fbdev may be NULL in drm_setup_crtcs().


Signed-off-by: David Lechner <da...@lechnology.com>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5] drm/fb-helper: pass physical dimensions to fbdev

[David Lechner]

On 08/04/2017 04:53 PM, Laurent Pinchart wrote:

Hi David,

Thank you for the patch.

On Friday 04 Aug 2017 11:25:24 David Lechner wrote:

The fbdev subsystem has a place for physical dimensions (width and height
in mm) that is readable by userspace. Since DRM also knows these
dimensions, pass this information to the fbdev device.


I'm curious, what's your use case for this ? What userspace software do you
use that is still based on fbdev and needs screen dimensions ?



I have dug up an old graphics library called GRX[1] and modernized 
it[2]. So, I am using the screen dimensions to make it DPI-aware so that 
the font on my 2.4" screen looks the same size as my 2.8" screen when 
both are 320x240 pixels. Until this year, all of the displays I have 
only have fbdev drivers.


[1]: http://grx.gnu.de
[2]: https://github.com/ev3dev/grx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 3/6] dt-bindings: add binding for Sitronix ST7586 display panels

[David Lechner]

On 08/04/2017 09:54 AM, Laurent Pinchart wrote:

Hi David,

Thank you for the patch.

On Thursday 03 Aug 2017 17:33:47 David Lechner wrote:

This adds a new binding for Sitronix ST7586 display panels.

Using lego as the vendor prefix in the compatible string because the display
panel I am working with is an integral part of the LEGO MINDSTORMS EV3.

Signed-off-by: David Lechner <da...@lechnology.com>
---
  .../bindings/display/sitronix,st7586.txt   | 26 +++
  1 file changed, 26 insertions(+)
  create mode 100644
Documentation/devicetree/bindings/display/sitronix,st7586.txt

diff --git a/Documentation/devicetree/bindings/display/sitronix,st7586.txt
b/Documentation/devicetree/bindings/display/sitronix,st7586.txt new file
mode 100644
index 000..dfb0b7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sitronix,st7586.txt
@@ -0,0 +1,26 @@
+Sitronix ST7586 display panel
+
+Required properties:
+- compatible:  "lego,ev3-lcd".
+
+The node for this driver must be a child node of a SPI controller, hence
+all mandatory properties described in ../spi/spi-bus.txt must be specified.
+
+Optional properties:
+- dc-gpios:D/C pin. The presence/absence of this GPIO determines
+   the panel interface operation mode (IF[3:1] pins):
+   - present: IF=011 4-wire 8-bit data serial interface
+   - absent:  IF=010 3-wire 9-bit data serial interface


How does this work ? Do you have a single GPIO on your system connected to
IF[1], with IF[3:2] hardwired to 01 ?


LEGO has not made the internals of the display publicly available, so I 
cannot say for sure. But I assume that IF[3:1] is hardwired to 011. This 
causes pin D1 to assigned to the signal A0, which is what we are calling 
the dc gpio here.


If IF[3:1] were hardwired to 010, then pin D1 would be not not used and 
there would be no A0 signal.


So, basically, we can infer the state of IF[3:1] by the fact that we 
have a dc pin or not.





+- reset-gpios: Reset pin
+- power-supply:A regulator node for the supply voltage.
+- backlight:   phandle of the backlight device attached to the panel
+- rotation:panel rotation in degrees counter clockwise (0,90,180,270)


Please use the OF graph DT bindings (a.k.a. ports) to describe the connection
between the panel and its source.


I am afraid that I do not understand this request. What would the source 
of the panel be? There is nothing like a SoC LCD controller that is 
driving this panel.





+Example:
+   display@0{
+   compatible = "lego,ev3-lcd";
+   reg = <0>;
+   spi-max-frequency = <1000>;
+   dc-gpios = < 43 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 80 GPIO_ACTIVE_HIGH>;
+   };




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

Re: [PATCH v4] drm/fb-helper: pass physical dimensions to fbdev

[David Lechner]

On 08/04/2017 11:22 AM, David Lechner wrote:

The fbdev subsystem has a place for physical dimensions (width and height
in mm) that is readable by userspace. Since DRM also knows these
dimensions, pass this information to the fbdev device.

This has to be done in drm_setup_crtcs_fb() instead of drm_setup_crtcs()
because fb_helper->fbdev may be NULL in drm_setup_crtcs().
---

v1 changes (from RFC):
* Use loop to get info from first connected connector instead of just the
   first connector.

v2 changes:
* Update width in height in drm_setup_crtcs() also to handle hotplug events.

v3 changes:
* Add new patch to handle post-fb allocation crcts setup.
* Use new drm_setup_crtcs_fb() function from new patch to avoid duplication
   of code.

v4 changes:
* Drop patch "drm/fb-helper: add new drm_setup_crtcs_fb() function" since it
   has been applied already.
* Add mutex lock.

  drivers/gpu/drm/drm_fb_helper.c | 17 +++--
  1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 4447a28..24787d6 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1882,8 +1882,6 @@ void drm_fb_helper_fill_var(struct fb_info *info, struct 
drm_fb_helper *fb_helpe
info->var.xoffset = 0;
info->var.yoffset = 0;
info->var.activate = FB_ACTIVATE_NOW;
-   info->var.height = -1;
-   info->var.width = -1;
  
  	switch (fb->format->depth) {

case 8:
@@ -2435,11 +2433,26 @@ static void drm_setup_crtcs(struct drm_fb_helper 
*fb_helper,
   */
  static void drm_setup_crtcs_fb(struct drm_fb_helper *fb_helper)
  {
+   struct fb_info *info = fb_helper->fbdev;
int i;
  
  	for (i = 0; i < fb_helper->crtc_count; i++)

if (fb_helper->crtc_info[i].mode_set.num_connectors)
fb_helper->crtc_info[i].mode_set.fb = fb_helper->fb;
+
+   mutex_lock(_helper->dev->mode_config.mutex);
+   drm_fb_helper_for_each_connector(fb_helper, i) {
+   struct drm_connector *connector =
+   fb_helper->connector_info[i]->connector;
+
+   /* use first connected connector for the physical dimensions */
+   if (connector->status == connector_status_connected) {
+   info->var.height = connector->display_info.width_mm;
+   info->var.width = connector->display_info.height_mm;


Oops. height = width!


+   break;
+   }
+   }
+   mutex_unlock(_helper->dev->mode_config.mutex);
  }
  
  /* Note: Drops fb_helper->lock before returning. */




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

Re: [PATCH v3 3/6] dt-bindings: add binding for Sitronix ST7586 display panels

[David Lechner]

On 08/04/2017 04:48 AM, Noralf Trønnes wrote:


Den 04.08.2017 00.33, skrev David Lechner:

This adds a new binding for Sitronix ST7586 display panels.

Using lego as the vendor prefix in the compatible string because the 
display

panel I am working with is an integral part of the LEGO MINDSTORMS EV3.


Is this display available outside of this Lego part?

No, it is not.


If not you can remove the properties you don't need for this particular
display setup. Another st7586 display with a different panel would need
a different initialization sequence and compatible string, so we can
add properties when/if that happens.


OK. so I will drop power-supply and backlight.

Should I remove these from the driver as well? There are some panels out 
there that could use them.[1]


[1]: 
http://www.buydisplay.com/download/manual/ERC240160-1_Series_Datasheet.pdf




Noralf.


Signed-off-by: David Lechner <da...@lechnology.com>
---
  .../bindings/display/sitronix,st7586.txt   | 26 
++

  1 file changed, 26 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/sitronix,st7586.txt


diff --git 
a/Documentation/devicetree/bindings/display/sitronix,st7586.txt 
b/Documentation/devicetree/bindings/display/sitronix,st7586.txt

new file mode 100644
index 000..dfb0b7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sitronix,st7586.txt
@@ -0,0 +1,26 @@
+Sitronix ST7586 display panel
+
+Required properties:
+- compatible:"lego,ev3-lcd".
+
+The node for this driver must be a child node of a SPI controller, hence
+all mandatory properties described in ../spi/spi-bus.txt must be 
specified.

+
+Optional properties:
+- dc-gpios:D/C pin. The presence/absence of this GPIO determines
+the panel interface operation mode (IF[3:1] pins):
+- present: IF=011 4-wire 8-bit data serial interface
+- absent:  IF=010 3-wire 9-bit data serial interface
+- reset-gpios:Reset pin
+- power-supply:A regulator node for the supply voltage.
+- backlight:phandle of the backlight device attached to the panel
+- rotation:panel rotation in degrees counter clockwise 
(0,90,180,270)

+
+Example:
+display@0{
+compatible = "lego,ev3-lcd";
+reg = <0>;
+spi-max-frequency = <1000>;
+dc-gpios = < 43 GPIO_ACTIVE_HIGH>;
+reset-gpios = < 80 GPIO_ACTIVE_HIGH>;
+};




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

[PATCH v4] drm/fb-helper: pass physical dimensions to fbdev

[David Lechner]

The fbdev subsystem has a place for physical dimensions (width and height
in mm) that is readable by userspace. Since DRM also knows these
dimensions, pass this information to the fbdev device.

This has to be done in drm_setup_crtcs_fb() instead of drm_setup_crtcs()
because fb_helper->fbdev may be NULL in drm_setup_crtcs().
---

v1 changes (from RFC):
* Use loop to get info from first connected connector instead of just the
  first connector.

v2 changes:
* Update width in height in drm_setup_crtcs() also to handle hotplug events.

v3 changes:
* Add new patch to handle post-fb allocation crcts setup.
* Use new drm_setup_crtcs_fb() function from new patch to avoid duplication
  of code.

v4 changes:
* Drop patch "drm/fb-helper: add new drm_setup_crtcs_fb() function" since it
  has been applied already.
* Add mutex lock.

 drivers/gpu/drm/drm_fb_helper.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 4447a28..24787d6 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1882,8 +1882,6 @@ void drm_fb_helper_fill_var(struct fb_info *info, struct 
drm_fb_helper *fb_helpe
info->var.xoffset = 0;
info->var.yoffset = 0;
info->var.activate = FB_ACTIVATE_NOW;
-   info->var.height = -1;
-   info->var.width = -1;
 
switch (fb->format->depth) {
case 8:
@@ -2435,11 +2433,26 @@ static void drm_setup_crtcs(struct drm_fb_helper 
*fb_helper,
  */
 static void drm_setup_crtcs_fb(struct drm_fb_helper *fb_helper)
 {
+   struct fb_info *info = fb_helper->fbdev;
int i;
 
for (i = 0; i < fb_helper->crtc_count; i++)
if (fb_helper->crtc_info[i].mode_set.num_connectors)
fb_helper->crtc_info[i].mode_set.fb = fb_helper->fb;
+
+   mutex_lock(_helper->dev->mode_config.mutex);
+   drm_fb_helper_for_each_connector(fb_helper, i) {
+   struct drm_connector *connector =
+   fb_helper->connector_info[i]->connector;
+
+   /* use first connected connector for the physical dimensions */
+   if (connector->status == connector_status_connected) {
+   info->var.height = connector->display_info.width_mm;
+   info->var.width = connector->display_info.height_mm;
+   break;
+   }
+   }
+   mutex_unlock(_helper->dev->mode_config.mutex);
 }
 
 /* Note: Drops fb_helper->lock before returning. */
-- 
2.7.4

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

[PATCH v5] drm/fb-helper: pass physical dimensions to fbdev

[David Lechner]

The fbdev subsystem has a place for physical dimensions (width and height
in mm) that is readable by userspace. Since DRM also knows these
dimensions, pass this information to the fbdev device.

This has to be done in drm_setup_crtcs_fb() instead of drm_setup_crtcs()
because fb_helper->fbdev may be NULL in drm_setup_crtcs().
---

v1 changes (from RFC):
* Use loop to get info from first connected connector instead of just the
  first connector.

v2 changes:
* Update width in height in drm_setup_crtcs() also to handle hotplug events.

v3 changes:
* Add new patch to handle post-fb allocation crcts setup.
* Use new drm_setup_crtcs_fb() function from new patch to avoid duplication
  of code.

v4 changes:
* Drop patch "drm/fb-helper: add new drm_setup_crtcs_fb() function" since it
  has been applied already.
* Add mutex lock.

v5 changes:
* Fix height = width mismatch.

 drivers/gpu/drm/drm_fb_helper.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 4447a28..24787d6 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1882,8 +1882,6 @@ void drm_fb_helper_fill_var(struct fb_info *info, struct 
drm_fb_helper *fb_helpe
info->var.xoffset = 0;
info->var.yoffset = 0;
info->var.activate = FB_ACTIVATE_NOW;
-   info->var.height = -1;
-   info->var.width = -1;
 
switch (fb->format->depth) {
case 8:
@@ -2435,11 +2433,26 @@ static void drm_setup_crtcs(struct drm_fb_helper 
*fb_helper,
  */
 static void drm_setup_crtcs_fb(struct drm_fb_helper *fb_helper)
 {
+   struct fb_info *info = fb_helper->fbdev;
int i;
 
for (i = 0; i < fb_helper->crtc_count; i++)
if (fb_helper->crtc_info[i].mode_set.num_connectors)
fb_helper->crtc_info[i].mode_set.fb = fb_helper->fb;
+
+   mutex_lock(_helper->dev->mode_config.mutex);
+   drm_fb_helper_for_each_connector(fb_helper, i) {
+   struct drm_connector *connector =
+   fb_helper->connector_info[i]->connector;
+
+   /* use first connected connector for the physical dimensions */
+   if (connector->status == connector_status_connected) {
+   info->var.width = connector->display_info.width_mm;
+   info->var.height = connector->display_info.height_mm;
+   break;
+   }
+   }
+   mutex_unlock(_helper->dev->mode_config.mutex);
 }
 
 /* Note: Drops fb_helper->lock before returning. */
-- 
2.7.4

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

Re: [PATCH v3 4/6] drm/tinydrm: add support for LEGO MINDSTORMS EV3 LCD

[David Lechner]

On 08/05/2017 01:19 PM, Noralf Trønnes wrote:


Den 04.08.2017 00.33, skrev David Lechner:

+
+buf = kmalloc(len, GFP_KERNEL);
+if (!buf)
+return;
+
+tinydrm_xrgb_to_gray8(buf, vaddr, fb, clip);
+src = buf;
+
+for (y = clip->y1; y < clip->y2; y++) {
+for (x = clip->x1; x < clip->x2; x += 3) {
+val = *src++ & 0xc0;
+if (val & 0xc0)
+val |= 0x20;
+val |= (*src++ & 0xc0) >> 3;
+if (val & 0x18)
+val |= 0x04;
+val |= *src++ >> 6;
+*dst++ = ~val;


I don't understand how this pixel packing matches the one described in
the datasheet. Why do you flip the bits at the end?



I a trying to be too clever. :-)

Here is the comment I will add to the next revision:

/*
 * The ST7586 controller has an unusual pixel format where 2bpp 
grayscale is
 * packed 3 pixels per byte with the first two pixels using 3 bits and 
the 3rd

 * pixel using only 2 bits.
 *
 * |  D7  |  D6  |  D5  ||  D1  |  D0  || 2bpp |
 * | (D4) | (D3) | (D2) ||  |  || GRAY |
 * +--+--+--++--+--++--+
 * |  1   |  1   |  1   ||  1   |  1   || 0  0 | black
 * |  1   |  0   |  0   ||  1   |  0   || 0  1 | dark gray
 * |  0   |  1   |  0   ||  0   |  1   || 1  0 | light gray
 * |  0   |  0   |  0   ||  0   |  0   || 1  1 | white
 */


As you can see, in the controller DRAM 1's are black and 0's are white, 
but in the kernel, it is the opposite. Also, if you look at the truth 
table, you can see that the extra 3rd bit has the pattern if D7 == 0 or 
D6 == 0 then D5 is zero.


I suppose it could be better to do this with a lookup table:

static const u8 st7586_lookup[] = { 0x7, 0x4, 0x2, 0x0 };

...

for (y = clip->y1; y < clip->y2; y++) {
for (x = clip->x1; x < clip->x2; x += 3) {
val = st7586_lookup[*src++ >> 6] << 5;
val |= st7586_lookup[*src++ >> 6] << 2;
val |= st7586_lookup[*src++ >> 6] >> 1;
*dst++ = val;
}
}


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

[PATCH v4 2/5] dt-bindings: add binding for Sitronix ST7586 display panels

[David Lechner]

This adds a new binding for Sitronix ST7586 display panels.

Using lego as the vendor prefix in the compatible string because the display
panel I am working with is an integral part of the LEGO MINDSTORMS EV3.

Signed-off-by: David Lechner <da...@lechnology.com>
---

v4 changes:
* Dropped optional properties and only use pins actually used on LEGO EV3.
* Rename dc to a0 since that is what is on the datasheet/LEGO schematic.


 .../bindings/display/sitronix,st7586.txt   | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/sitronix,st7586.txt

diff --git a/Documentation/devicetree/bindings/display/sitronix,st7586.txt 
b/Documentation/devicetree/bindings/display/sitronix,st7586.txt
new file mode 100644
index 000..1d0dad1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sitronix,st7586.txt
@@ -0,0 +1,22 @@
+Sitronix ST7586 display panel
+
+Required properties:
+- compatible:  "lego,ev3-lcd".
+- a0-gpios:The A0 signal (since this binding is for serial mode, this is
+the pin labeled D1 on the controller, not the pin labeled A0)
+- reset-gpios: Reset pin
+
+The node for this driver must be a child node of a SPI controller, hence
+all mandatory properties described in ../spi/spi-bus.txt must be specified.
+
+Optional properties:
+- rotation:panel rotation in degrees counter clockwise (0,90,180,270)
+
+Example:
+   display@0{
+   compatible = "lego,ev3-lcd";
+   reg = <0>;
+   spi-max-frequency = <1000>;
+   a0-gpios = < 43 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 80 GPIO_ACTIVE_HIGH>;
+   };
-- 
2.7.4

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

[PATCH v4 1/5] drm/tinydrm: Generalize tinydrm_xrgb8888_to_gray8()

[David Lechner]

This adds parameters for vaddr and clip to tinydrm_xrgb_to_gray8() to
make it more generic.

dma_buf_{begin,end}_cpu_access() are moved out to the repaper driver.

Return type is change to void to simplify error handling by callers.

Signed-off-by: David Lechner <da...@lechnology.com>
---

v4 changes:
* Change return type to void.


 drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 42 +-
 drivers/gpu/drm/tinydrm/repaper.c  | 28 +++--
 include/drm/tinydrm/tinydrm-helpers.h  |  3 +-
 3 files changed, 41 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index 75808bb..bd6cce0 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -185,7 +185,9 @@ EXPORT_SYMBOL(tinydrm_xrgb_to_rgb565);
 /**
  * tinydrm_xrgb_to_gray8 - Convert XRGB to grayscale
  * @dst: 8-bit grayscale destination buffer
+ * @vaddr: XRGB source buffer
  * @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
  *
  * Drm doesn't have native monochrome or grayscale support.
  * Such drivers can announce the commonly supported XR24 format to userspace
@@ -195,41 +197,31 @@ EXPORT_SYMBOL(tinydrm_xrgb_to_rgb565);
  * where 1 means foreground color and 0 background color.
  *
  * ITU BT.601 is used for the RGB -> luma (brightness) conversion.
- *
- * Returns:
- * Zero on success, negative error code on failure.
  */
-int tinydrm_xrgb_to_gray8(u8 *dst, struct drm_framebuffer *fb)
+void tinydrm_xrgb_to_gray8(u8 *dst, void *vaddr, struct drm_framebuffer 
*fb,
+  struct drm_clip_rect *clip)
 {
-   struct drm_gem_cma_object *cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
-   struct dma_buf_attachment *import_attach = cma_obj->base.import_attach;
-   unsigned int x, y, pitch = fb->pitches[0];
-   int ret = 0;
+   unsigned int len = (clip->x2 - clip->x1) * sizeof(u32);
+   unsigned int x, y;
void *buf;
u32 *src;
 
if (WARN_ON(fb->format->format != DRM_FORMAT_XRGB))
-   return -EINVAL;
+   return;
/*
 * The cma memory is write-combined so reads are uncached.
 * Speed up by fetching one line at a time.
 */
-   buf = kmalloc(pitch, GFP_KERNEL);
+   buf = kmalloc(len, GFP_KERNEL);
if (!buf)
-   return -ENOMEM;
-
-   if (import_attach) {
-   ret = dma_buf_begin_cpu_access(import_attach->dmabuf,
-  DMA_FROM_DEVICE);
-   if (ret)
-   goto err_free;
-   }
+   return;
 
-   for (y = 0; y < fb->height; y++) {
-   src = cma_obj->vaddr + (y * pitch);
-   memcpy(buf, src, pitch);
+   for (y = clip->y1; y < clip->y2; y++) {
+   src = vaddr + (y * fb->pitches[0]);
+   src += clip->x1;
+   memcpy(buf, src, len);
src = buf;
-   for (x = 0; x < fb->width; x++) {
+   for (x = clip->x1; x < clip->x2; x++) {
u8 r = (*src & 0x00ff) >> 16;
u8 g = (*src & 0xff00) >> 8;
u8 b =  *src & 0x00ff;
@@ -240,13 +232,7 @@ int tinydrm_xrgb_to_gray8(u8 *dst, struct 
drm_framebuffer *fb)
}
}
 
-   if (import_attach)
-   ret = dma_buf_end_cpu_access(import_attach->dmabuf,
-DMA_FROM_DEVICE);
-err_free:
kfree(buf);
-
-   return ret;
 }
 EXPORT_SYMBOL(tinydrm_xrgb_to_gray8);
 
diff --git a/drivers/gpu/drm/tinydrm/repaper.c 
b/drivers/gpu/drm/tinydrm/repaper.c
index 3343d3f..30dc97b 100644
--- a/drivers/gpu/drm/tinydrm/repaper.c
+++ b/drivers/gpu/drm/tinydrm/repaper.c
@@ -18,6 +18,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -525,11 +526,20 @@ static int repaper_fb_dirty(struct drm_framebuffer *fb,
struct drm_clip_rect *clips,
unsigned int num_clips)
 {
+   struct drm_gem_cma_object *cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
+   struct dma_buf_attachment *import_attach = cma_obj->base.import_attach;
struct tinydrm_device *tdev = fb->dev->dev_private;
struct repaper_epd *epd = epd_from_tinydrm(tdev);
+   struct drm_clip_rect clip;
u8 *buf = NULL;
int ret = 0;
 
+   /* repaper can't do partial updates */
+   clip.x1 = 0;
+   clip.x2 = fb->width;
+   clip.y1 = 0;
+   clip.y2 = fb->height;
+
mutex_lock(>dirty_lock);
 
if (!epd->enabled)
@@ -550,9 +560,21 @@ static int repaper_fb_dirty(struct drm_framebuffer *fb,
   

[PATCH v4 0/5] Support for LEGO MINDSTORMS EV3 LCD display

[David Lechner]

The goal of this series is to get the built-in LCD of the LEGO MINDSTORMS EV3
working.

v2 changes:
* Wrote a new driver for ST7586 instead of combining it with existing drivers
* Don't touch MIPI DBI code (other than the patch suggested by Noralf)
* New defconfig patch

v3 changes:
* New patch to generalize tinydrm_xrgb_to_gray8() so that it can be reused.
* Device tree bindings in separate patch.
* Fixed incorrect device tree binding pin descriptions.
* Added MAINTAINERS entry for drivers/gpu/drm/tinydrm/st7586.c.
* Removed "mipi_dbi_" from function names in st7586.c.
* Moved init and fini to pipe_enable and pipe_disable ops.
* Dropped RGB565 format.
* Made adjustments for the fact the controller cannot be read via SPI.
* Dropped st7586.h - values moved into st7586.c.

v4 changes:
* Dropped patch "drm/tinydrm: remove call to mipi_dbi_init()
  from mipi_dbi_spi_init()" since it has been applied.
* correct order for MAINTAINERS entry
* Drop code/dt bindings not used by LEGO EV3 (regulator, backlight, etc)
* Make gpios required
* Use lookup table for pixel packing algorithm
* Don't modify clip when used as function parameter
* Rename dc to a0 since that is what is on the datasheet/LEGO schematic.

David Lechner (5):
  drm/tinydrm: Generalize tinydrm_xrgb_to_gray8()
  dt-bindings: add binding for Sitronix ST7586 display panels
  drm/tinydrm: add support for LEGO MINDSTORMS EV3 LCD
  ARM: dts: da850-lego-ev3: Add node for LCD display
  ARM: davinci_all_defconfig: enable tinydrm and ST7586

 .../bindings/display/sitronix,st7586.txt   |  22 ++
 MAINTAINERS|   6 +
 arch/arm/boot/dts/da850-lego-ev3.dts   |  24 ++
 arch/arm/configs/davinci_all_defconfig |   2 +
 drivers/gpu/drm/tinydrm/Kconfig|  10 +
 drivers/gpu/drm/tinydrm/Makefile   |   1 +
 drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c |  42 +-
 drivers/gpu/drm/tinydrm/repaper.c  |  28 +-
 drivers/gpu/drm/tinydrm/st7586.c   | 428 +
 include/drm/tinydrm/tinydrm-helpers.h  |   3 +-
 10 files changed, 534 insertions(+), 32 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/sitronix,st7586.txt
 create mode 100644 drivers/gpu/drm/tinydrm/st7586.c

-- 
2.7.4

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

[PATCH v4 3/5] drm/tinydrm: add support for LEGO MINDSTORMS EV3 LCD

[David Lechner]

LEGO MINDSTORMS EV3 has an LCD with a ST7586 controller. This adds a new
module for the ST7586 controller with parameters for the LEGO MINDSTORMS
EV3 LCD display.

Signed-off-by: David Lechner <da...@lechnology.com>
---

v4 changes:
* correct order for MAINTAINERS entry
* Drop code not used by LEGO EV3 (regulator, backlight, suspend/resume)
* Make gpios required
* Use lookup table for pixel packing algorithm
* Don't modify clip when used as function parameter
* Use roundup/rounddown macros


 MAINTAINERS  |   6 +
 drivers/gpu/drm/tinydrm/Kconfig  |  10 +
 drivers/gpu/drm/tinydrm/Makefile |   1 +
 drivers/gpu/drm/tinydrm/st7586.c | 428 +++
 4 files changed, 445 insertions(+)
 create mode 100644 drivers/gpu/drm/tinydrm/st7586.c

diff --git a/MAINTAINERS b/MAINTAINERS
index a1e772e..19ca3e6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4380,6 +4380,12 @@ S:   Orphan / Obsolete
 F: drivers/gpu/drm/sis/
 F: include/uapi/drm/sis_drm.h
 
+DRM DRIVER FOR SITRONIX ST7586 PANELS
+M: David Lechner <da...@lechnology.com>
+S: Maintained
+F: drivers/gpu/drm/tinydrm/st7586.c
+F: Documentation/devicetree/bindings/display/st7586.txt
+
 DRM DRIVER FOR TDFX VIDEO CARDS
 S: Orphan / Obsolete
 F: drivers/gpu/drm/tdfx/
diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index f17c3ca..2e790e7 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -32,3 +32,13 @@ config TINYDRM_REPAPER
  2.71" TFT EPD Panel (E2271CS021)
 
  If M is selected the module will be called repaper.
+
+config TINYDRM_ST7586
+   tristate "DRM support for Sitronix ST7586 display panels"
+   depends on DRM_TINYDRM && SPI
+   select TINYDRM_MIPI_DBI
+   help
+ DRM driver for the following Sitronix ST7586 panels:
+ * LEGO MINDSTORMS EV3
+
+ If M is selected the module will be called st7586.
diff --git a/drivers/gpu/drm/tinydrm/Makefile b/drivers/gpu/drm/tinydrm/Makefile
index 95bb4d4..0c184bd 100644
--- a/drivers/gpu/drm/tinydrm/Makefile
+++ b/drivers/gpu/drm/tinydrm/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_TINYDRM_MIPI_DBI)  += mipi-dbi.o
 # Displays
 obj-$(CONFIG_TINYDRM_MI0283QT) += mi0283qt.o
 obj-$(CONFIG_TINYDRM_REPAPER)  += repaper.o
+obj-$(CONFIG_TINYDRM_ST7586)   += st7586.o
diff --git a/drivers/gpu/drm/tinydrm/st7586.c b/drivers/gpu/drm/tinydrm/st7586.c
new file mode 100644
index 000..1b39d3f
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/st7586.c
@@ -0,0 +1,428 @@
+/*
+ * DRM driver for Sitronix ST7586 panels
+ *
+ * Copyright 2017 David Lechner <da...@lechnology.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+/* controller-specific commands */
+#define ST7586_DISP_MODE_GRAY  0x38
+#define ST7586_DISP_MODE_MONO  0x39
+#define ST7586_ENABLE_DDRAM0x3a
+#define ST7586_SET_DISP_DUTY   0xb0
+#define ST7586_SET_PART_DISP   0xb4
+#define ST7586_SET_NLINE_INV   0xb5
+#define ST7586_SET_VOP 0xc0
+#define ST7586_SET_BIAS_SYSTEM 0xc3
+#define ST7586_SET_BOOST_LEVEL 0xc4
+#define ST7586_SET_VOP_OFFSET  0xc7
+#define ST7586_ENABLE_ANALOG   0xd0
+#define ST7586_AUTO_READ_CTRL  0xd7
+#define ST7586_OTP_RW_CTRL 0xe0
+#define ST7586_OTP_CTRL_OUT0xe1
+#define ST7586_OTP_READ0xe3
+
+#define ST7586_DISP_CTRL_MXBIT(6)
+#define ST7586_DISP_CTRL_MYBIT(7)
+
+/*
+ * The ST7586 controller has an unusual pixel format where 2bpp grayscale is
+ * packed 3 pixels per byte with the first two pixels using 3 bits and the 3rd
+ * pixel using only 2 bits.
+ *
+ * |  D7  |  D6  |  D5  ||  |  || 2bpp |
+ * | (D4) | (D3) | (D2) ||  D1  |  D0  || GRAY |
+ * +--+--+--++--+--++--+
+ * |  1   |  1   |  1   ||  1   |  1   || 0  0 | black
+ * |  1   |  0   |  0   ||  1   |  0   || 0  1 | dark gray
+ * |  0   |  1   |  0   ||  0   |  1   || 1  0 | light gray
+ * |  0   |  0   |  0   ||  0   |  0   || 1  1 | white
+ */
+
+static const u8 st7586_lookup[] = { 0x7, 0x4, 0x2, 0x0 };
+
+static void st7586_xrgb_to_gray332(u8 *dst, void *vaddr,
+  struct drm_framebuffer *fb,
+  struct drm_clip_rect *clip)
+{
+   size_t len = (clip->x2 - clip->x1) * (clip->y2 - clip->y1);
+   unsigned int x, y;
+   u8 *src, *buf, val;
+
+   buf = kmalloc(len, GFP_KERNEL);
+   if (!buf)
+   return;
+
+   tinydrm_xrgb_to_gray8(buf, vaddr, fb, clip);
+   src = buf;
+
+   for (y = clip->y1; y < clip->y2; 

[PATCH v4 4/5] ARM: dts: da850-lego-ev3: Add node for LCD display

[David Lechner]

This adds a new node for the LEGO MINDSTORMS EV3 LCD display.

Signed-off-by: David Lechner <da...@lechnology.com>
---

v4 changes:
* changed dc to a0

 arch/arm/boot/dts/da850-lego-ev3.dts | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/da850-lego-ev3.dts 
b/arch/arm/boot/dts/da850-lego-ev3.dts
index 45983c0..413dbd5 100644
--- a/arch/arm/boot/dts/da850-lego-ev3.dts
+++ b/arch/arm/boot/dts/da850-lego-ev3.dts
@@ -249,6 +249,15 @@
0x4c 0x0080 0x00f0
>;
};
+
+   ev3_lcd_pins: pinmux_lcd {
+   pinctrl-single,bits = <
+   /* SIMO, GP2[11], GP2[12], CLK */
+   0x14 0x00188100 0x0000
+   /* GP5[0] */
+   0x30 0x8000 0xf000
+   >;
+   };
 };
 
  {
@@ -357,6 +366,21 @@
};
 };
 
+ {
+   status = "okay";
+   pinctrl-0 = <_lcd_pins>;
+   pinctrl-names = "default";
+   cs-gpios = < 44 GPIO_ACTIVE_LOW>;
+
+   display@0{
+   compatible = "lego,ev3-lcd";
+   reg = <0>;
+   spi-max-frequency = <1000>;
+   a0-gpios = < 43 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 80 GPIO_ACTIVE_HIGH>;
+   };
+};
+
  {
status = "okay";
 };
-- 
2.7.4

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

[PATCH v4 5/5] ARM: davinci_all_defconfig: enable tinydrm and ST7586

[David Lechner]

This enables the tinydrm and ST7586 panel modules used by the display
on LEGO MINDSTORMS EV3.

Signed-off-by: David Lechner <da...@lechnology.com>
---
 arch/arm/configs/davinci_all_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/davinci_all_defconfig 
b/arch/arm/configs/davinci_all_defconfig
index 06e2e2a..27d9720 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -143,6 +143,8 @@ CONFIG_VIDEO_ADV7343=m
 CONFIG_DRM=m
 CONFIG_DRM_TILCDC=m
 CONFIG_DRM_DUMB_VGA_DAC=m
+CONFIG_DRM_TINYDRM=m
+CONFIG_TINYDRM_ST7586=m
 CONFIG_FB=y
 CONFIG_FIRMWARE_EDID=y
 CONFIG_FB_DA8XX=y
-- 
2.7.4

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

Re: [PATCH] drm/tinydrm: mipi-dbi: Fix unbalanced DMA access

[David Lechner]

On 08/04/2017 01:49 AM, Noralf Trønnes wrote:


Den 04.08.2017 00.41, skrev David Lechner:

On 08/01/2017 03:14 PM, David Lechner wrote:
If we return here and import_attach is true, then 
dma_buf_end_cpu_access()

will not be called balance dma_buf_begin_cpu_access().

Fix by setting ret instead of returning.

Signed-off-by: David Lechner <da...@lechnology.com>
---
  drivers/gpu/drm/tinydrm/mipi-dbi.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
b/drivers/gpu/drm/tinydrm/mipi-dbi.c

index c83eeb7..e10fa4b 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -183,7 +183,8 @@ static int mipi_dbi_buf_copy(void *dst, struct 
drm_framebuffer *fb,

  dev_err_once(fb->dev->dev, "Format is not supported: %s\n",
   drm_get_format_name(fb->format->format,
   _name));
-return -EINVAL;
+ret = -EINVAL;
+break;
  }
if (import_attach)




I just realized that the next line here can mask ret.


if (import_attach)
ret = dma_buf_end_cpu_access(import_attach->dmabuf,
 DMA_FROM_DEVICE);

So, we should either ignore the return value from 
dma_buf_end_cpu_access() always or add some logic to ignore it if ret 
is already an error.


In some of the other patches I have been sending, we have the same 
situation. I those, I have opted to just ignore the return value from 
dma_buf_end_cpu_access(). e.g...



if (import_attach)
dma_buf_end_cpu_access(import_attach->dmabuf, DMA_FROM_DEVICE);

Is this a reasonable thing to do?


mipi_dbi_buf_copy() can be used by other rgb565 controllers, hence
the format check I think. So when that happens, it can be moved to
tinydrm-helpers.

Currently it's not possible to get an illegal format, since mipi-dbi
only supports those two formats.
Userspace can't set an illegal format, beacuse it's checked:
drm_atomic_commit -> drm_atomic_check_only -> drm_atomic_plane_check ->
drm_plane_check_pixel_format

So I think we can just leave this alone, or put the check before
import_attach if you really want to put this straight.



I guess we can just leave it alone for now.

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

Re: [PATCH 4/6] drm/tinydrm: Embed drm_device in tinydrm_device

[David Lechner]

On 08/28/2017 12:17 PM, Noralf Trønnes wrote:

Might as well embed drm_device since tinydrm_device (embeds pipe struct
and fbdev pointer) needs to stick around after driver-device unbind to
handle open fd's after device removal.

Cc: David Lechner <da...@lechnology.com>
Signed-off-by: Noralf Trønnes <nor...@tronnes.org>


Acked-By: David Lechner <da...@lechnology.com>



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

Re: [PATCH v2 07/11] drm/tinydrm: Drop driver registered message

[David Lechner]

On 09/08/2017 10:07 AM, Noralf Trønnes wrote:

No need to put out a driver registered message since drm_dev_register()
does that now. SPI speed is an important metric when dealing with
display problems, so retain that info.

Cc: David Lechner <da...@lechnology.com>
Signed-off-by: Noralf Trønnes <nor...@tronnes.org>
---


Acked-by: David Lechner <da...@lechnology.com>

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

[PATCH v1 0/2] DRM driver for Sitronix ST7735R display panels

[David Lechner]

This series adds a new DRM/TinyDRM driver for Sitronix ST7735R, specifically
the Adafruit 1.8" TFT.

Nothing fancy here. Just mostly TinyDRM boilerplate with the init sequence from
the fbtft driver for the same panel.

I'm assuming that since it says so here[1], that the "R" suffix is important,
so I am including it in the driver name and device tree bindings.

[1]: https://github.com/notro/tinydrm/wiki/Development

David Lechner (2):
  dt-bindings: Add binding for Sitronix ST7735R display panels
  drm/tinydrm: add driver for ST7735R panels

 .../bindings/display/sitronix,st7735r.txt  |  35 +++
 MAINTAINERS|   6 +
 drivers/gpu/drm/tinydrm/Kconfig|  10 +
 drivers/gpu/drm/tinydrm/Makefile   |   1 +
 drivers/gpu/drm/tinydrm/st7735r.c  | 237 +
 5 files changed, 289 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/sitronix,st7735r.txt
 create mode 100644 drivers/gpu/drm/tinydrm/st7735r.c

-- 
2.7.4

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

[PATCH v1 1/2] dt-bindings: Add binding for Sitronix ST7735R display panels

[David Lechner]

This adds a new device tree binding for Sitronix ST7735R display panels,
such as the Adafruit 1.8" TFT.

Signed-off-by: David Lechner <da...@lechnology.com>
---
 .../bindings/display/sitronix,st7735r.txt  | 35 ++
 1 file changed, 35 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/sitronix,st7735r.txt

diff --git a/Documentation/devicetree/bindings/display/sitronix,st7735r.txt 
b/Documentation/devicetree/bindings/display/sitronix,st7735r.txt
new file mode 100644
index 000..bbb8ba6
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sitronix,st7735r.txt
@@ -0,0 +1,35 @@
+Sitronix ST7735R display panels
+
+This binding is for display panels using a Sitronix ST7735R controller in SPI
+mode.
+
+Required properties:
+- compatible:  "sitronix,st7735r-jd-t18003-t01"
+- dc-gpios:Display data/command selection (D/CX)
+- reset-gpios: Reset signal (RSTX)
+
+The node for this driver must be a child node of a SPI controller, hence
+all mandatory properties described in ../spi/spi-bus.txt must be specified.
+
+Optional properties:
+- rotation:panel rotation in degrees counter clockwise (0,90,180,270)
+- backlight:   phandle of the backlight device attached to the panel
+
+Example:
+
+   backlight: backlight {
+   compatible = "gpio-backlight";
+   gpios = < 44 GPIO_ACTIVE_HIGH>;
+   }
+
+   ...
+
+   display@0{
+   compatible = "sitronix,st7735r-jd-t18003-t01";
+   reg = <0>;
+   spi-max-frequency = <3200>;
+   dc-gpios = < 43 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 80 GPIO_ACTIVE_HIGH>;
+   rotation = <270>;
+   backlight = 
+   };
-- 
2.7.4

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

[PATCH v1 2/2] drm/tinydrm: add driver for ST7735R panels

[David Lechner]

This adds a new driver for Sitronix ST7735R display panels.

This has been tested using an Adafruit 1.8" TFT.

Signed-off-by: David Lechner <da...@lechnology.com>
---
 MAINTAINERS   |   6 +
 drivers/gpu/drm/tinydrm/Kconfig   |  10 ++
 drivers/gpu/drm/tinydrm/Makefile  |   1 +
 drivers/gpu/drm/tinydrm/st7735r.c | 237 ++
 4 files changed, 254 insertions(+)
 create mode 100644 drivers/gpu/drm/tinydrm/st7735r.c

diff --git a/MAINTAINERS b/MAINTAINERS
index a174632..9c7707e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4462,6 +4462,12 @@ S:   Maintained
 F: drivers/gpu/drm/tinydrm/st7586.c
 F: Documentation/devicetree/bindings/display/st7586.txt
 
+DRM DRIVER FOR SITRONIX ST7735R PANELS
+M: David Lechner <da...@lechnology.com>
+S: Maintained
+F: drivers/gpu/drm/tinydrm/st7735r.c
+F: Documentation/devicetree/bindings/display/st7735r.txt
+
 DRM DRIVER FOR TDFX VIDEO CARDS
 S: Orphan / Obsolete
 F: drivers/gpu/drm/tdfx/
diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index 90c5bd5..b0e567d 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -52,3 +52,13 @@ config TINYDRM_ST7586
  * LEGO MINDSTORMS EV3
 
  If M is selected the module will be called st7586.
+
+config TINYDRM_ST7735R
+   tristate "DRM support for Sitronix ST7735R display panels"
+   depends on DRM_TINYDRM && SPI
+   select TINYDRM_MIPI_DBI
+   help
+ DRM driver Sitronix ST7735R with one of the following LCDs:
+ * JD-T18003-T01 1.8" 128x160 TFT
+
+ If M is selected the module will be called st7735r.
diff --git a/drivers/gpu/drm/tinydrm/Makefile b/drivers/gpu/drm/tinydrm/Makefile
index 8aeee53..49a1119 100644
--- a/drivers/gpu/drm/tinydrm/Makefile
+++ b/drivers/gpu/drm/tinydrm/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_TINYDRM_ILI9225)   += ili9225.o
 obj-$(CONFIG_TINYDRM_MI0283QT) += mi0283qt.o
 obj-$(CONFIG_TINYDRM_REPAPER)  += repaper.o
 obj-$(CONFIG_TINYDRM_ST7586)   += st7586.o
+obj-$(CONFIG_TINYDRM_ST7735R)  += st7735r.o
diff --git a/drivers/gpu/drm/tinydrm/st7735r.c 
b/drivers/gpu/drm/tinydrm/st7735r.c
new file mode 100644
index 000..6435b00
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/st7735r.c
@@ -0,0 +1,237 @@
+/*
+ * DRM driver for Sitronix ST7735R panels
+ *
+ * Copyright 2017 David Lechner <da...@lechnology.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define ST7735R_FRMCTR10xb1
+#define ST7735R_FRMCTR20xb2
+#define ST7735R_FRMCTR30xb3
+#define ST7735R_INVCTR 0xb4
+#define ST7735R_PWCTR1 0xc0
+#define ST7735R_PWCTR2 0xc1
+#define ST7735R_PWCTR3 0xc2
+#define ST7735R_PWCTR4 0xc3
+#define ST7735R_PWCTR5 0xc4
+#define ST7735R_VMCTR1 0xc5
+#define ST7735R_GAMCTRP1   0xe0
+#define ST7735R_GAMCTRN1   0xe1
+
+#define ST7735R_MY BIT(7)
+#define ST7735R_MX BIT(6)
+#define ST7735R_MV BIT(5)
+
+static void st7735r_pipe_enable(struct drm_simple_display_pipe *pipe,
+   struct drm_crtc_state *crtc_state)
+{
+   struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
+   struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
+   struct drm_framebuffer *fb = pipe->plane.fb;
+   struct device *dev = tdev->drm->dev;
+   int ret;
+   u8 addr_mode;
+
+   DRM_DEBUG_KMS("\n");
+
+   mipi_dbi_hw_reset(mipi);
+
+   ret = mipi_dbi_command(mipi, MIPI_DCS_SOFT_RESET);
+   if (ret) {
+   DRM_DEV_ERROR(dev, "Error sending command %d\n", ret);
+   return;
+   }
+
+   msleep(150);
+
+   mipi_dbi_command(mipi, MIPI_DCS_EXIT_SLEEP_MODE);
+   msleep(500);
+
+   mipi_dbi_command(mipi, ST7735R_FRMCTR1, 0x01, 0x2c, 0x2d);
+   mipi_dbi_command(mipi, ST7735R_FRMCTR2, 0x01, 0x2c, 0x2d);
+   mipi_dbi_command(mipi, ST7735R_FRMCTR3, 0x01, 0x2c, 0x2d, 0x01, 0x2c,
+0x2d);
+   mipi_dbi_command(mipi, ST7735R_INVCTR, 0x07);
+   mipi_dbi_command(mipi, ST7735R_PWCTR1, 0xa2, 0x02, 0x84);
+   mipi_dbi_command(mipi, ST7735R_PWCTR2, 0xc5);
+   mipi_dbi_command(mipi, ST7735R_PWCTR3, 0x0a, 0x00);
+   mipi_dbi_command(mipi, ST7735R_PWCTR4, 0x8a, 0x2a);
+   mipi_dbi_command(mipi, ST7735R_PWCTR5, 0x8a, 0xee);
+   mipi_dbi_command(mipi, ST7735R_VMCTR1, 0x0e);
+   mipi_dbi_command(mipi, MIPI_DCS_EXIT_INVERT_MODE);
+   switch (mipi->ro

Re: tinydrm: page allocation failure

[David Lechner]

On 12/11/2017 06:45 AM, Noralf Trønnes wrote:


Den 11.12.2017 04.28, skrev David Lechner:
I'm using drm-misc/drm-misc-next and occasionally getting errors as 
seen in the stack traces below. I'm not really sure what to make of 
it. Any ideas?




I'm starting to wonder if there is some sort of race condition involved. 
I only get this warning on some boots, but when I do, it happens 
multiple times. Also, when I was debugging a an unrelated problem, I 
enabled some of the spin lock checking kernel options that really slow 
down the kernel. When I did this, I got this warning all of the time.


Would it be sensible to allocate a dummy RX buffer once instead of 
letting SPI allocate a new one for every transfer?




The spi controller driver has told the spi core to allocate dummy
buffers for tx/rx: spi_sync -> __spi_pump_messages -> spi_map_msg
-> krealloc -> __do_krealloc -> kmalloc_track_caller

order:4 means it's trying to allocate 2^4*PAGE_SIZE = 64kB, which
probably is the max DMA limit. So this is a pixel data transfer.

On my Raspberry Pi I've got 43 chunks of 64kB available if I have
understood this right:

$ sudo cat /proc/buddyinfo
Node 0, zone   Normal 40 68 66 51 43 46 13 
1  3  3 75


I don't know what those dummy buffers are used for.

Noralf.


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

[PATCH v2 4/4] drm/tinydrm: add driver for ILI9225 panels

[David Lechner]

This adds a new driver for display panels based on the Ilitek ILI9225
controller.

This was developed for a no-name panel with a red PCB that is commonly
marketed for Arduino. See <https://github.com/Nkawu/TFT_22_ILI9225>.

Signed-off-by: David Lechner <da...@lechnology.com>
---

v2 changes:
* use exported mipi_dbi_* functions from patch 3/4
* new ili9225_command function

 MAINTAINERS   |   6 +
 drivers/gpu/drm/tinydrm/Kconfig   |  10 +
 drivers/gpu/drm/tinydrm/Makefile  |   1 +
 drivers/gpu/drm/tinydrm/ili9225.c | 468 ++
 4 files changed, 485 insertions(+)
 create mode 100644 drivers/gpu/drm/tinydrm/ili9225.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 0d77f22..72404f3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4372,6 +4372,12 @@ T:   git git://anongit.freedesktop.org/drm/drm-misc
 S: Maintained
 F: drivers/gpu/drm/tve200/
 
+DRM DRIVER FOR ILITEK ILI9225 PANELS
+M: David Lechner <da...@lechnology.com>
+S: Maintained
+F: drivers/gpu/drm/tinydrm/ili9225.c
+F: Documentation/devicetree/bindings/display/ili9225.txt
+
 DRM DRIVER FOR INTEL I810 VIDEO CARDS
 S: Orphan / Obsolete
 F: drivers/gpu/drm/i810/
diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index 2e790e7..90c5bd5 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -12,6 +12,16 @@ menuconfig DRM_TINYDRM
 config TINYDRM_MIPI_DBI
tristate
 
+config TINYDRM_ILI9225
+   tristate "DRM support for ILI9225 display panels"
+   depends on DRM_TINYDRM && SPI
+   select TINYDRM_MIPI_DBI
+   help
+ DRM driver for the following Ilitek ILI9225 panels:
+ * No-name 2.2" color screen module
+
+ If M is selected the module will be called ili9225.
+
 config TINYDRM_MI0283QT
tristate "DRM support for MI0283QT"
depends on DRM_TINYDRM && SPI
diff --git a/drivers/gpu/drm/tinydrm/Makefile b/drivers/gpu/drm/tinydrm/Makefile
index 0c184bd..8aeee53 100644
--- a/drivers/gpu/drm/tinydrm/Makefile
+++ b/drivers/gpu/drm/tinydrm/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_TINYDRM)   += core/
 obj-$(CONFIG_TINYDRM_MIPI_DBI) += mipi-dbi.o
 
 # Displays
+obj-$(CONFIG_TINYDRM_ILI9225)  += ili9225.o
 obj-$(CONFIG_TINYDRM_MI0283QT) += mi0283qt.o
 obj-$(CONFIG_TINYDRM_REPAPER)  += repaper.o
 obj-$(CONFIG_TINYDRM_ST7586)   += st7586.o
diff --git a/drivers/gpu/drm/tinydrm/ili9225.c 
b/drivers/gpu/drm/tinydrm/ili9225.c
new file mode 100644
index 000..3b766a2
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/ili9225.c
@@ -0,0 +1,468 @@
+/*
+ * DRM driver for Ilitek ILI9225 panels
+ *
+ * Copyright 2017 David Lechner <da...@lechnology.com>
+ *
+ * Some code copied from mipi-dbi.c
+ * Copyright 2016 Noralf Trønnes
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define ILI9225_DRIVER_READ_CODE   0x00
+#define ILI9225_DRIVER_OUTPUT_CONTROL  0x01
+#define ILI9225_LCD_AC_DRIVING_CONTROL 0x02
+#define ILI9225_ENTRY_MODE 0x03
+#define ILI9225_DISPLAY_CONTROL_1  0x07
+#define ILI9225_BLANK_PERIOD_CONTROL_1 0x08
+#define ILI9225_FRAME_CYCLE_CONTROL0x0b
+#define ILI9225_INTERFACE_CONTROL  0x0c
+#define ILI9225_OSCILLATION_CONTROL0x0f
+#define ILI9225_POWER_CONTROL_10x10
+#define ILI9225_POWER_CONTROL_20x11
+#define ILI9225_POWER_CONTROL_30x12
+#define ILI9225_POWER_CONTROL_40x13
+#define ILI9225_POWER_CONTROL_50x14
+#define ILI9225_VCI_RECYCLING  0x15
+#define ILI9225_RAM_ADDRESS_SET_1  0x20
+#define ILI9225_RAM_ADDRESS_SET_2  0x21
+#define ILI9225_WRITE_DATA_TO_GRAM 0x22
+#define ILI9225_SOFTWARE_RESET 0x28
+#define ILI9225_GATE_SCAN_CONTROL  0x30
+#define ILI9225_VERTICAL_SCROLL_1  0x31
+#define ILI9225_VERTICAL_SCROLL_2  0x32
+#define ILI9225_VERTICAL_SCROLL_3  0x33
+#define ILI9225_PARTIAL_DRIVING_POS_1  0x34
+#define ILI9225_PARTIAL_DRIVING_POS_2  0x35
+#define ILI9225_HORIZ_WINDOW_ADDR_10x36
+#define ILI9225_HORIZ_WINDOW_ADDR_20x37
+#define ILI9225_VERT_WINDOW_ADDR_1 0x38
+#define ILI9225_VERT_WINDOW_ADDR_2 0x39
+#define ILI9225_GAMMA_CONTROL_10x50
+#define ILI9225_GAMMA_CONTROL_20x51
+#define ILI9225_GAMMA_CONTROL_30x52
+#define ILI9225_GAMMA_CONTROL_40x53
+#define ILI9225_GAMMA_CONTROL_50x54
+#define ILI9225_GAMMA_CONTROL_60x55
+#define ILI9225_GAMMA_CONTROL_7

[PATCH v2 1/4] dt-bindings: Add vendor prefix for ilitek

[David Lechner]

This adds the vendor prefix ilitek for ILI Technology Corporation (ILITEK).

This prefix is already used several places and I will be adding more.

Signed-off-by: David Lechner <da...@lechnology.com>
---

v2 changes:
* New patch in v2

 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 6cf1dc5..cf41a33 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -150,6 +150,7 @@ i2seI2SE GmbH
 ibmInternational Business Machines (IBM)
 idtIntegrated Device Technologies, Inc.
 ifiIngenieurburo Fur Ic-Technologie (I/F/I)
+ilitek ILI Technology Corporation (ILITEK)
 imgImagination Technologies Ltd.
 infineon Infineon Technologies
 inforceInforce Computing
-- 
2.7.4

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

[PATCH v2 0/4] DRM driver for ILI9225 display panels

[David Lechner]

This is a new driver for ILI9225 based display panels.

v2 changes:
* New patch for ilitek vendor prefix.
* Use "ilitek" instead of "generic" in dt-bindings
* New patch to export 2 mipi_dbi_* functions
* Clean up ILI9225 driver based on feedback

David Lechner (4):
  dt-bindings: Add vendor prefix for ilitek
  dt-bindings: Add binding for Ilitek ILI9225 display panels
  drm/tinydrm: export mipi_dbi_buf_copy and mipi_dbi_spi_cmd_max_speed
  drm/tinydrm: add driver for ILI9225 panels

 .../devicetree/bindings/display/ilitek,ili9225.txt |  25 ++
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 MAINTAINERS|   6 +
 drivers/gpu/drm/tinydrm/Kconfig|  10 +
 drivers/gpu/drm/tinydrm/Makefile   |   1 +
 drivers/gpu/drm/tinydrm/ili9225.c  | 468 +
 drivers/gpu/drm/tinydrm/mipi-dbi.c |  24 +-
 include/drm/tinydrm/mipi-dbi.h |   4 +-
 8 files changed, 534 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9225.txt
 create mode 100644 drivers/gpu/drm/tinydrm/ili9225.c

-- 
2.7.4

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

[PATCH v2 3/4] drm/tinydrm: export mipi_dbi_buf_copy and mipi_dbi_spi_cmd_max_speed

[David Lechner]

This exports the mipi_dbi_buf_copy() and mipi_dbi_spi_cmd_max_speed()
functions so that they can be shared with other drivers.

Signed-off-by: David Lechner <da...@lechnology.com>
---

v2 changes:
* new patch in v2

 drivers/gpu/drm/tinydrm/mipi-dbi.c | 24 
 include/drm/tinydrm/mipi-dbi.h |  4 +++-
 2 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index 347f9b2..aa6b6ce 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -154,8 +154,18 @@ int mipi_dbi_command_buf(struct mipi_dbi *mipi, u8 cmd, u8 
*data, size_t len)
 }
 EXPORT_SYMBOL(mipi_dbi_command_buf);
 
-static int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer *fb,
-   struct drm_clip_rect *clip, bool swap)
+/**
+ * mipi_dbi_buf_copy - Copy a framebuffer, transforming it if necessary
+ * @dst: The destination buffer
+ * @fb: The source framebuffer
+ * @clip: Clipping rectangle of the area to be copied
+ * @swap: When true, swap MSB/LSB of 16-bit values
+ *
+ * Returns:
+ * Zero on success, negative error code on failure.
+ */
+int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer *fb,
+ struct drm_clip_rect *clip, bool swap)
 {
struct drm_gem_cma_object *cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
struct dma_buf_attachment *import_attach = cma_obj->base.import_attach;
@@ -192,6 +202,7 @@ static int mipi_dbi_buf_copy(void *dst, struct 
drm_framebuffer *fb,
 DMA_FROM_DEVICE);
return ret;
 }
+EXPORT_SYMBOL(mipi_dbi_buf_copy);
 
 static int mipi_dbi_fb_dirty(struct drm_framebuffer *fb,
 struct drm_file *file_priv,
@@ -444,18 +455,23 @@ EXPORT_SYMBOL(mipi_dbi_display_is_on);
 
 #if IS_ENABLED(CONFIG_SPI)
 
-/*
+/**
+ * mipi_dbi_spi_cmd_max_speed - get the maximum SPI bus speed
+ * @spi: SPI device
+ * @len: The transfer buffer length.
+ *
  * Many controllers have a max speed of 10MHz, but can be pushed way beyond
  * that. Increase reliability by running pixel data at max speed and the rest
  * at 10MHz, preventing transfer glitches from messing up the init settings.
  */
-static u32 mipi_dbi_spi_cmd_max_speed(struct spi_device *spi, size_t len)
+u32 mipi_dbi_spi_cmd_max_speed(struct spi_device *spi, size_t len)
 {
if (len > 64)
return 0; /* use default */
 
return min_t(u32, 1000, spi->max_speed_hz);
 }
+EXPORT_SYMBOL(mipi_dbi_spi_cmd_max_speed);
 
 /*
  * MIPI DBI Type C Option 1
diff --git a/include/drm/tinydrm/mipi-dbi.h b/include/drm/tinydrm/mipi-dbi.h
index 83346dd..5d0e82b 100644
--- a/include/drm/tinydrm/mipi-dbi.h
+++ b/include/drm/tinydrm/mipi-dbi.h
@@ -72,10 +72,12 @@ void mipi_dbi_pipe_enable(struct drm_simple_display_pipe 
*pipe,
 void mipi_dbi_pipe_disable(struct drm_simple_display_pipe *pipe);
 void mipi_dbi_hw_reset(struct mipi_dbi *mipi);
 bool mipi_dbi_display_is_on(struct mipi_dbi *mipi);
+u32 mipi_dbi_spi_cmd_max_speed(struct spi_device *spi, size_t len);
 
 int mipi_dbi_command_read(struct mipi_dbi *mipi, u8 cmd, u8 *val);
 int mipi_dbi_command_buf(struct mipi_dbi *mipi, u8 cmd, u8 *data, size_t len);
-
+int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer *fb,
+ struct drm_clip_rect *clip, bool swap);
 /**
  * mipi_dbi_command - MIPI DCS command with optional parameter(s)
  * @mipi: MIPI structure
-- 
2.7.4

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

[PATCH v2 2/4] dt-bindings: Add binding for Ilitek ILI9225 display panels

[David Lechner]

This adds a new binding for display panels that use an Ilitek ILI9225
controller.

The "ilitek,ili9225-2.2in-176x220" device listed has no identification
markings whatsoever and an hour of googling turned up nothing, hence the use
of the size and resolution in the name instead of a model name.

An example of this nameless device can be found at:
https://github.com/Nkawu/TFT_22_ILI9225

Signed-off-by: David Lechner <da...@lechnology.com>
---

v2 changes:
* renamed compatible string based on feedback

 .../devicetree/bindings/display/ilitek,ili9225.txt | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9225.txt

diff --git a/Documentation/devicetree/bindings/display/ilitek,ili9225.txt 
b/Documentation/devicetree/bindings/display/ilitek,ili9225.txt
new file mode 100644
index 000..21607a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ilitek,ili9225.txt
@@ -0,0 +1,25 @@
+Ilitek ILI9225 display panels
+
+This binding is for display panels using an Ilitek ILI9225 controller in SPI
+mode.
+
+Required properties:
+- compatible:  "ilitek,ili9225-2.2in-176x220"
+- rs-gpios:Register select signal
+- reset-gpios: Reset pin
+
+The node for this driver must be a child node of a SPI controller, hence
+all mandatory properties described in ../spi/spi-bus.txt must be specified.
+
+Optional properties:
+- rotation:panel rotation in degrees counter clockwise (0,90,180,270)
+
+Example:
+   display@0{
+   compatible = "ilitek,ili9225-2.2in-176x220";
+   reg = <0>;
+   spi-max-frequency = <1200>;
+   rs-gpios = < 9 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 8 GPIO_ACTIVE_HIGH>;
+   rotation = <270>;
+   };
-- 
2.7.4

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

Re: [PATCH 21/22] drm/tinydrm: Use drm_fb_cma_fbdev_init_with_funcs/fini()

[David Lechner]

On 11/04/2017 08:04 AM, Noralf Trønnes wrote:

Use drm_fb_cma_fbdev_init_with_funcs() and drm_fb_cma_fbdev_fini() which
relies on the fact that drm_device holds a pointer to the drm_fb_helper
structure. This means that the driver doesn't have to keep track of that.
Also use the drm_fb_helper functions directly.
Remove todo entry.

Cc: David Lechner <da...@lechnology.com>
Signed-off-by: Noralf Trønnes <nor...@tronnes.org>
---


Acked-by: David Lechner <da...@lechnology.com>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1 0/2] DRM driver for ILI9225 display panels

[David Lechner]

This is a new driver for ILI9225 based display panels.

There are a couple of things that stand out:

1.  Despite my best efforts, I could not find a name for this display[1], so I
have made up a generic name for it. If someone recognizes this and has a
name for it, please speak up. The best documentation I could find was
here[2].

2.  There is quite a bit of one-off code copied from mipi-dbi.c. Based on the
feedback from a previous patch series, I'm guessing that we don't want to
modify mipi-dbi.c to accommodate the ILI9225 controller because the ILI9225
controller does not use standard MIPI commands. ILI9225 has it's own
non-standard command set, but other than that, it pretty much matches the
generic mipi-dbi driver in all regards.

Code that could be easily shared:

a.  ili9225_buf_copy() is exactly the same as mipi_dbi_buf_copy()
- ili9225_buf_copy() is used in ili9225_fb_dirty()
- mipi_dbi_buf_copy() is static in mipi-dbi.c

b.  ili9225_spi_cmd_max_speed() is exactly the same as
mipi_dbi_spi_cmd_max_speed()
- ili9225_spi_cmd_max_speed() is used in ili9225_command() below, so
  would not need to be copied if mipi_dbi_typec3_command() could be
  shared
- mipi_dbi_spi_cmd_max_speed() is static in mipi-dbi.c

c.  ili9225_command() is nearly the same as mipi_dbi_typec3_command()
- a few unused lines were removed so I didn't have to copy even more
  code, but these would not be an issue if code was shared
- cmd == ILI9225_WRITE_DATA_TO_GRAM instead of
  cmd == MIPI_DCS_WRITE_MEMORY_START

d.  ili9225_spi_init() is nearly the same as mipi_dbi_spi_init()
- a few unused lines were removed so I didn't have to copy even more
  code, but these would not be an issue if code was shared
- mipi->command = ili9225_command instead of
  mipi->command = mipi_dbi_typec3_command
- this function would not need to be copied if mipi_dbi_typec3_command()
  was modified to work with the ILI9225 command set too

e.  ili9225_init() is nearly the same as mipi_dbi_init()
- only difference is ili9225_fb_funcs instead of mipi_dbi_fb_funcs

3.  I haven't tried it, but I believe that it is possible to implement
DRM_FORMAT_RGB888 directly instead of simulating DRM_FORMAT_XRGB.
I don't know if there would be any real benefit to doing this. I am not
familiar enough with userspace programs/libraries to know if this mode is
universally used. And, it will only physically be 18-bit color instead of
24-bit but will increase the amount of data transferred by 50% (3 bytes per
pixel instead of 2). Implementing this would have a side effect of making
the one-off shared code (described above) more than one-off though.

[1]: https://github.com/Nkawu/TFT_22_ILI9225
[2]: http://www.hotmcu.com/22-176x220-tft-lcd-with-spi-interface-p-316.html

David Lechner (2):
  dt-bindings: Add binding for Ilitek ILI9225 display panels
  drm/tinydrm: add driver for ILI9225 panels

 .../devicetree/bindings/display/ilitek,ili9225.txt |  25 +
 MAINTAINERS|   6 +
 drivers/gpu/drm/tinydrm/Kconfig|  10 +
 drivers/gpu/drm/tinydrm/Makefile   |   1 +
 drivers/gpu/drm/tinydrm/ili9225.c  | 547 +
 5 files changed, 589 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9225.txt
 create mode 100644 drivers/gpu/drm/tinydrm/ili9225.c

--
2.7.4

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

[PATCH v1 2/2] drm/tinydrm: add driver for ILI9225 panels

[David Lechner]

This adds a new driver for display panels based on the Ilitek ILI9225
controller.

This was developed for a no-name panel with a red PCB that is commonly
marketed for Arduino. See <https://github.com/Nkawu/TFT_22_ILI9225>.

I really did try very hard to find a make and model for this panel, but
there doesn't seem to be one, so the best I can do is offer the picture
in the link above for identification.

Signed-off-by: David Lechner <da...@lechnology.com>
---
 MAINTAINERS   |   6 +
 drivers/gpu/drm/tinydrm/Kconfig   |  10 +
 drivers/gpu/drm/tinydrm/Makefile  |   1 +
 drivers/gpu/drm/tinydrm/ili9225.c | 547 ++
 4 files changed, 564 insertions(+)
 create mode 100644 drivers/gpu/drm/tinydrm/ili9225.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 0d77f22..72404f3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4372,6 +4372,12 @@ T:   git git://anongit.freedesktop.org/drm/drm-misc
 S: Maintained
 F: drivers/gpu/drm/tve200/
 
+DRM DRIVER FOR ILITEK ILI9225 PANELS
+M: David Lechner <da...@lechnology.com>
+S: Maintained
+F: drivers/gpu/drm/tinydrm/ili9225.c
+F: Documentation/devicetree/bindings/display/ili9225.txt
+
 DRM DRIVER FOR INTEL I810 VIDEO CARDS
 S: Orphan / Obsolete
 F: drivers/gpu/drm/i810/
diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index 2e790e7..90c5bd5 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -12,6 +12,16 @@ menuconfig DRM_TINYDRM
 config TINYDRM_MIPI_DBI
tristate
 
+config TINYDRM_ILI9225
+   tristate "DRM support for ILI9225 display panels"
+   depends on DRM_TINYDRM && SPI
+   select TINYDRM_MIPI_DBI
+   help
+ DRM driver for the following Ilitek ILI9225 panels:
+ * No-name 2.2" color screen module
+
+ If M is selected the module will be called ili9225.
+
 config TINYDRM_MI0283QT
tristate "DRM support for MI0283QT"
depends on DRM_TINYDRM && SPI
diff --git a/drivers/gpu/drm/tinydrm/Makefile b/drivers/gpu/drm/tinydrm/Makefile
index 0c184bd..8aeee53 100644
--- a/drivers/gpu/drm/tinydrm/Makefile
+++ b/drivers/gpu/drm/tinydrm/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_TINYDRM)   += core/
 obj-$(CONFIG_TINYDRM_MIPI_DBI) += mipi-dbi.o
 
 # Displays
+obj-$(CONFIG_TINYDRM_ILI9225)  += ili9225.o
 obj-$(CONFIG_TINYDRM_MI0283QT) += mi0283qt.o
 obj-$(CONFIG_TINYDRM_REPAPER)  += repaper.o
 obj-$(CONFIG_TINYDRM_ST7586)   += st7586.o
diff --git a/drivers/gpu/drm/tinydrm/ili9225.c 
b/drivers/gpu/drm/tinydrm/ili9225.c
new file mode 100644
index 000..07e1b8b
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/ili9225.c
@@ -0,0 +1,547 @@
+/*
+ * DRM driver for Ilitek ILI9225 panels
+ *
+ * Copyright 2017 David Lechner <da...@lechnology.com>
+ *
+ * Lots of code copied from mipi-dbi.c
+ * Copyright 2016 Noralf Trønnes
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define ILI9225_DRIVER_READ_CODE   0x00
+#define ILI9225_DRIVER_OUTPUT_CONTROL  0x01
+#define ILI9225_LCD_AC_DRIVING_CONTROL 0x02
+#define ILI9225_ENTRY_MODE 0x03
+#define ILI9225_DISPLAY_CONTROL_1  0x07
+#define ILI9225_BLANK_PERIOD_CONTROL_1 0x08
+#define ILI9225_FRAME_CYCLE_CONTROL0x0b
+#define ILI9225_INTERFACE_CONTROL  0x0c
+#define ILI9225_OSCILLATION_CONTROL0x0f
+#define ILI9225_POWER_CONTROL_10x10
+#define ILI9225_POWER_CONTROL_20x11
+#define ILI9225_POWER_CONTROL_30x12
+#define ILI9225_POWER_CONTROL_40x13
+#define ILI9225_POWER_CONTROL_50x14
+#define ILI9225_VCI_RECYCLING  0x15
+#define ILI9225_RAM_ADDRESS_SET_1  0x20
+#define ILI9225_RAM_ADDRESS_SET_2  0x21
+#define ILI9225_WRITE_DATA_TO_GRAM 0x22
+#define ILI9225_SOFTWARE_RESET 0x28
+#define ILI9225_GATE_SCAN_CONTROL  0x30
+#define ILI9225_VERTICAL_SCROLL_1  0x31
+#define ILI9225_VERTICAL_SCROLL_2  0x32
+#define ILI9225_VERTICAL_SCROLL_3  0x33
+#define ILI9225_PARTIAL_DRIVING_POS_1  0x34
+#define ILI9225_PARTIAL_DRIVING_POS_2  0x35
+#define ILI9225_HORIZ_WINDOW_ADDR_10x36
+#define ILI9225_HORIZ_WINDOW_ADDR_20x37
+#define ILI9225_VERT_WINDOW_ADDR_1 0x38
+#define ILI9225_VERT_WINDOW_ADDR_2 0x39
+#define ILI9225_GAMMA_CONTROL_10x50
+#define ILI9225_GAMMA_CONTROL_20x51
+#define ILI9225_GAMMA_CONTROL_30x52
+#define ILI9225_GAMMA_CONTROL_40x53
+#define ILI9225_GAMMA_CONTROL_50

[PATCH v1 1/2] dt-bindings: Add binding for Ilitek ILI9225 display panels

[David Lechner]

This adds a new binding for display panels that use an Ilitek ILI9225
controller.

The "generic,2.2in-176x220-ili9225-tft" device listed has no identification
markings whatsoever and an hour of googling turned up nothing, hence the use
of "generic".

An example of this nameless device can be found at:
https://github.com/Nkawu/TFT_22_ILI9225

Signed-off-by: David Lechner <da...@lechnology.com>
---
 .../devicetree/bindings/display/ilitek,ili9225.txt | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9225.txt

diff --git a/Documentation/devicetree/bindings/display/ilitek,ili9225.txt 
b/Documentation/devicetree/bindings/display/ilitek,ili9225.txt
new file mode 100644
index 000..5839f56
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ilitek,ili9225.txt
@@ -0,0 +1,25 @@
+Ilitek ILI9225 display panels
+
+This binding is for display panels using an Ilitek ILI9225 controller in SPI
+mode.
+
+Required properties:
+- compatible:  "generic,2.2in-176x220-ili9225-tft"
+- rs-gpios:Register select signal
+- reset-gpios: Reset pin
+
+The node for this driver must be a child node of a SPI controller, hence
+all mandatory properties described in ../spi/spi-bus.txt must be specified.
+
+Optional properties:
+- rotation:panel rotation in degrees counter clockwise (0,90,180,270)
+
+Example:
+   display@0{
+   compatible = "generic,2.2in-176x220-ili9225-tft";
+   reg = <0>;
+   spi-max-frequency = <1200>;
+   rs-gpios = < 9 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 8 GPIO_ACTIVE_HIGH>;
+   rotation = <270>;
+   };
-- 
2.7.4

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

Re: [PATCH v1 2/2] drm/tinydrm: add driver for ST7735R panels

[David Lechner]

On 12/06/2017 12:27 PM, Noralf Trønnes wrote:


Den 29.11.2017 04.01, skrev David Lechner:

This adds a new driver for Sitronix ST7735R display panels.

This has been tested using an Adafruit 1.8" TFT.

Signed-off-by: David Lechner <da...@lechnology.com>
---
  MAINTAINERS   |   6 +
  drivers/gpu/drm/tinydrm/Kconfig   |  10 ++
  drivers/gpu/drm/tinydrm/Makefile  |   1 +
  drivers/gpu/drm/tinydrm/st7735r.c | 237 
++

  4 files changed, 254 insertions(+)
  create mode 100644 drivers/gpu/drm/tinydrm/st7735r.c

diff --git a/MAINTAINERS b/MAINTAINERS
index a174632..9c7707e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4462,6 +4462,12 @@ S:    Maintained
  F:    drivers/gpu/drm/tinydrm/st7586.c
  F:    Documentation/devicetree/bindings/display/st7586.txt
+DRM DRIVER FOR SITRONIX ST7735R PANELS
+M:    David Lechner <da...@lechnology.com>


I know we haven't done this in the other tinydrm drivers, but I think
we should start adding which tree the development is happening in:

T:    git git://anongit.freedesktop.org/drm/drm-misc


This is inherited, just like L:, so get_maintainers.pl --scm returns git 
git://anongit.freedesktop.org/drm/drm-misc already. So there doesn't 
seem to be a need to add this line.





+S:    Maintained
+F:    drivers/gpu/drm/tinydrm/st7735r.c
+F:    Documentation/devicetree/bindings/display/st7735r.txt





+}
+
+static void st7735r_pipe_disable(struct drm_simple_display_pipe *pipe)
+{
+    struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
+    struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
+


Please use mipi_dbi_pipe_disable() here.


+    DRM_DEBUG_KMS("\n");
+
+    if (!mipi->enabled)
+    return;
+
+    tinydrm_disable_backlight(mipi->backlight);
+
+    mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_OFF);


You turn off the panel, have you checked what it looks like if you don't
turn off backlight (which is optional in this driver)?

On the displays I have tried this on, all pixels turn white when they're
not driven, letting backlight through, giving an all white display.
That's why I have that blanking code in mipi_dbi_pipe_disable() when we
don't have backlight control and the reason I don't turn off the panel.
The power savings of not driving the panel is negligible AFAICR.

If you don't need DISPLAY_OFF, you can just use mipi_dbi_pipe_disable()
directly as the callback.



I tested this and you are right, it causes the panel to go white when a 
backlight is not specified, so I will just use mipi_dbi_pipe_disable().

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

Re: [PATCH v3 10/11] drm/tinydrm: Use drm_fb_cma_fbdev_init_with_funcs/fini()

[David Lechner]

On 12/08/2017 01:37 PM, Noralf Trønnes wrote:

Use drm_fb_cma_fbdev_init_with_funcs() and drm_fb_cma_fbdev_fini() which
relies on the fact that drm_device holds a pointer to the drm_fb_helper
structure. This means that the driver doesn't have to keep track of that.
Also use the drm_fb_helper functions directly.
Remove todo entry.

Cc: David Lechner <da...@lechnology.com>
Signed-off-by: Noralf Trønnes <nor...@tronnes.org>
Acked-by: David Lechner <da...@lechnology.com>
Acked-by: Daniel Vetter <daniel.vet...@ffwll.ch>
---
  Documentation/gpu/todo.rst  |  5 
  drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 37 -
  drivers/gpu/drm/tinydrm/ili9225.c   |  3 ++-
  drivers/gpu/drm/tinydrm/mi0283qt.c  |  3 ++-
  drivers/gpu/drm/tinydrm/st7586.c|  3 ++-
  include/drm/tinydrm/tinydrm.h   |  3 ---
  6 files changed, 11 insertions(+), 43 deletions(-)



Tested-by: David Lechner <da...@lechnolgy.com>

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

tinydrm: page allocation failure

[David Lechner]

I'm using drm-misc/drm-misc-next and occasionally getting errors as seen 
in the stack traces below. I'm not really sure what to make of it. Any 
ideas?



[ 1727.253743] kworker/0:2: page allocation failure: order:4, 
mode:0x14040c1(GFP_KERNEL|GFP_DMA|__GFP_COMP), nodemask=(null)
[ 1727.298438] CPU: 0 PID: 1913 Comm: kworker/0:2 Tainted: P 
4.15.0-rc2-08575-gbc02198-dirty #612

[ 1727.331513] Hardware name: Generic DA850/OMAP-L138/AM18x
[ 1727.354135] Workqueue: events drm_fb_helper_dirty_work [drm_kms_helper]
[ 1727.379355] Backtrace:
[ 1727.380665] [] (dump_backtrace) from [] 
(show_stack+0x18/0x1c)

[ 1727.423509]  r7:0040 r6:c0521840 r5:e000 r4:
[ 1727.434302] [] (show_stack) from [] 
(dump_stack+0x20/0x28)
[ 1727.468647] [] (dump_stack) from [] 
(warn_alloc+0x94/0x13c)
[ 1727.481443] [] (warn_alloc) from [] 
(__alloc_pages_nodemask+0x8d0/0xbd4)

[ 1727.514315]  r3:0004 r2:c0521840
[ 1727.524305]  r6:0023 r5: r4:c05c915c
[ 1727.530599] [] (__alloc_pages_nodemask) from [] 
(kmalloc_order+0x20/0x54)
[ 1727.554296]  r10: r9:6013 r8:c02f0e98 r7:014000c1 
r6:c2ae9d94 r5:a000

[ 1727.575312]  r4:
[ 1727.587963] [] (kmalloc_order) from [] 
(__kmalloc_track_caller+0x180/0x1a4)
[ 1727.624311] [] (__kmalloc_track_caller) from [] 
(krealloc+0x7c/0xc0)
[ 1727.654324]  r10: r9:6013 r8:c02f0e98 r7:014000c1 
r6:c2ae9d94 r5:a000

[ 1727.668407]  r4:
[ 1727.669779] [] (krealloc) from [] 
(__spi_pump_messages+0x4bc/0x584)
[ 1727.704329]  r9:6013 r8:c02ef590 r7: r6:c2ae9d94 
r5:c2b50c00 r4:a000
[ 1727.710940] [] (__spi_pump_messages) from [] 
(__spi_sync+0x250/0x284)
[ 1727.744313]  r10: r9:6013 r8:c02ef590 r7:c2b50c00 
r6:c2ae9d94 r5:c2b50400

[ 1727.751125]  r4:6013
[ 1727.752479] [] (__spi_sync) from [] 
(spi_sync+0x2c/0x44)
[ 1727.781959]  r9: r8:c305a000 r7:c2b50400 r6:c2ae9d94 
r5:c2ae9d94 r4:c2b50400
[ 1727.814395] [] (spi_sync) from [] 
(tinydrm_spi_transfer+0x118/0x1b8 [tinydrm])

[ 1727.822355]  r5:7ffc r4:
[ 1727.840616] [] (tinydrm_spi_transfer [tinydrm]) from 
[] (mipi_dbi_typec3_command+0x114/0x1cc [mipi_dbi])
[ 1727.874285]  r10:c05e67e4 r9: r8:0010 r7:c2b50400 
r6:c305 r5:c2bd6010

[ 1727.881098]  r4:a000
[ 1727.882486] [] (mipi_dbi_typec3_command [mipi_dbi]) from 
[] (mipi_dbi_command_buf+0x40/0x54 [mipi_dbi])

[ 1727.924298]  r8:a000 r7:c305 r6:bf2b32d8 r5:c2bd65c0 r4:c2bd6010
[ 1727.929891] [] (mipi_dbi_command_buf [mipi_dbi]) from 
[] (mipi_dbi_fb_dirty+0x18c/0x218 [mipi_dbi])
[ 1727.964291]  r9: r8:c305 r7:0001 r6:c1f7f600 
r5:c2bd65a0 r4:c2bd6010
[ 1727.971220] [] (mipi_dbi_fb_dirty [mipi_dbi]) from 
[] (drm_fb_helper_dirty_work+0xc8/0xe4 [drm_kms_helper])
[ 1728.004256]  r9: r8:c05e67e4 r7:c2f5d200 r6: 
r5:6013 r4:bf2b24dc
[ 1728.011371] [] (drm_fb_helper_dirty_work [drm_kms_helper]) 
from [] (process_one_work+0x140/0x454)

[ 1728.054256]  r5:c1f6de40 r4:c1e861f4
[ 1728.056676] [] (process_one_work) from [] 
(worker_thread+0x40/0x64c)
[ 1728.063570]  r10:c05e67e4 r9:c2ae8000 r8:0008 r7:c05f7220 
r6:c05e67f8 r5:c1f6de58

[ 1728.090392]  r4:c1f6de40
[ 1728.097104] [] (worker_thread) from [] 
(kthread+0x108/0x148)
[ 1728.103522]  r10:c1ced258 r9:c283bea4 r8:c1f6de40 r7:c2ae8000 
r6: r5:c058da00

[ 1728.144241]  r4:c1ced240
[ 1728.145601] [] (kthread) from [] 
(ret_from_fork+0x14/0x34)
[ 1728.152331]  r10: r9: r8: r7: 
r6: r5:c00382c4

[ 1728.182111]  r4:c058da00
[ 1728.183397] Mem-Info:
[ 1728.184877] active_anon:2927 inactive_anon:204 isolated_anon:0
active_file:2033 inactive_file:1830 isolated_file:0
unevictable:0 dirty:107 writeback:0 unstable:0
slab_reclaimable:996 slab_unreclaimable:1441
mapped:3107 shmem:320 pagetables:149 bounce:0
free:4279 free_pcp:0 free_cma:3098
[ 1728.254307] Node 0 active_anon:11732kB inactive_anon:792kB 
active_file:8188kB inactive_file:7376kB unevictable:0kB 
isolated(anon):0kB isolated(file):0kB mapped:12512kB dirty:456kB 
writeback:0kB shmem:1280kB writeback_tmp:0kB unstable:0kB 
all_unreclaimable? no
[ 1728.304296] DMA free:16988kB min:820kB low:1024kB high:1228kB 
active_anon:11748kB inactive_anon:776kB active_file:8192kB 
inactive_file:7428kB unevictable:0kB writepending:464kB present:65536kB 
managed:58704kB mlocked:0kB kernel_stack:488kB pagetables:596kB 
bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:12392kB

[ 1728.364196] lowmem_reserve[]: 0 0 0
[ 1728.366509] DMA: 527*4kB (UMEHC) 412*8kB (UMEHC) 196*16kB (UMEHC) 
106*32kB (UMEHC) 43*64kB (UEC) 14*128kB (UC) 2*256kB (C) 0*512kB 
0*1024kB 0*2048kB 0*4096kB = 16988kB

[ 1728.404211] 4225 total pagecache pages
[ 1728.406722] 16384 pages RAM
[ 1728.408239] 0 pages HighMem/MovableOnly
[ 1728.410796] 1708 pages reserved
[ 1728.412654] 4096 pages cma reserved
[ 1728.437308] st7735r spi1.0: 

Re: tinydrm: page allocation failure

[David Lechner]

On 12/11/2017 07:37 AM, Noralf Trønnes wrote:


Den 11.12.2017 13.45, skrev Noralf Trønnes:


Den 11.12.2017 04.28, skrev David Lechner:
I'm using drm-misc/drm-misc-next and occasionally getting errors as 
seen in the stack traces below. I'm not really sure what to make of 
it. Any ideas?




The spi controller driver has told the spi core to allocate dummy
buffers for tx/rx: spi_sync -> __spi_pump_messages -> spi_map_msg
-> krealloc -> __do_krealloc -> kmalloc_track_caller

order:4 means it's trying to allocate 2^4*PAGE_SIZE = 64kB, which
probably is the max DMA limit. So this is a pixel data transfer.

On my Raspberry Pi I've got 43 chunks of 64kB available if I have
understood this right:

$ sudo cat /proc/buddyinfo
Node 0, zone   Normal 40 68 66 51 43 46 
13  1  3  3 75


I don't know what those dummy buffers are used for.



tinydrm has a spi_max module parameter that can set the chunk size.
I have wondered if I should just remove this parameter when spi-bcm2835
has been fixed as explained here:
https://lists.freedesktop.org/archives/dri-devel/2017-February/132725.html
I'm figuring it is better to add this parameter if the problem arises 
again,

instead of preparing for something that might not be a problem anymore.

But now I'm reminded of this dummy buffer and if we were to send the entire
framebuffer in one go, the dummy buffer would have to be the same size as
the framebuffer. Not sure how well that works on long running boards with
little ram, to be able to allocate 320*480*2 = 300kB ~= 512kB (continous)
for the largest SPI displays on every flush, after months of run time.

How much ram do you have on the Lego module?


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

Re: [PATCH v1 1/2] dt-bindings: Add binding for Sitronix ST7735R display panels

[David Lechner]

On 12/08/2017 03:41 PM, Noralf Trønnes wrote:


Den 29.11.2017 04.01, skrev David Lechner:

This adds a new device tree binding for Sitronix ST7735R display panels,
such as the Adafruit 1.8" TFT.

Signed-off-by: David Lechner <da...@lechnology.com>
---
  .../bindings/display/sitronix,st7735r.txt  | 35 
++

  1 file changed, 35 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/sitronix,st7735r.txt


diff --git 
a/Documentation/devicetree/bindings/display/sitronix,st7735r.txt 
b/Documentation/devicetree/bindings/display/sitronix,st7735r.txt

new file mode 100644
index 000..bbb8ba6
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sitronix,st7735r.txt
@@ -0,0 +1,35 @@
+Sitronix ST7735R display panels
+
+This binding is for display panels using a Sitronix ST7735R 
controller in SPI

+mode.
+
+Required properties:
+- compatible:    "sitronix,st7735r-jd-t18003-t01"
+- dc-gpios:    Display data/command selection (D/CX)
+- reset-gpios:    Reset signal (RSTX)


I'm wondering if this should be optional.

Even though the display needs the reset line to be driven, it doesn't
have to be so by a gpio, I believe you can even get away with just
using a resistor as a reset circuit.

Not terribly important, it's up to you.



It can be made optional later if needed, so I'm going to leave it as-is.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/2] DRM driver for Sitronix ST7735R display panels

[David Lechner]

This series adds a new DRM/TinyDRM driver for Sitronix ST7735R, specifically
the Adafruit 1.8" TFT.

Nothing fancy here. Just mostly TinyDRM boilerplate with the init sequence
from the fbtft driver for the same panel.

Please see new discussion on device tree bindings in patch 1/2.

David Lechner (2):
  dt-bindings: Add binding for Sitronix ST7735R display panels
  drm/tinydrm: add driver for ST7735R panels

 .../bindings/display/sitronix,st7735r.txt  |  35 
 MAINTAINERS|   6 +
 drivers/gpu/drm/tinydrm/Kconfig|  10 +
 drivers/gpu/drm/tinydrm/Makefile   |   1 +
 drivers/gpu/drm/tinydrm/st7735r.c  | 219 +
 5 files changed, 271 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/sitronix,st7735r.txt
 create mode 100644 drivers/gpu/drm/tinydrm/st7735r.c

-- 
2.7.4

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

[PATCH v2 2/2] drm/tinydrm: add driver for ST7735R panels

[David Lechner]

This adds a new driver for Sitronix ST7735R display panels.

This has been tested using an Adafruit 1.8" TFT.

Signed-off-by: David Lechner <da...@lechnology.com>
---

v2 changes:
* Change delay from 10ms to 20ms to avoid checkpatch warning
* Use mipi_dbi_pipe_enable()/mipi_dbi_pipe_disable() to reduce duplicated code
* Rebase on drm-misc-next (tinydrm_lastclose => drm_fb_helper_lastclose)
* Use mipi_dbi_debugfs_init
* Add mipi->read_commands = NULL; since this display is write-only


 MAINTAINERS   |   6 ++
 drivers/gpu/drm/tinydrm/Kconfig   |  10 ++
 drivers/gpu/drm/tinydrm/Makefile  |   1 +
 drivers/gpu/drm/tinydrm/st7735r.c | 219 ++
 4 files changed, 236 insertions(+)
 create mode 100644 drivers/gpu/drm/tinydrm/st7735r.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 0e49099..2ce17f5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4551,6 +4551,12 @@ S:   Maintained
 F: drivers/gpu/drm/tinydrm/st7586.c
 F: Documentation/devicetree/bindings/display/st7586.txt
 
+DRM DRIVER FOR SITRONIX ST7735R PANELS
+M: David Lechner <da...@lechnology.com>
+S: Maintained
+F: drivers/gpu/drm/tinydrm/st7735r.c
+F: Documentation/devicetree/bindings/display/st7735r.txt
+
 DRM DRIVER FOR TDFX VIDEO CARDS
 S: Orphan / Obsolete
 F: drivers/gpu/drm/tdfx/
diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index 90c5bd5..b0e567d 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -52,3 +52,13 @@ config TINYDRM_ST7586
  * LEGO MINDSTORMS EV3
 
  If M is selected the module will be called st7586.
+
+config TINYDRM_ST7735R
+   tristate "DRM support for Sitronix ST7735R display panels"
+   depends on DRM_TINYDRM && SPI
+   select TINYDRM_MIPI_DBI
+   help
+ DRM driver Sitronix ST7735R with one of the following LCDs:
+ * JD-T18003-T01 1.8" 128x160 TFT
+
+ If M is selected the module will be called st7735r.
diff --git a/drivers/gpu/drm/tinydrm/Makefile b/drivers/gpu/drm/tinydrm/Makefile
index 8aeee53..49a1119 100644
--- a/drivers/gpu/drm/tinydrm/Makefile
+++ b/drivers/gpu/drm/tinydrm/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_TINYDRM_ILI9225)   += ili9225.o
 obj-$(CONFIG_TINYDRM_MI0283QT) += mi0283qt.o
 obj-$(CONFIG_TINYDRM_REPAPER)  += repaper.o
 obj-$(CONFIG_TINYDRM_ST7586)   += st7586.o
+obj-$(CONFIG_TINYDRM_ST7735R)  += st7735r.o
diff --git a/drivers/gpu/drm/tinydrm/st7735r.c 
b/drivers/gpu/drm/tinydrm/st7735r.c
new file mode 100644
index 000..0f5c295
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/st7735r.c
@@ -0,0 +1,219 @@
+/*
+ * DRM driver for Sitronix ST7735R panels
+ *
+ * Copyright 2017 David Lechner <da...@lechnology.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define ST7735R_FRMCTR10xb1
+#define ST7735R_FRMCTR20xb2
+#define ST7735R_FRMCTR30xb3
+#define ST7735R_INVCTR 0xb4
+#define ST7735R_PWCTR1 0xc0
+#define ST7735R_PWCTR2 0xc1
+#define ST7735R_PWCTR3 0xc2
+#define ST7735R_PWCTR4 0xc3
+#define ST7735R_PWCTR5 0xc4
+#define ST7735R_VMCTR1 0xc5
+#define ST7735R_GAMCTRP1   0xe0
+#define ST7735R_GAMCTRN1   0xe1
+
+#define ST7735R_MY BIT(7)
+#define ST7735R_MX BIT(6)
+#define ST7735R_MV BIT(5)
+
+static void st7735r_pipe_enable(struct drm_simple_display_pipe *pipe,
+   struct drm_crtc_state *crtc_state)
+{
+   struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
+   struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
+   struct device *dev = tdev->drm->dev;
+   int ret;
+   u8 addr_mode;
+
+   DRM_DEBUG_KMS("\n");
+
+   mipi_dbi_hw_reset(mipi);
+
+   ret = mipi_dbi_command(mipi, MIPI_DCS_SOFT_RESET);
+   if (ret) {
+   DRM_DEV_ERROR(dev, "Error sending command %d\n", ret);
+   return;
+   }
+
+   msleep(150);
+
+   mipi_dbi_command(mipi, MIPI_DCS_EXIT_SLEEP_MODE);
+   msleep(500);
+
+   mipi_dbi_command(mipi, ST7735R_FRMCTR1, 0x01, 0x2c, 0x2d);
+   mipi_dbi_command(mipi, ST7735R_FRMCTR2, 0x01, 0x2c, 0x2d);
+   mipi_dbi_command(mipi, ST7735R_FRMCTR3, 0x01, 0x2c, 0x2d, 0x01, 0x2c,
+0x2d);
+   mipi_dbi_command(mipi, ST7735R_INVCTR, 0x07);
+   mipi_dbi_command(mipi, ST7735R_PWCTR1, 0xa2, 0x02, 0x84);
+   mipi_dbi_command(mipi, ST7735R_PWCTR2, 0xc5);
+   mipi_dbi_command(mipi, ST7735R_

Re: [PATCH v2 2/2] drm/tinydrm: add driver for ST7735R panels

[David Lechner]

On 12/11/2017 03:18 PM, Noralf Trønnes wrote:


Den 10.12.2017 23.10, skrev David Lechner:

This adds a new driver for Sitronix ST7735R display panels.

This has been tested using an Adafruit 1.8" TFT.

Signed-off-by: David Lechner <da...@lechnology.com>
---



+static void st7735r_pipe_enable(struct drm_simple_display_pipe *pipe,
+    struct drm_crtc_state *crtc_state)
+{
+    struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
+    struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
+    struct device *dev = tdev->drm->dev;
+    int ret;
+    u8 addr_mode;
+
+    DRM_DEBUG_KMS("\n");
+
+    mipi_dbi_hw_reset(mipi);
+
+    ret = mipi_dbi_command(mipi, MIPI_DCS_SOFT_RESET);
+    if (ret) {
+    DRM_DEV_ERROR(dev, "Error sending command %d\n", ret);
+    return;
+    }
+
+    msleep(150);
+
+    mipi_dbi_command(mipi, MIPI_DCS_EXIT_SLEEP_MODE);
+    msleep(500);
+
+    mipi_dbi_command(mipi, ST7735R_FRMCTR1, 0x01, 0x2c, 0x2d);
+    mipi_dbi_command(mipi, ST7735R_FRMCTR2, 0x01, 0x2c, 0x2d);
+    mipi_dbi_command(mipi, ST7735R_FRMCTR3, 0x01, 0x2c, 0x2d, 0x01, 
0x2c,

+ 0x2d);
+    mipi_dbi_command(mipi, ST7735R_INVCTR, 0x07);
+    mipi_dbi_command(mipi, ST7735R_PWCTR1, 0xa2, 0x02, 0x84);
+    mipi_dbi_command(mipi, ST7735R_PWCTR2, 0xc5);
+    mipi_dbi_command(mipi, ST7735R_PWCTR3, 0x0a, 0x00);
+    mipi_dbi_command(mipi, ST7735R_PWCTR4, 0x8a, 0x2a);
+    mipi_dbi_command(mipi, ST7735R_PWCTR5, 0x8a, 0xee);
+    mipi_dbi_command(mipi, ST7735R_VMCTR1, 0x0e);
+    mipi_dbi_command(mipi, MIPI_DCS_EXIT_INVERT_MODE);
+    switch (mipi->rotation) {
+    default:
+    addr_mode = ST7735R_MX | ST7735R_MY;
+    break;
+    case 90:
+    addr_mode = ST7735R_MX | ST7735R_MV;
+    break;
+    case 180:
+    addr_mode = 0;
+    break;
+    case 270:
+    addr_mode = ST7735R_MY | ST7735R_MV;
+    break;
+    }
+    mipi_dbi_command(mipi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
+    mipi_dbi_command(mipi, MIPI_DCS_SET_PIXEL_FORMAT,
+ MIPI_DCS_PIXEL_FMT_16BIT);
+    mipi_dbi_command(mipi, ST7735R_GAMCTRP1, 0x0f, 0x1a, 0x0f, 0x18, 
0x2f,

+ 0x28, 0x20, 0x22, 0x1f, 0x1b, 0x23, 0x37, 0x00, 0x07,
+ 0x02, 0x10);
+    mipi_dbi_command(mipi, ST7735R_GAMCTRN1, 0x0f, 0x1b, 0x0f, 0x17, 
0x33,

+ 0x2c, 0x29, 0x2e, 0x30, 0x30, 0x39, 0x3f, 0x00, 0x07,
+ 0x03, 0x10);
+    mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_ON);
+
+    msleep(100);
+
+    mipi_dbi_command(mipi, MIPI_DCS_ENTER_NORMAL_MODE);
+
+    msleep(20);
+
+    mipi_dbi_pipe_enable(pipe, crtc_state);
+}
+
+static const struct drm_simple_display_pipe_funcs st7735r_pipe_funcs = {
+    .enable    = st7735r_pipe_enable,
+    .disable    = mipi_dbi_pipe_disable,
+    .update    = tinydrm_display_pipe_update,
+    .prepare_fb    = tinydrm_display_pipe_prepare_fb,
+};
+
+static const struct drm_display_mode st7735r_mode = {
+    TINYDRM_MODE(128, 160, 28, 35),
+};


This naming talk has made me realise that these should be named after
the panel since they're not generic controller functions.
Maybe the mode can be generic, not sure if the physical size can/will
differ, the resolution is very likely to be the same for all.


Adafruit has a 1.44" 128x128px display [1] with the same controller, so 
the answer is no, the mode cannot be generic.


[1]: https://www.adafruit.com/product/2088


What's your view on my descision to split the MIPI DBI compatible
controllers into per controller drivers instead of having one driver
that supports them all?


My first impression was that I didn't like it so much. But now, I 
actually think that it is a good idea. I think it is a good compromise 
between some boilerplate code in every driver and a driver with so many 
quirks that it is very difficult to work on. It may make sense to 
combine some very similar controllers, but as a rule of thumb, I think 
one driver per controller will work nicely.



I've been afraid that it will be a very big file with macro definitions
per controller and enable functions per panel.

This driver has 15 macros and ~80 panel specific lines.
With one panel supported, half the driver is boilerplate.
The mi0283qt panel (MIPI DBI compatible) is in the same ballpark.

Adding helpers for panel reset/exit_sleep, for MIPI_DCS_SET_ADDRESS_MODE
and for display_on/enter_normal/flush could cut it down some more if we
made one driver to rule them all. Maybe the enable function per panel
could be cut in half that way.

I'm starting to wonder if one driver isn't such a bad solution after all...


I think as we add more drivers, the parts that get duplicated will 
become obvious candidates for helper functions to refactor, but I don't 
think trying to cram everything all into one driver is such a good idea.

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

[PATCH 3/3] drm/tinydrm: new driver for ILI9341 display panels

[David Lechner]

This adds a new driver for display panels that use the Ilitek ILI9341
controller. It currently supports a single display panel, namely
the YX240QV29-T (e.g. Adafruit 2.4" TFT).

The init sequence is from the Adafruit Python library for the ILI9341
controller. https://github.com/adafruit/Adafruit_Python_ILI9341

Signed-off-by: David Lechner <da...@lechnology.com>
---
 MAINTAINERS   |   6 +
 drivers/gpu/drm/tinydrm/Kconfig   |  10 ++
 drivers/gpu/drm/tinydrm/Makefile  |   1 +
 drivers/gpu/drm/tinydrm/ili9341.c | 239 ++
 4 files changed, 256 insertions(+)
 create mode 100644 drivers/gpu/drm/tinydrm/ili9341.c

diff --git a/MAINTAINERS b/MAINTAINERS
index bc219de9cbee..ffa099abbd79 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4480,6 +4480,12 @@ S:   Maintained
 F: drivers/gpu/drm/tinydrm/ili9225.c
 F: Documentation/devicetree/bindings/display/ilitek,ili9225.txt
 
+DRM DRIVER FOR ILITEK ILI9341 PANELS
+M: David Lechner <da...@lechnology.com>
+S: Maintained
+F: drivers/gpu/drm/tinydrm/ili9341.c
+F: Documentation/devicetree/bindings/display/ilitek,ili9341.txt
+
 DRM DRIVER FOR INTEL I810 VIDEO CARDS
 S: Orphan / Obsolete
 F: drivers/gpu/drm/i810/
diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index 4592a5e3f20b..7a8008b0783f 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -20,6 +20,16 @@ config TINYDRM_ILI9225
 
  If M is selected the module will be called ili9225.
 
+config TINYDRM_ILI9341
+   tristate "DRM support for ILI9341 display panels"
+   depends on DRM_TINYDRM && SPI
+   select TINYDRM_MIPI_DBI
+   help
+ DRM driver for the following Ilitek ILI9341 panels:
+ * YX240QV29-T 2.4" 240x320 TFT (Adafruit 2.4")
+
+ If M is selected the module will be called ili9341.
+
 config TINYDRM_MI0283QT
tristate "DRM support for MI0283QT"
depends on DRM_TINYDRM && SPI
diff --git a/drivers/gpu/drm/tinydrm/Makefile b/drivers/gpu/drm/tinydrm/Makefile
index 49a111929724..14d99080665a 100644
--- a/drivers/gpu/drm/tinydrm/Makefile
+++ b/drivers/gpu/drm/tinydrm/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_TINYDRM_MIPI_DBI)  += mipi-dbi.o
 
 # Displays
 obj-$(CONFIG_TINYDRM_ILI9225)  += ili9225.o
+obj-$(CONFIG_TINYDRM_ILI9341)  += ili9341.o
 obj-$(CONFIG_TINYDRM_MI0283QT) += mi0283qt.o
 obj-$(CONFIG_TINYDRM_REPAPER)  += repaper.o
 obj-$(CONFIG_TINYDRM_ST7586)   += st7586.o
diff --git a/drivers/gpu/drm/tinydrm/ili9341.c 
b/drivers/gpu/drm/tinydrm/ili9341.c
new file mode 100644
index ..2ce4244a68c3
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/ili9341.c
@@ -0,0 +1,239 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * DRM driver for Ilitek ILI9341 panels
+ *
+ * Copyright 2018 David Lechner <da...@lechnology.com>
+ *
+ * Based on mi0283qt.c:
+ * Copyright 2016 Noralf Trønnes
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ILI9341_FRMCTR10xb1
+#define ILI9341_DISCTRL0xb6
+#define ILI9341_ETMOD  0xb7
+
+#define ILI9341_PWCTRL10xc0
+#define ILI9341_PWCTRL20xc1
+#define ILI9341_VMCTRL10xc5
+#define ILI9341_VMCTRL20xc7
+#define ILI9341_PWCTRLA0xcb
+#define ILI9341_PWCTRLB0xcf
+
+#define ILI9341_PGAMCTRL   0xe0
+#define ILI9341_NGAMCTRL   0xe1
+#define ILI9341_DTCTRLA0xe8
+#define ILI9341_DTCTRLB0xea
+#define ILI9341_PWRSEQ 0xed
+
+#define ILI9341_EN3GAM 0xf2
+#define ILI9341_PUMPCTRL   0xf7
+
+#define ILI9341_MADCTL_BGR BIT(3)
+#define ILI9341_MADCTL_MV  BIT(5)
+#define ILI9341_MADCTL_MX  BIT(6)
+#define ILI9341_MADCTL_MY  BIT(7)
+
+static void yx240qv29_enable(struct drm_simple_display_pipe *pipe,
+struct drm_crtc_state *crtc_state,
+struct drm_plane_state *plane_state)
+{
+   struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
+   struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
+   u8 addr_mode;
+   int ret;
+
+   DRM_DEBUG_KMS("\n");
+
+   ret = mipi_dbi_poweron_conditional_reset(mipi);
+   if (ret < 0)
+   return;
+   if (ret == 1)
+   goto out_enable;
+
+   mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_OFF);
+
+   mipi_dbi_command(mipi, ILI9341_PWCTRLB, 0x00, 0xc1, 0x30);
+   mipi_dbi_command(mipi, ILI9341_PWRSEQ, 0x64, 0x03, 0x12, 0x81);
+   mipi_dbi_command(mipi, ILI9341_DTCTRLA, 0x85, 0x00, 0x78);
+   mipi_dbi_command(mipi, ILI9341_PWCTRLA, 0x39, 0x2c, 0x00, 0x34, 0x02);
+   mipi_dbi_command(mipi, ILI9341_PUMPCTRL, 0x20

[PATCH 2/3] dt-bindings: new binding for Ilitek ILI9341 display panels

[David Lechner]

This adds a new binding for Ilitek ILI9341 display panels. It includes
a compatible string for one display (more can be added in the future).

The vendor prefix "noname" is used because the vendor is not known.
The YX240QV29-T panel[1] is found, for example, in an Adafruit breakout
board[2] and in Mindsensors' PiStorms[3].

[1]: 
https://cdn-learn.adafruit.com/assets/assets/000/046/879/original/SPEC-YX240QV29-T_Rev.A__1_.pdf
[2]: https://www.adafruit.com/product/2478
[3]: 
http://www.mindsensors.com/stem-with-robotics/13-pistorms-v2-base-kit-raspberry-pi-brain-for-lego-robot

Signed-off-by: David Lechner <da...@lechnology.com>
---
 .../bindings/display/ilitek,ili9341.txt   | 27 +++
 1 file changed, 27 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9341.txt

diff --git a/Documentation/devicetree/bindings/display/ilitek,ili9341.txt 
b/Documentation/devicetree/bindings/display/ilitek,ili9341.txt
new file mode 100644
index ..0fc90b2dd732
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ilitek,ili9341.txt
@@ -0,0 +1,27 @@
+Ilitek ILI9341 display panels
+
+This binding is for display panels using an Ilitek ILI9341 controller in SPI
+mode.
+
+Required properties:
+- compatible:  "noname,yx240qv29", "ilitek,ili9341"
+- dc-gpios:D/C pin
+- reset-gpios: Reset pin
+
+The node for this driver must be a child node of a SPI controller, hence
+all mandatory properties described in ../spi/spi-bus.txt must be specified.
+
+Optional properties:
+- rotation:panel rotation in degrees counter clockwise (0,90,180,270)
+- backlight:   phandle of the backlight device attached to the panel
+
+Example:
+   display@0{
+   compatible = "noname,yx240qv29", "ilitek,ili9341";
+   reg = <0>;
+   spi-max-frequency = <3200>;
+   dc-gpios = < 9 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 8 GPIO_ACTIVE_HIGH>;
+   rotation = <270>;
+   backlight = <>;
+   };
-- 
2.17.0

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

[PATCH 0/3] drm/tinydrm: new dirver for ILI9341 displays

[David Lechner]

This series adds a new tinydrm driver for the Ilitek ILI9341 controller and
a 2.4" display panel that uses this controller.

A few things to note here:
* The datasheet for this display[1] doesn't have a vendor mentioned on it
  anywhere, so I have used "noname" as the vendor prefix. If someone has a
  better suggestion, please speak up.
* The driver is basically a copy of mi0283qt.c with a new init sequence,
  a different physical panel size, fixed (as in corrected) rotation handling,
  and dropped PM (since I don't have a way to test it). Do we want to try to
  share code with these two drivers (it's not much)?
* The MAINTAINERS patch for ili9225 is included so we don't end up with a merge
  conflict later on.

[1]: 
https://cdn-learn.adafruit.com/assets/assets/000/046/879/original/SPEC-YX240QV29-T_Rev.A__1_.pdf

David Lechner (3):
  MAINTAINERS: fix path to ilitek,ili9225 device tree bindings
  dt-bindings: new binding for Ilitek ILI9341 display panels
  drm/tinydrm: new driver for ILI9341 display panels

 .../bindings/display/ilitek,ili9341.txt   |  27 ++
 MAINTAINERS   |   8 +-
 drivers/gpu/drm/tinydrm/Kconfig   |  10 +
 drivers/gpu/drm/tinydrm/Makefile  |   1 +
 drivers/gpu/drm/tinydrm/ili9341.c | 239 ++
 5 files changed, 284 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9341.txt
 create mode 100644 drivers/gpu/drm/tinydrm/ili9341.c

-- 
2.17.0

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

[PATCH 1/3] MAINTAINERS: fix path to ilitek, ili9225 device tree bindings

[David Lechner]

This fixes the path to the ilitek,ili9225 device tree binding file.

Signed-off-by: David Lechner <da...@lechnology.com>
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 334a00350922..bc219de9cbee 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4478,7 +4478,7 @@ DRM DRIVER FOR ILITEK ILI9225 PANELS
 M: David Lechner <da...@lechnology.com>
 S: Maintained
 F: drivers/gpu/drm/tinydrm/ili9225.c
-F: Documentation/devicetree/bindings/display/ili9225.txt
+F: Documentation/devicetree/bindings/display/ilitek,ili9225.txt
 
 DRM DRIVER FOR INTEL I810 VIDEO CARDS
 S: Orphan / Obsolete
-- 
2.17.0

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

Re: [PATCH] drm/tilcdc: Fix setting clock divider for omap-l138

[David Lechner]

On 03/19/2018 04:05 AM, Jyri Sarha wrote:

Thanks,
I'll pick this for v4.18.


Ping. I don't see this in drm-misc-next yet.

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

Re: [PATCH 2/3] dt-bindings: new binding for Ilitek ILI9341 display panels

[David Lechner]

On 05/19/2018 08:37 AM, Noralf Trønnes wrote:


Den 15.05.2018 03.43, skrev David Lechner:

This adds a new binding for Ilitek ILI9341 display panels. It includes
a compatible string for one display (more can be added in the future).

The vendor prefix "noname" is used because the vendor is not known.
The YX240QV29-T panel[1] is found, for example, in an Adafruit breakout
board[2] and in Mindsensors' PiStorms[3].

[1]: 
https://cdn-learn.adafruit.com/assets/assets/000/046/879/original/SPEC-YX240QV29-T_Rev.A__1_.pdf
[2]: https://www.adafruit.com/product/2478
[3]: 
http://www.mindsensors.com/stem-with-robotics/13-pistorms-v2-base-kit-raspberry-pi-brain-for-lego-robot

Signed-off-by: David Lechner <da...@lechnology.com>
---
  .../bindings/display/ilitek,ili9341.txt   | 27 +++
  1 file changed, 27 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/ilitek,ili9341.txt

diff --git a/Documentation/devicetree/bindings/display/ilitek,ili9341.txt 
b/Documentation/devicetree/bindings/display/ilitek,ili9341.txt
new file mode 100644
index ..0fc90b2dd732
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ilitek,ili9341.txt
@@ -0,0 +1,27 @@
+Ilitek ILI9341 display panels
+
+This binding is for display panels using an Ilitek ILI9341 controller in SPI
+mode.
+
+Required properties:
+- compatible:    "noname,yx240qv29", "ilitek,ili9341"


Calling a vendor 'noname' looks a bit odd and AFAICT it isn't used by
any other binding. A google search always mentions Adafruit in
connection with this panel, so I suggest we use Adafruit as vendor.


I was hoping that someone might know the correct vendor, but barring that,
I agree that adafruit is probably the best choice.



I don't think we should use "ilitek,ili9341" as an option/fallback,
because panels varies in resolution (rarely) and initialization. A
generic ili9341 driver would probably not work with a random new panel.


I'm just following the precedent set in the other bindings for similar
displays that I have already done.

References:
* https://patchwork.freedesktop.org/patch/194648/
* https://patchwork.freedesktop.org/patch/195320/

I agree that it is probably not super-useful as a fallback. On the other
hand, the vendors and models for these displays are pretty obscure and
I think having the more well-known controller name _somewhere_ is useful.





+- dc-gpios:    D/C pin
+- reset-gpios:    Reset pin
+
+The node for this driver must be a child node of a SPI controller, hence
+all mandatory properties described in ../spi/spi-bus.txt must be specified.
+
+Optional properties:
+- rotation:    panel rotation in degrees counter clockwise (0,90,180,270)
+- backlight:    phandle of the backlight device attached to the panel


You forgot to mention the regulator that you support in the driver.

Noralf.


+
+Example:
+    display@0{
+    compatible = "noname,yx240qv29", "ilitek,ili9341";
+    reg = <0>;
+    spi-max-frequency = <3200>;
+    dc-gpios = < 9 GPIO_ACTIVE_HIGH>;
+    reset-gpios = < 8 GPIO_ACTIVE_HIGH>;
+    rotation = <270>;
+    backlight = <>;
+    };




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

[PATCH v2 2/4] dt-bindings: Add vendor prefix for Adafruit

[David Lechner]

This adds a device tree vendor prefix for Adafruit Industries, LLC.

Signed-off-by: David Lechner <da...@lechnology.com>
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index b5f978a4cac6..4d2ba7f52059 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -8,6 +8,7 @@ abracon Abracon Corporation
 actionsActions Semiconductor Co., Ltd.
 active-semiActive-Semi International Inc
 ad Avionic Design GmbH
+adafruit   Adafruit Industries, LLC
 adapteva   Adapteva, Inc.
 adaptrum   Adaptrum, Inc.
 adhAD Holdings Plc.
-- 
2.17.0

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

[PATCH v2 4/4] drm/tinydrm: new driver for ILI9341 display panels

[David Lechner]

This adds a new driver for display panels that use the Ilitek ILI9341
controller. It currently supports a single display panel, namely
the YX240QV29-T (e.g. Adafruit 2.4" TFT).

The init sequence is from the Adafruit Python library for the ILI9341
controller. https://github.com/adafruit/Adafruit_Python_ILI9341

Signed-off-by: David Lechner <da...@lechnology.com>
Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com>
Reviewed-by: Noralf Trønnes <nor...@tronnes.org>
---
 MAINTAINERS   |   6 +
 drivers/gpu/drm/tinydrm/Kconfig   |  10 ++
 drivers/gpu/drm/tinydrm/Makefile  |   1 +
 drivers/gpu/drm/tinydrm/ili9341.c | 233 ++
 4 files changed, 250 insertions(+)
 create mode 100644 drivers/gpu/drm/tinydrm/ili9341.c

diff --git a/MAINTAINERS b/MAINTAINERS
index bc219de9cbee..ffa099abbd79 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4480,6 +4480,12 @@ S:   Maintained
 F: drivers/gpu/drm/tinydrm/ili9225.c
 F: Documentation/devicetree/bindings/display/ilitek,ili9225.txt
 
+DRM DRIVER FOR ILITEK ILI9341 PANELS
+M: David Lechner <da...@lechnology.com>
+S: Maintained
+F: drivers/gpu/drm/tinydrm/ili9341.c
+F: Documentation/devicetree/bindings/display/ilitek,ili9341.txt
+
 DRM DRIVER FOR INTEL I810 VIDEO CARDS
 S: Orphan / Obsolete
 F: drivers/gpu/drm/i810/
diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index 4592a5e3f20b..7a8008b0783f 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -20,6 +20,16 @@ config TINYDRM_ILI9225
 
  If M is selected the module will be called ili9225.
 
+config TINYDRM_ILI9341
+   tristate "DRM support for ILI9341 display panels"
+   depends on DRM_TINYDRM && SPI
+   select TINYDRM_MIPI_DBI
+   help
+ DRM driver for the following Ilitek ILI9341 panels:
+ * YX240QV29-T 2.4" 240x320 TFT (Adafruit 2.4")
+
+ If M is selected the module will be called ili9341.
+
 config TINYDRM_MI0283QT
tristate "DRM support for MI0283QT"
depends on DRM_TINYDRM && SPI
diff --git a/drivers/gpu/drm/tinydrm/Makefile b/drivers/gpu/drm/tinydrm/Makefile
index 49a111929724..14d99080665a 100644
--- a/drivers/gpu/drm/tinydrm/Makefile
+++ b/drivers/gpu/drm/tinydrm/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_TINYDRM_MIPI_DBI)  += mipi-dbi.o
 
 # Displays
 obj-$(CONFIG_TINYDRM_ILI9225)  += ili9225.o
+obj-$(CONFIG_TINYDRM_ILI9341)  += ili9341.o
 obj-$(CONFIG_TINYDRM_MI0283QT) += mi0283qt.o
 obj-$(CONFIG_TINYDRM_REPAPER)  += repaper.o
 obj-$(CONFIG_TINYDRM_ST7586)   += st7586.o
diff --git a/drivers/gpu/drm/tinydrm/ili9341.c 
b/drivers/gpu/drm/tinydrm/ili9341.c
new file mode 100644
index ..8864dcde6edc
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/ili9341.c
@@ -0,0 +1,233 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * DRM driver for Ilitek ILI9341 panels
+ *
+ * Copyright 2018 David Lechner <da...@lechnology.com>
+ *
+ * Based on mi0283qt.c:
+ * Copyright 2016 Noralf Trønnes
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ILI9341_FRMCTR10xb1
+#define ILI9341_DISCTRL0xb6
+#define ILI9341_ETMOD  0xb7
+
+#define ILI9341_PWCTRL10xc0
+#define ILI9341_PWCTRL20xc1
+#define ILI9341_VMCTRL10xc5
+#define ILI9341_VMCTRL20xc7
+#define ILI9341_PWCTRLA0xcb
+#define ILI9341_PWCTRLB0xcf
+
+#define ILI9341_PGAMCTRL   0xe0
+#define ILI9341_NGAMCTRL   0xe1
+#define ILI9341_DTCTRLA0xe8
+#define ILI9341_DTCTRLB0xea
+#define ILI9341_PWRSEQ 0xed
+
+#define ILI9341_EN3GAM 0xf2
+#define ILI9341_PUMPCTRL   0xf7
+
+#define ILI9341_MADCTL_BGR BIT(3)
+#define ILI9341_MADCTL_MV  BIT(5)
+#define ILI9341_MADCTL_MX  BIT(6)
+#define ILI9341_MADCTL_MY  BIT(7)
+
+static void yx240qv29_enable(struct drm_simple_display_pipe *pipe,
+struct drm_crtc_state *crtc_state,
+struct drm_plane_state *plane_state)
+{
+   struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
+   struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
+   u8 addr_mode;
+   int ret;
+
+   DRM_DEBUG_KMS("\n");
+
+   ret = mipi_dbi_poweron_conditional_reset(mipi);
+   if (ret < 0)
+   return;
+   if (ret == 1)
+   goto out_enable;
+
+   mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_OFF);
+
+   mipi_dbi_command(mipi, ILI9341_PWCTRLB, 0x00, 0xc1, 0x30);
+   mipi_dbi_command(mipi, ILI9341_PWRSEQ, 0x64, 0x03, 0x12, 0x81);
+   mipi_dbi_command(mipi, ILI9341_DTCTRLA, 0x85, 0x00, 0x78);
+   mipi_d

[PATCH v2 0/4] drm/tinydrm: new dirver for ILI9341 displays

[David Lechner]

This series adds a new tinydrm driver for the Ilitek ILI9341 controller and
a 2.4" display panel that uses this controller.

A few things to note here:
* The datasheet for this display[1] doesn't have a vendor mentioned on it
  anywhere, so I have used "adafruit" as the vendor prefix. If someone has a
  better suggestion, please speak up.
* The MAINTAINERS patch for ili9225 is included so we don't end up with a merge
  conflict later on.

v2 changes:
* change vendor prefix from "noname" to "adafruit"
* new patch for "adafruit" vendor prefix
* minor style changes
* drop regulator from driver (instead of adding to DT bindings)

[1]: 
https://cdn-learn.adafruit.com/assets/assets/000/046/879/original/SPEC-YX240QV29-T_Rev.A__1_.pdf


David Lechner (4):
  MAINTAINERS: fix path to ilitek,ili9225 device tree bindings
  dt-bindings: Add vendor prefix for Adafruit
  dt-bindings: new binding for Ilitek ILI9341 display panels
  drm/tinydrm: new driver for ILI9341 display panels

 .../bindings/display/ilitek,ili9341.txt   |  27 ++
 .../devicetree/bindings/vendor-prefixes.txt   |   1 +
 MAINTAINERS   |   8 +-
 drivers/gpu/drm/tinydrm/Kconfig   |  10 +
 drivers/gpu/drm/tinydrm/Makefile  |   1 +
 drivers/gpu/drm/tinydrm/ili9341.c | 233 ++
 6 files changed, 279 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9341.txt
 create mode 100644 drivers/gpu/drm/tinydrm/ili9341.c

-- 
2.17.0

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

[PATCH v2 1/4] MAINTAINERS: fix path to ilitek, ili9225 device tree bindings

[David Lechner]

This fixes the path to the ilitek,ili9225 device tree binding file.

Signed-off-by: David Lechner <da...@lechnology.com>
Reviewed-by: Noralf Trønnes <nor...@tronnes.org>
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 334a00350922..bc219de9cbee 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4478,7 +4478,7 @@ DRM DRIVER FOR ILITEK ILI9225 PANELS
 M: David Lechner <da...@lechnology.com>
 S: Maintained
 F: drivers/gpu/drm/tinydrm/ili9225.c
-F: Documentation/devicetree/bindings/display/ili9225.txt
+F: Documentation/devicetree/bindings/display/ilitek,ili9225.txt
 
 DRM DRIVER FOR INTEL I810 VIDEO CARDS
 S: Orphan / Obsolete
-- 
2.17.0

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

[PATCH v2 3/4] dt-bindings: new binding for Ilitek ILI9341 display panels

[David Lechner]

This adds a new binding for Ilitek ILI9341 display panels. It includes
a compatible string for one display (more can be added in the future).

The vendor prefix "noname" is used because the vendor is not known.
The YX240QV29-T panel[1] is found, for example, in an Adafruit breakout
board[2] and in Mindsensors' PiStorms[3].

[1]: 
https://cdn-learn.adafruit.com/assets/assets/000/046/879/original/SPEC-YX240QV29-T_Rev.A__1_.pdf
[2]: https://www.adafruit.com/product/2478
[3]: 
http://www.mindsensors.com/stem-with-robotics/13-pistorms-v2-base-kit-raspberry-pi-brain-for-lego-robot

Signed-off-by: David Lechner <da...@lechnology.com>
---
 .../bindings/display/ilitek,ili9341.txt   | 27 +++
 1 file changed, 27 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9341.txt

diff --git a/Documentation/devicetree/bindings/display/ilitek,ili9341.txt 
b/Documentation/devicetree/bindings/display/ilitek,ili9341.txt
new file mode 100644
index ..169b32e4ee4e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ilitek,ili9341.txt
@@ -0,0 +1,27 @@
+Ilitek ILI9341 display panels
+
+This binding is for display panels using an Ilitek ILI9341 controller in SPI
+mode.
+
+Required properties:
+- compatible:  "adafruit,yx240qv29", "ilitek,ili9341"
+- dc-gpios:D/C pin
+- reset-gpios: Reset pin
+
+The node for this driver must be a child node of a SPI controller, hence
+all mandatory properties described in ../spi/spi-bus.txt must be specified.
+
+Optional properties:
+- rotation:panel rotation in degrees counter clockwise (0,90,180,270)
+- backlight:   phandle of the backlight device attached to the panel
+
+Example:
+   display@0{
+   compatible = "adafruit,yx240qv29", "ilitek,ili9341";
+   reg = <0>;
+   spi-max-frequency = <3200>;
+   dc-gpios = < 9 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 8 GPIO_ACTIVE_HIGH>;
+   rotation = <270>;
+   backlight = <>;
+   };
-- 
2.17.0

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

Re: [PATCH v2 3/4] dt-bindings: new binding for Ilitek ILI9341 display panels

[David Lechner]

On 05/25/2018 02:36 PM, David Lechner wrote:

This adds a new binding for Ilitek ILI9341 display panels. It includes
a compatible string for one display (more can be added in the future).

The vendor prefix "noname" is used because the vendor is not known.


Looks like I forgot to update "noname" to "adafruit" in the commit message.
Patch is as intended though.


The YX240QV29-T panel[1] is found, for example, in an Adafruit breakout
board[2] and in Mindsensors' PiStorms[3].

[1]: 
https://cdn-learn.adafruit.com/assets/assets/000/046/879/original/SPEC-YX240QV29-T_Rev.A__1_.pdf
[2]: https://www.adafruit.com/product/2478
[3]: 
http://www.mindsensors.com/stem-with-robotics/13-pistorms-v2-base-kit-raspberry-pi-brain-for-lego-robot

Signed-off-by: David Lechner <da...@lechnology.com>
---
  .../bindings/display/ilitek,ili9341.txt   | 27 +++
  1 file changed, 27 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/ilitek,ili9341.txt

diff --git a/Documentation/devicetree/bindings/display/ilitek,ili9341.txt 
b/Documentation/devicetree/bindings/display/ilitek,ili9341.txt
new file mode 100644
index ..169b32e4ee4e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ilitek,ili9341.txt
@@ -0,0 +1,27 @@
+Ilitek ILI9341 display panels
+
+This binding is for display panels using an Ilitek ILI9341 controller in SPI
+mode.
+
+Required properties:
+- compatible:  "adafruit,yx240qv29", "ilitek,ili9341"
+- dc-gpios:D/C pin
+- reset-gpios: Reset pin
+
+The node for this driver must be a child node of a SPI controller, hence
+all mandatory properties described in ../spi/spi-bus.txt must be specified.
+
+Optional properties:
+- rotation:panel rotation in degrees counter clockwise (0,90,180,270)
+- backlight:   phandle of the backlight device attached to the panel
+
+Example:
+   display@0{
+   compatible = "adafruit,yx240qv29", "ilitek,ili9341";
+   reg = <0>;
+   spi-max-frequency = <3200>;
+   dc-gpios = < 9 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 8 GPIO_ACTIVE_HIGH>;
+   rotation = <270>;
+   backlight = <>;
+   };



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

Re: [PATCH v2 0/4] drm/tinydrm: new dirver for ILI9341 displays

[David Lechner]

On 6/3/18 5:00 PM, Noralf Trønnes wrote:


Den 25.05.2018 21.36, skrev David Lechner:
This series adds a new tinydrm driver for the Ilitek ILI9341 
controller and

a 2.4" display panel that uses this controller.


David, do you have commit rights now?


No. Opened a bug a while back to request access, but I guess the
right person didn't see it.

https://bugs.freedesktop.org/show_bug.cgi?id=105166



Noralf.


A few things to note here:
* The datasheet for this display[1] doesn't have a vendor mentioned on it
   anywhere, so I have used "adafruit" as the vendor prefix. If 
someone has a

   better suggestion, please speak up.
* The MAINTAINERS patch for ili9225 is included so we don't end up 
with a merge

   conflict later on.

v2 changes:
* change vendor prefix from "noname" to "adafruit"
* new patch for "adafruit" vendor prefix
* minor style changes
* drop regulator from driver (instead of adding to DT bindings)

[1]: 
https://cdn-learn.adafruit.com/assets/assets/000/046/879/original/SPEC-YX240QV29-T_Rev.A__1_.pdf 




David Lechner (4):
   MAINTAINERS: fix path to ilitek,ili9225 device tree bindings
   dt-bindings: Add vendor prefix for Adafruit
   dt-bindings: new binding for Ilitek ILI9341 display panels
   drm/tinydrm: new driver for ILI9341 display panels

  .../bindings/display/ilitek,ili9341.txt   |  27 ++
  .../devicetree/bindings/vendor-prefixes.txt   |   1 +
  MAINTAINERS   |   8 +-
  drivers/gpu/drm/tinydrm/Kconfig   |  10 +
  drivers/gpu/drm/tinydrm/Makefile  |   1 +
  drivers/gpu/drm/tinydrm/ili9341.c | 233 ++
  6 files changed, 279 insertions(+), 1 deletion(-)
  create mode 100644 
Documentation/devicetree/bindings/display/ilitek,ili9341.txt

  create mode 100644 drivers/gpu/drm/tinydrm/ili9341.c




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

Re: [PATCH v2 0/4] drm/tinydrm: new dirver for ILI9341 displays

[David Lechner]

On 06/20/2018 04:07 AM, Daniel Vetter wrote:


I acked and forwarded the account request, sorry for the delay. Next
time around, poking maintainers on irc helps if this stuff is stuck.
-Daniel


The account was supposedly setup, but I am not able to use it for some
reason. Are there any particular nicks I should ping on IRC?

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

Re: [PATCH v2 0/4] drm/tinydrm: new dirver for ILI9341 displays

[David Lechner]

On 06/27/2018 01:58 AM, Daniel Vetter wrote:

On Tue, Jun 26, 2018 at 8:16 PM, David Lechner  wrote:

On 06/20/2018 04:07 AM, Daniel Vetter wrote:


I acked and forwarded the account request, sorry for the delay. Next
time around, poking maintainers on irc helps if this stuff is stuck.
-Daniel



The account was supposedly setup, but I am not able to use it for some
reason. Are there any particular nicks I should ping on IRC?


#freedesktop on freenode is the channel where fd.o admins hang out.


Got that sorted out and pushed this series.

Hope I didn't break anything. :-o
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 9/9] drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs()

[David Lechner]

On 07/02/2018 08:54 AM, Noralf Trønnes wrote:

Remove drm_fb_cma_fbdev_init_with_funcs(), its only user tinydrm has
moved to drm_fbdev_generic_setup().

Cc: Laurent Pinchart 
Signed-off-by: Noralf Trønnes 
---


Reviewed-by: David Lechner 


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

Re: [PATCH v4 8/9] drm/tinydrm: Use drm_fbdev_generic_setup()

[David Lechner]

On 07/02/2018 08:54 AM, Noralf Trønnes wrote:

Make full use of the generic fbdev client.

Cc: David Lechner 
Signed-off-by: Noralf Trønnes 
---


Reviewed-by: David Lechner 


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

Re: [PATCH 5/5] drm/tinydrm: Embed the mode in tinydrm_connector

[David Lechner]

On 01/05/2018 10:56 AM, Noralf Trønnes wrote:

Embed the mode in tinydrm_connector instead of doing an devm_ allocation.
Remove unnecessary use of ret variable at the end of
tinydrm_display_pipe_init().

Signed-off-by: Noralf Trønnes 
---
  drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c | 34 +++--
  1 file changed, 13 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
index f41fc506ff87..dadd26d53216 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
@@ -15,7 +15,7 @@
  
  struct tinydrm_connector {

struct drm_connector base;
-   const struct drm_display_mode *mode;
+   struct drm_display_mode mode;
  };
  
  static inline struct tinydrm_connector *

@@ -29,7 +29,7 @@ static int tinydrm_connector_get_modes(struct drm_connector 
*connector)
struct tinydrm_connector *tconn = to_tinydrm_connector(connector);
struct drm_display_mode *mode;
  
-	mode = drm_mode_duplicate(connector->dev, tconn->mode);

+   mode = drm_mode_duplicate(connector->dev, >mode);
if (!mode) {
DRM_ERROR("Failed to duplicate mode\n");
return 0;
@@ -92,7 +92,7 @@ tinydrm_connector_create(struct drm_device *drm,
if (!tconn)
return ERR_PTR(-ENOMEM);
  
-	tconn->mode = mode;

+   tconn->mode = *mode;


I see there is a special drm_mode_copy() function, so I am wondering if this
is safe.


connector = >base;
  
  	drm_connector_helper_add(connector, _connector_hfuncs);

@@ -199,35 +199,27 @@ tinydrm_display_pipe_init(struct tinydrm_device *tdev,
  unsigned int rotation)
  {
struct drm_device *drm = tdev->drm;
-   struct drm_display_mode *mode_copy;
+   struct drm_display_mode mode_copy;
struct drm_connector *connector;
int ret;
  
-	mode_copy = devm_kmalloc(drm->dev, sizeof(*mode_copy), GFP_KERNEL);

-   if (!mode_copy)
-   return -ENOMEM;
-
-   *mode_copy = *mode;
-   ret = tinydrm_rotate_mode(mode_copy, rotation);
+   mode_copy = *mode;


Same here.


+   ret = tinydrm_rotate_mode(_copy, rotation);
if (ret) {
DRM_ERROR("Illegal rotation value %u\n", rotation);
return -EINVAL;
}
  
-	drm->mode_config.min_width = mode_copy->hdisplay;

-   drm->mode_config.max_width = mode_copy->hdisplay;
-   drm->mode_config.min_height = mode_copy->vdisplay;
-   drm->mode_config.max_height = mode_copy->vdisplay;
+   drm->mode_config.min_width = mode_copy.hdisplay;
+   drm->mode_config.max_width = mode_copy.hdisplay;
+   drm->mode_config.min_height = mode_copy.vdisplay;
+   drm->mode_config.max_height = mode_copy.vdisplay;
  
-	connector = tinydrm_connector_create(drm, mode_copy, connector_type);

+   connector = tinydrm_connector_create(drm, _copy, connector_type);
if (IS_ERR(connector))
return PTR_ERR(connector);
  
-	ret = drm_simple_display_pipe_init(drm, >pipe, funcs, formats,

-  format_count, NULL, connector);
-   if (ret)
-   return ret;
-
-   return 0;
+   return drm_simple_display_pipe_init(drm, >pipe, funcs, formats,
+   format_count, NULL, connector);
  }
  EXPORT_SYMBOL(tinydrm_display_pipe_init);



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

Re: [PATCH 3/5] drm/tinydrm/mi0283qt: Clarify error message

[David Lechner]

On 01/05/2018 10:55 AM, Noralf Trønnes wrote:

Make it clear that the printed value is the error and not the command
value itself.

Signed-off-by: Noralf Trønnes <nor...@tronnes.org>
---
  drivers/gpu/drm/tinydrm/mi0283qt.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index c69a4d958f24..5994140f1e1e 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -58,7 +58,7 @@ static int mi0283qt_init(struct mipi_dbi *mipi)
  
  	ret = regulator_enable(mipi->regulator);

if (ret) {
-   DRM_DEV_ERROR(dev, "Failed to enable regulator %d\n", ret);
+   DRM_DEV_ERROR(dev, "Failed to enable regulator: %d\n", ret);


It is more common to use parenthesis around the error value, so that would be
more clear to me.

 +  DRM_DEV_ERROR(dev, "Failed to enable regulator (%d)\n", ret);


return ret;
}
  
@@ -69,7 +69,7 @@ static int mi0283qt_init(struct mipi_dbi *mipi)

mipi_dbi_hw_reset(mipi);
ret = mipi_dbi_command(mipi, MIPI_DCS_SOFT_RESET);
if (ret) {
-   DRM_DEV_ERROR(dev, "Error sending command %d\n", ret);
+   DRM_DEV_ERROR(dev, "Error sending command: %d\n", ret);


ditto


regulator_disable(mipi->regulator);
    return ret;
}



With that change:

Reviewed-by: David Lechner <da...@lechnology.com>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/5] drm/tinydrm/mi0283qt: Remove ili9341.h

[David Lechner]

On 01/05/2018 10:55 AM, Noralf Trønnes wrote:

No need for a public header file for the command macros.
Just include the necessary ones in the driver.

Also use the MIPI_DCS_PIXEL_FMT_16BIT macro.

Signed-off-by: Noralf Trønnes <nor...@tronnes.org>
---


Reviewed-by: David Lechner <da...@lechnology.com>

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

Re: [PATCH 4/5] drm/tinydrm/mi0283qt: Let the display pipe handle power

[David Lechner]

On 01/05/2018 10:55 AM, Noralf Trønnes wrote:

It's better to leave power handling and controller init to the
modesetting machinery using the simple pipe .enable and .disable
callbacks.

Signed-off-by: Noralf Trønnes 
---
  drivers/gpu/drm/tinydrm/mi0283qt.c | 51 --
  drivers/gpu/drm/tinydrm/mipi-dbi.c | 14 ++-
  2 files changed, 19 insertions(+), 46 deletions(-)





@@ -316,8 +315,8 @@ static void mipi_dbi_blank(struct mipi_dbi *mipi)
   * mipi_dbi_pipe_disable - MIPI DBI pipe disable helper
   * @pipe: Display pipe
   *
- * This function disables backlight if present or if not the
- * display memory is blanked. Drivers can use this as their
+ * This function disables backlight if present, if not the display memory is
+ * blanked. The regulator is disabled if in use. Drivers can use this as their
   * _simple_display_pipe_funcs->disable callback.
   */
  void mipi_dbi_pipe_disable(struct drm_simple_display_pipe *pipe)
@@ -333,6 +332,9 @@ void mipi_dbi_pipe_disable(struct drm_simple_display_pipe 
*pipe)
tinydrm_disable_backlight(mipi->backlight);
else
mipi_dbi_blank(mipi);
+
+   if (mipi->regulator)
+   regulator_disable(mipi->regulator);
  }
  EXPORT_SYMBOL(mipi_dbi_pipe_disable);
  


If a display physically has a backlight, but it is not controllable (i.e.
mipi->backlight == NULL) and you disable the regulator, would that not cause
the display to be all white instead of blanked?

Also, even if this is OK, it seems like you should call regulator_enable()
in mipi_dbi_pipe_enable() to keep things balanced in the helper functions.

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

Re: [PATCH 1/5] drm/tinydrm/mi0283qt: Use common include order

[David Lechner]

On 01/05/2018 10:55 AM, Noralf Trønnes wrote:

Include linux headers before drm headers as it's commonly done.

Signed-off-by: Noralf Trønnes <nor...@tronnes.org>
---
  drivers/gpu/drm/tinydrm/mi0283qt.c | 11 ++-
  1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 674d407640be..45f02b6052b1 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -9,17 +9,18 @@
   * (at your option) any later version.
   */
  
-#include 

-#include 
-#include 
-#include 
-#include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
  #include 
  
  static int mi0283qt_init(struct mipi_dbi *mipi)




Reviewed-by: David Lechner <da...@lechnology.com>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/5] drm/tinydrm: Embed the mode in tinydrm_connector

[David Lechner]

On 01/06/2018 06:49 AM, Noralf Trønnes wrote:


Den 05.01.2018 20.14, skrev David Lechner:

On 01/05/2018 10:56 AM, Noralf Trønnes wrote:

Embed the mode in tinydrm_connector instead of doing an devm_ allocation.
Remove unnecessary use of ret variable at the end of
tinydrm_display_pipe_init().

Signed-off-by: Noralf Trønnes <nor...@tronnes.org>
---
  drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c | 34 +++--
  1 file changed, 13 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
index f41fc506ff87..dadd26d53216 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
@@ -15,7 +15,7 @@
    struct tinydrm_connector {
  struct drm_connector base;
-    const struct drm_display_mode *mode;
+    struct drm_display_mode mode;
  };
    static inline struct tinydrm_connector *
@@ -29,7 +29,7 @@ static int tinydrm_connector_get_modes(struct drm_connector 
*connector)
  struct tinydrm_connector *tconn = to_tinydrm_connector(connector);
  struct drm_display_mode *mode;
  -    mode = drm_mode_duplicate(connector->dev, tconn->mode);
+    mode = drm_mode_duplicate(connector->dev, >mode);
  if (!mode) {
  DRM_ERROR("Failed to duplicate mode\n");
  return 0;
@@ -92,7 +92,7 @@ tinydrm_connector_create(struct drm_device *drm,
  if (!tconn)
  return ERR_PTR(-ENOMEM);
  -    tconn->mode = mode;
+    tconn->mode = *mode;


I see there is a special drm_mode_copy() function, so I am wondering if this
is safe.



It is safe, the underlying drm_mode_object isn't initialized/registered.
So to me an assignment like this makes it clear that it is so, but Laurent
also asked about this, so maybe I'm the odd one here.
I'll switch to drm_mode_copy().



I think a comment to this effect would be enough.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/5] drm/tinydrm/mi0283qt: Let the display pipe handle power

[David Lechner]

On 01/06/2018 06:45 AM, Noralf Trønnes wrote:


Den 05.01.2018 19.59, skrev David Lechner:

On 01/05/2018 10:55 AM, Noralf Trønnes wrote:

It's better to leave power handling and controller init to the
modesetting machinery using the simple pipe .enable and .disable
callbacks.

Signed-off-by: Noralf Trønnes <nor...@tronnes.org>
---
  drivers/gpu/drm/tinydrm/mi0283qt.c | 51 --
  drivers/gpu/drm/tinydrm/mipi-dbi.c | 14 ++-
  2 files changed, 19 insertions(+), 46 deletions(-)





@@ -316,8 +315,8 @@ static void mipi_dbi_blank(struct mipi_dbi *mipi)
   * mipi_dbi_pipe_disable - MIPI DBI pipe disable helper
   * @pipe: Display pipe
   *
- * This function disables backlight if present or if not the
- * display memory is blanked. Drivers can use this as their
+ * This function disables backlight if present, if not the display memory is
+ * blanked. The regulator is disabled if in use. Drivers can use this as their
   * _simple_display_pipe_funcs->disable callback.
   */
  void mipi_dbi_pipe_disable(struct drm_simple_display_pipe *pipe)
@@ -333,6 +332,9 @@ void mipi_dbi_pipe_disable(struct drm_simple_display_pipe 
*pipe)
  tinydrm_disable_backlight(mipi->backlight);
  else
  mipi_dbi_blank(mipi);
+
+    if (mipi->regulator)
+    regulator_disable(mipi->regulator);
  }
  EXPORT_SYMBOL(mipi_dbi_pipe_disable);


If a display physically has a backlight, but it is not controllable (i.e.
mipi->backlight == NULL) and you disable the regulator, would that not cause
the display to be all white instead of blanked?



Yes, if the regulator doesn't control the backlight. But on these simple
displays I assume that a regulator would control the whole display
including the backlight. If we get a display with a separate backlight
regulator, I think it's better to treat that as the exception rather than
the other way around.


Makes sense. All of the displays I have that have a controllable backlight don't
have a regulator for the display itself, so they won't be affected anyway.




Also, even if this is OK, it seems like you should call regulator_enable()
in mipi_dbi_pipe_enable() to keep things balanced in the helper functions.



Yes, I wasn't entirely happy with this. The regulator has to be enabled
before the controller is initialized, so it can't happen in this _enable helper.
I thought about having mipi_dbi_pipe_enable_begin/end functions, but I'm
not sure I like that either. I prefer something more descriptive.

Maybe we should drop the pipe enable helper, since it's not very likely
that anyone can use it directly as an .enable function.

What do you think about this approach:


It looks OK to me. Although I am wondering about the conditional reset. If the
display is already on, how do we know it is configured correctly?



/**
  * mipi_dbi_poweron_conditional_reset - MIPI DBI poweron and conditional reset
  * @mipi: MIPI DBI structure
  *
  * This function enables the regulator if used and if the display is off, it
  * does a hardware and software reset. If mipi_dbi_display_is_on() determines
  * that the display is on, no reset is performed.
  *
  * Returns:
  * Zero if the controller was reset, 1 if the display was already on, or a
  * negative error code.
  */
int mipi_dbi_poweron_conditional_reset(struct mipi_dbi *mipi)
{
     struct device *dev = mipi->tinydrm.drm->dev;
     int ret;

     if (mipi->regulator) {
         ret = regulator_enable(mipi->regulator);
         if (ret) {
             DRM_DEV_ERROR(dev, "Failed to enable regulator (%d)\n", ret);
             return ret;
         }
     }

     if (mipi_dbi_display_is_on(mipi))
         return 1;

     mipi_dbi_hw_reset(mipi);
     ret = mipi_dbi_command(mipi, MIPI_DCS_SOFT_RESET);
     if (ret) {
         DRM_DEV_ERROR(dev, "Failed to send reset command (%d)\n", ret);
         regulator_disable(mipi->regulator);
         return ret;
     }

     return 0;
}
EXPORT_SYMBOL(mipi_dbi_poweron_conditional_reset);

/**
  * mipi_dbi_enable_flush - MIPI DBI enable helper
  * @mipi: MIPI DBI structure
  *
  * This function sets _dbi->enabled, flushes the whole framebuffer and
  * enables the backlight. Drivers can use this in their
  * _simple_display_pipe_funcs->enable callback.
  */
void mipi_dbi_enable_flush(struct mipi_dbi *mipi)
{
     struct drm_framebuffer *fb = mipi->tdev.pipe->plane.fb;

     mipi->enabled = true;
     if (fb)
         fb->funcs->dirty(fb, NULL, 0, 0, NULL, 0);

     tinydrm_enable_backlight(mipi->backlight);
}
EXPORT_SYMBOL(mipi_dbi_enable_flush);


static void mi0283qt_enable(struct drm_simple_display_pipe *pipe,
                 struct drm_crtc_state *crtc_state)
{
     struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
     struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
     struct device *dev = tdev->drm->dev;

     ret = mipi_dbi_poweron_conditional_rese

Re: [PATCH v2 4/6] drm/tinydrm/mipi-dbi: Add poweron-reset functions

[David Lechner]

On 01/07/2018 11:44 AM, Noralf Trønnes wrote:

Split out common poweron-reset functionality.

Signed-off-by: Noralf Trønnes 
---
  drivers/gpu/drm/tinydrm/mi0283qt.c | 20 ++--
  drivers/gpu/drm/tinydrm/mipi-dbi.c | 63 ++
  drivers/gpu/drm/tinydrm/st7586.c   |  9 ++
  drivers/gpu/drm/tinydrm/st7735r.c  |  8 ++---
  include/drm/tinydrm/mipi-dbi.h |  2 ++
  5 files changed, 73 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index c69a4d958f24..2a78bcd35045 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -49,31 +49,17 @@
  
  static int mi0283qt_init(struct mipi_dbi *mipi)

  {
-   struct tinydrm_device *tdev = >tinydrm;
-   struct device *dev = tdev->drm->dev;
u8 addr_mode;
int ret;
  
  	DRM_DEBUG_KMS("\n");
  
-	ret = regulator_enable(mipi->regulator);

-   if (ret) {
-   DRM_DEV_ERROR(dev, "Failed to enable regulator %d\n", ret);
+   ret = mipi_dbi_poweron_conditional_reset(mipi);
+   if (ret < 0)
return ret;
-   }
-
-   /* Avoid flicker by skipping setup if the bootloader has done it */
-   if (mipi_dbi_display_is_on(mipi))
+   if (ret > 0)
return 0;


If I am reading the patch right, it looks like there are two

if (ret > 0)
return 0;

in a row with nothing in between when this is applied.

  
-	mipi_dbi_hw_reset(mipi);

-   ret = mipi_dbi_command(mipi, MIPI_DCS_SOFT_RESET);
-   if (ret) {
-   DRM_DEV_ERROR(dev, "Error sending command %d\n", ret);
-   regulator_disable(mipi->regulator);
-   return ret;
-   }
-
msleep(20);
  
  	mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_OFF);

diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index ecc5c81a93ac..eea6803ff223 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -463,6 +463,7 @@ bool mipi_dbi_display_is_on(struct mipi_dbi *mipi)
  
  	val &= ~DCS_POWER_MODE_RESERVED_MASK;
  
+	/* The poweron/reset value is 08h DCS_POWER_MODE_DISPLAY_NORMAL_MODE */

if (val != (DCS_POWER_MODE_DISPLAY |
DCS_POWER_MODE_DISPLAY_NORMAL_MODE | DCS_POWER_MODE_SLEEP_MODE))
return false;
@@ -473,6 +474,68 @@ bool mipi_dbi_display_is_on(struct mipi_dbi *mipi)
  }
  EXPORT_SYMBOL(mipi_dbi_display_is_on);
  
+static int mipi_dbi_por_conditional(struct mipi_dbi *mipi, bool cond)


I know it is long, but it would be nice to spell out poweron_reset here
instead of "por".


+{
+   struct device *dev = mipi->tinydrm.drm->dev;
+   int ret;
+
+   if (mipi->regulator) {
+   ret = regulator_enable(mipi->regulator);
+   if (ret) {
+   DRM_DEV_ERROR(dev, "Failed to enable regulator (%d)\n", 
ret);
+   return ret;
+   }
+   }
+
+   if (cond && mipi_dbi_display_is_on(mipi))
+   return 1;
+
+   mipi_dbi_hw_reset(mipi);
+   ret = mipi_dbi_command(mipi, MIPI_DCS_SOFT_RESET);


It seems unnecessary to do a soft reset after a hard reset, but I suppose some 
displays
don't have a hard reset and the extra soft reset shouldn't hurt anything.


+   if (ret) {
+   DRM_DEV_ERROR(dev, "Failed to send reset command (%d)\n", ret);
+   if (mipi->regulator)
+   regulator_disable(mipi->regulator);
+   return ret;
+   }
+
+   return 0;
+}
+
+/**
+ * mipi_dbi_poweron_reset - MIPI DBI poweron and reset
+ * @mipi: MIPI DBI structure
+ *
+ * This function enables the regulator if used and does a hardware and software
+ * reset.
+ *
+ * Returns:
+ * Zero on success, or a negative error code.
+ */
+int mipi_dbi_poweron_reset(struct mipi_dbi *mipi)
+{
+   return mipi_dbi_por_conditional(mipi, false);
+}
+EXPORT_SYMBOL(mipi_dbi_poweron_reset);
+
+/**
+ * mipi_dbi_poweron_conditional_reset - MIPI DBI poweron and conditional reset
+ * @mipi: MIPI DBI structure
+ *
+ * This function enables the regulator if used and if the display is off, it
+ * does a hardware and software reset. If mipi_dbi_display_is_on() determines
+ * that the display is on, no reset is performed.
+ *
+ * Returns:
+ * Zero if the controller was reset, 1 if the display was already on, or a
+ * negative error code.
+ */
+int mipi_dbi_poweron_conditional_reset(struct mipi_dbi *mipi)
+{
+   return mipi_dbi_por_conditional(mipi, true);
+}
+EXPORT_SYMBOL(mipi_dbi_poweron_conditional_reset);
+
  #if IS_ENABLED(CONFIG_SPI)
  
  /**

diff --git a/drivers/gpu/drm/tinydrm/st7586.c b/drivers/gpu/drm/tinydrm/st7586.c
index 9fd4423c8e70..a6396ef9cc4a 100644
--- a/drivers/gpu/drm/tinydrm/st7586.c
+++ b/drivers/gpu/drm/tinydrm/st7586.c
@@ -179,19 +179,16 @@ static void st7586_pipe_enable(struct 

Re: [PATCH v2 4/6] drm/tinydrm/mipi-dbi: Add poweron-reset functions

[David Lechner]

On 01/09/2018 09:01 AM, Noralf Trønnes wrote:


Den 09.01.2018 02.38, skrev David Lechner:

On 01/07/2018 11:44 AM, Noralf Trønnes wrote:

Split out common poweron-reset functionality.

Signed-off-by: Noralf Trønnes <nor...@tronnes.org>
---
  drivers/gpu/drm/tinydrm/mi0283qt.c | 20 ++--
  drivers/gpu/drm/tinydrm/mipi-dbi.c | 63 ++
  drivers/gpu/drm/tinydrm/st7586.c   |  9 ++
  drivers/gpu/drm/tinydrm/st7735r.c  |  8 ++---
  include/drm/tinydrm/mipi-dbi.h |  2 ++
  5 files changed, 73 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index c69a4d958f24..2a78bcd35045 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -49,31 +49,17 @@
    static int mi0283qt_init(struct mipi_dbi *mipi)
  {
-    struct tinydrm_device *tdev = >tinydrm;
-    struct device *dev = tdev->drm->dev;
  u8 addr_mode;
  int ret;
    DRM_DEBUG_KMS("\n");
  -    ret = regulator_enable(mipi->regulator);
-    if (ret) {
-    DRM_DEV_ERROR(dev, "Failed to enable regulator %d\n", ret);
+    ret = mipi_dbi_poweron_conditional_reset(mipi);
+    if (ret < 0)
  return ret;
-    }
-
-    /* Avoid flicker by skipping setup if the bootloader has done it */
-    if (mipi_dbi_display_is_on(mipi))
+    if (ret > 0)
  return 0;


If I am reading the patch right, it looks like there are two

if (ret > 0)
   return 0;

in a row with nothing in between when this is applied.


  -    mipi_dbi_hw_reset(mipi);
-    ret = mipi_dbi_command(mipi, MIPI_DCS_SOFT_RESET);
-    if (ret) {
-    DRM_DEV_ERROR(dev, "Error sending command %d\n", ret);
-    regulator_disable(mipi->regulator);
-    return ret;
-    }
-
  msleep(20);
    mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_OFF);
diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index ecc5c81a93ac..eea6803ff223 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -463,6 +463,7 @@ bool mipi_dbi_display_is_on(struct mipi_dbi *mipi)
    val &= ~DCS_POWER_MODE_RESERVED_MASK;
  +    /* The poweron/reset value is 08h DCS_POWER_MODE_DISPLAY_NORMAL_MODE */
  if (val != (DCS_POWER_MODE_DISPLAY |
  DCS_POWER_MODE_DISPLAY_NORMAL_MODE | DCS_POWER_MODE_SLEEP_MODE))
  return false;
@@ -473,6 +474,68 @@ bool mipi_dbi_display_is_on(struct mipi_dbi *mipi)
  }
  EXPORT_SYMBOL(mipi_dbi_display_is_on);
  +static int mipi_dbi_por_conditional(struct mipi_dbi *mipi, bool cond)


I know it is long, but it would be nice to spell out poweron_reset here
instead of "por".


+{
+    struct device *dev = mipi->tinydrm.drm->dev;
+    int ret;
+
+    if (mipi->regulator) {
+    ret = regulator_enable(mipi->regulator);
+    if (ret) {
+    DRM_DEV_ERROR(dev, "Failed to enable regulator (%d)\n", ret);
+    return ret;
+    }
+    }
+
+    if (cond && mipi_dbi_display_is_on(mipi))
+    return 1;
+
+    mipi_dbi_hw_reset(mipi);
+    ret = mipi_dbi_command(mipi, MIPI_DCS_SOFT_RESET);


It seems unnecessary to do a soft reset after a hard reset, but I suppose some 
displays
don't have a hard reset and the extra soft reset shouldn't hurt anything.



Both ILI9341 and ST7735R (not ST7586S) lists soft reset as part of the
Power Flow Chart, but it's not explicit about it being required or not:

Power on sequence
HW reset
SW reset
State is now Sleep in

I looked in the MIPI DBI spec and there's nothing about requiring both
hw _and_ soft reset. But I have seen hard and soft reset in many panel
init's, so I think we keep this as the default. It has a 5ms penalty.
I could shave that off in mipi_dbi_hw_reset(). It keeps reset low for
20ms, but the spec says it just has to be longer than 9us with noise
spikes less than 20ns wide:

-    msleep(20);
+    usleep_range(20, 1000);



Sounds good to me.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel