From: Igor Grinberg <grinberg@compulab.co.il>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Archit Taneja <archit@ti.com>,
linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org,
Tony Lindgren <tony@atomide.com>
Subject: Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
Date: Thu, 14 Feb 2013 09:43:15 +0000 [thread overview]
Message-ID: <511CB1B3.80605@compulab.co.il> (raw)
In-Reply-To: <511CA9B3.70401@ti.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/14/13 11:09, Tomi Valkeinen wrote:
> On 2013-02-14 10:37, Igor Grinberg wrote:
>> On 02/14/13 09:09, Tomi Valkeinen wrote:
>>> On 2013-02-14 08:56, Igor Grinberg wrote:
>>>> On 02/13/13 17:59, Tomi Valkeinen wrote:
>>
>>>>> Okay, so I just realized there's an spi backlight driver used here, and
>>>>> that backlight driver is actually handling the SPI transactions with the
>>>>> panel, instead of the panel driver. So this looks quite messed up.
>>>>
>>>> Yep, it always was.
>>>> The whole DSS specific panel handling inside the
>>>> drivers/video/omap2/displays is a mess.
>>
>>> Well, that's not mess itself, it's just omap specific panel framework.
>>> But dividing single device handling into two separate places is a mess.
>>
>> Yes, you are right it is not the mess, but it prevents the panel to
>> be used on other systems and that is BAD.
>> At the very least, drivers/video/backlight is a generic place that can be
>> used not just on OMAP.
>
> True, it's generic, but does it work reliably? The panel hardware is now
> partly handled in the backlight driver, and partly in the omap's panel
> driver (and wherever on other platforms).
It works reliably on other platforms, but not on OMAP - because
we need to cope with the OMAP specific framework...
>
> At least currently there's a dependency between the two, as the LCD_EN
> gpio is handled by the panel driver, which affects the functioning of
> the backlight driver. Is it ensured that the panel driver does not
> disable the panel when the backlight driver does spi transactions?
>
> That's what I meant with the mess, it's difficult to make it work
> reliably. I know that for some panels such a two-driver approach would
> not work at all. Although I guess it's working well enough for you for
> this panel.
Yep, that is correct - this is the mess.
>
> Thinking about it, if you do move the gpio handling to the backlight
> driver, the panel driver will only handle the DPI video stream. Then it
> should not have any effect on the SPI side (presuming the panel doesn't
> use the pixel clock as func clock), although there's probably still
> possibility for display artifacts on enable and disable, if the order of
> operations goes the wrong way.
Yep, again, that is correct.
>
>> And since the toppoly was and is used on other systems, why the hell
>> should anyone duplicate the driver just to please the OMAP specific
>> panel framework? The real problem is that this framework should not be
>
> Not to please. To make it reliable.
Well, there are multiple ways to make it reliable.
And I don't think that the best would be: make it OMAP specific.
>
>> OMAP specific...
>> Of course I'm aware of the fact that currently there is no generic
>> panel framework, but forging something OMAP specific which is obviously
>> used on most of the other architectures/platforms (and I mean
>> panel<->controller relations), is not a good way to go.
>
> Well, if duplicating the code gives us reliable drivers, versus
> unreliable without duplicating, then... I don't see it as that bad.
Hmmm... I don't think this fits the mainline (upstream) philosophy.
This can be also extrapolated into: let's make our own Linux ARM fork
so it will be more reliable...
This is the way how vendor specific kernel releases work.
>
>> Although, I'm also aware of the fact that most things are done this way:
>> do several specific drivers/frameworks, find the common stuff, and extract
>> it into a core driver/framework. So I don't want to blame anyone - that's
>> just the way how we do things, right?
>
> If it was easy, somebody would've done it.
In fact this is done all the time on multiple drivers and frameworks.
Also, I don't say this is easy, but I also don't think this too hard.
It is also a function of resources (time/will/experience/etc.).
>
>>>>> For a quick solution, can we just set the LCD_EN at boot time (with the
>>>>> msleep), and not touch it after that?
>>>>
>>>> That would be sensible for now, so this series can be merged.
>>>> As a more appropriate (and long term) solution,
>>>> I plan on moving the panel reset pin handling to the spi backlight
>>>> driver itself.
>>
>>> Well, if you must. But I suggest moving the whole panel handling into a
>>> (omap specific) panel driver, as it's done for other panels. That way
>>> you'll have a proper panel driver for it, for omap, and when CDF comes,
>>> you'll get a platform independent panel driver for it.
>>
>> You can't just move generic architecture/platform independent stuff
>> into OMAP specific framework... Just think about this... It's insane.
>
> As I said, reliable vs unreliable. That's not insane.
>
> But again, if you can handle this particular panel reliably with the
> two-driver approach, I'm fine with it.
Again, it works reliably on other platforms,
why would OMAP be an exception?
>
>> In addition, AFAIR, the reset pin is the property of the toppoly panel
>> hardware, so that is why I think, we should let the toppoly driver
>> (currently spi backlight, later hopefully CDF) handle it correctly
>> along with the spi sequences.
>
> Yes, that sounds ok.
>
> Tomi
>
- --
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRHLGzAAoJEBDE8YO64EfaOJMP/AtR9IkN+eWwdbt0R1Vu9vKH
mFgSCENqErAjYi3zM0YScj+E2zSby4rfXCY14Goh46DBCBXjRWYms6P/nZgGSLYT
lIup5YljWxWJxM0nvrykok872Atx+TSJukx3nD5foWieu4tNRRvhqN7+ckBO7R4D
J1D5uy3wH8Ea3SZ/foPrzewTeajnOeZxzhprfodLdmKIuqxInVE0KrWqrcefspNI
TvWAjLCHtoM4LDCZRaiHs3mN03QMdcJc1BfWeJe1eVx6YXSBqNTTG6mSgUegQyOG
PnC1T3kzS5Vuhmk9NfUmL19LInAljPVDoQomUqG6N140M6jol4ru+A5yE/NZ/tSl
j/8vz5pE8JXp0ueQt1X1vkAGL+Lgzbyrf38xQTxnjSLggO3OFHOv6AzlY453Lfem
gz6Xpjq+2Kcqxghfndd4yXnOjdlyWDN6dvYBthBBixmt34c6nNtdoXmakAXyw8wW
qSyT3sO6WgE53ROZRh9W2FCiLXdJ1rHYMBRRY4nbKNhOhtC/vSF4UVsFBUuAaqul
a6QToMggpugY8n3lm/SZ6LFWJDaHjnkUAVXxq3/GiclJSFwBnHqsOT1bfjsF5OfC
YnaldNBbH0WvmFN89Ds/inW1MLcFc/yWirB0Utj7ysb5AL4vH4QLs1dokzjxnTyK
WJmOMyQi7Jk+ocUSBgu2
=G6lL
-----END PGP SIGNATURE-----
WARNING: multiple messages have this Message-ID (diff)
From: Igor Grinberg <grinberg@compulab.co.il>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Archit Taneja <archit@ti.com>,
linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org,
Tony Lindgren <tony@atomide.com>
Subject: Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
Date: Thu, 14 Feb 2013 11:43:15 +0200 [thread overview]
Message-ID: <511CB1B3.80605@compulab.co.il> (raw)
In-Reply-To: <511CA9B3.70401@ti.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/14/13 11:09, Tomi Valkeinen wrote:
> On 2013-02-14 10:37, Igor Grinberg wrote:
>> On 02/14/13 09:09, Tomi Valkeinen wrote:
>>> On 2013-02-14 08:56, Igor Grinberg wrote:
>>>> On 02/13/13 17:59, Tomi Valkeinen wrote:
>>
>>>>> Okay, so I just realized there's an spi backlight driver used here, and
>>>>> that backlight driver is actually handling the SPI transactions with the
>>>>> panel, instead of the panel driver. So this looks quite messed up.
>>>>
>>>> Yep, it always was.
>>>> The whole DSS specific panel handling inside the
>>>> drivers/video/omap2/displays is a mess.
>>
>>> Well, that's not mess itself, it's just omap specific panel framework.
>>> But dividing single device handling into two separate places is a mess.
>>
>> Yes, you are right it is not the mess, but it prevents the panel to
>> be used on other systems and that is BAD.
>> At the very least, drivers/video/backlight is a generic place that can be
>> used not just on OMAP.
>
> True, it's generic, but does it work reliably? The panel hardware is now
> partly handled in the backlight driver, and partly in the omap's panel
> driver (and wherever on other platforms).
It works reliably on other platforms, but not on OMAP - because
we need to cope with the OMAP specific framework...
>
> At least currently there's a dependency between the two, as the LCD_EN
> gpio is handled by the panel driver, which affects the functioning of
> the backlight driver. Is it ensured that the panel driver does not
> disable the panel when the backlight driver does spi transactions?
>
> That's what I meant with the mess, it's difficult to make it work
> reliably. I know that for some panels such a two-driver approach would
> not work at all. Although I guess it's working well enough for you for
> this panel.
Yep, that is correct - this is the mess.
>
> Thinking about it, if you do move the gpio handling to the backlight
> driver, the panel driver will only handle the DPI video stream. Then it
> should not have any effect on the SPI side (presuming the panel doesn't
> use the pixel clock as func clock), although there's probably still
> possibility for display artifacts on enable and disable, if the order of
> operations goes the wrong way.
Yep, again, that is correct.
>
>> And since the toppoly was and is used on other systems, why the hell
>> should anyone duplicate the driver just to please the OMAP specific
>> panel framework? The real problem is that this framework should not be
>
> Not to please. To make it reliable.
Well, there are multiple ways to make it reliable.
And I don't think that the best would be: make it OMAP specific.
>
>> OMAP specific...
>> Of course I'm aware of the fact that currently there is no generic
>> panel framework, but forging something OMAP specific which is obviously
>> used on most of the other architectures/platforms (and I mean
>> panel<->controller relations), is not a good way to go.
>
> Well, if duplicating the code gives us reliable drivers, versus
> unreliable without duplicating, then... I don't see it as that bad.
Hmmm... I don't think this fits the mainline (upstream) philosophy.
This can be also extrapolated into: let's make our own Linux ARM fork
so it will be more reliable...
This is the way how vendor specific kernel releases work.
>
>> Although, I'm also aware of the fact that most things are done this way:
>> do several specific drivers/frameworks, find the common stuff, and extract
>> it into a core driver/framework. So I don't want to blame anyone - that's
>> just the way how we do things, right?
>
> If it was easy, somebody would've done it.
In fact this is done all the time on multiple drivers and frameworks.
Also, I don't say this is easy, but I also don't think this too hard.
It is also a function of resources (time/will/experience/etc.).
>
>>>>> For a quick solution, can we just set the LCD_EN at boot time (with the
>>>>> msleep), and not touch it after that?
>>>>
>>>> That would be sensible for now, so this series can be merged.
>>>> As a more appropriate (and long term) solution,
>>>> I plan on moving the panel reset pin handling to the spi backlight
>>>> driver itself.
>>
>>> Well, if you must. But I suggest moving the whole panel handling into a
>>> (omap specific) panel driver, as it's done for other panels. That way
>>> you'll have a proper panel driver for it, for omap, and when CDF comes,
>>> you'll get a platform independent panel driver for it.
>>
>> You can't just move generic architecture/platform independent stuff
>> into OMAP specific framework... Just think about this... It's insane.
>
> As I said, reliable vs unreliable. That's not insane.
>
> But again, if you can handle this particular panel reliably with the
> two-driver approach, I'm fine with it.
Again, it works reliably on other platforms,
why would OMAP be an exception?
>
>> In addition, AFAIR, the reset pin is the property of the toppoly panel
>> hardware, so that is why I think, we should let the toppoly driver
>> (currently spi backlight, later hopefully CDF) handle it correctly
>> along with the spi sequences.
>
> Yes, that sounds ok.
>
> Tomi
>
- --
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRHLGzAAoJEBDE8YO64EfaOJMP/AtR9IkN+eWwdbt0R1Vu9vKH
mFgSCENqErAjYi3zM0YScj+E2zSby4rfXCY14Goh46DBCBXjRWYms6P/nZgGSLYT
lIup5YljWxWJxM0nvrykok872Atx+TSJukx3nD5foWieu4tNRRvhqN7+ckBO7R4D
J1D5uy3wH8Ea3SZ/foPrzewTeajnOeZxzhprfodLdmKIuqxInVE0KrWqrcefspNI
TvWAjLCHtoM4LDCZRaiHs3mN03QMdcJc1BfWeJe1eVx6YXSBqNTTG6mSgUegQyOG
PnC1T3kzS5Vuhmk9NfUmL19LInAljPVDoQomUqG6N140M6jol4ru+A5yE/NZ/tSl
j/8vz5pE8JXp0ueQt1X1vkAGL+Lgzbyrf38xQTxnjSLggO3OFHOv6AzlY453Lfem
gz6Xpjq+2Kcqxghfndd4yXnOjdlyWDN6dvYBthBBixmt34c6nNtdoXmakAXyw8wW
qSyT3sO6WgE53ROZRh9W2FCiLXdJ1rHYMBRRY4nbKNhOhtC/vSF4UVsFBUuAaqul
a6QToMggpugY8n3lm/SZ6LFWJDaHjnkUAVXxq3/GiclJSFwBnHqsOT1bfjsF5OfC
YnaldNBbH0WvmFN89Ds/inW1MLcFc/yWirB0Utj7ysb5AL4vH4QLs1dokzjxnTyK
WJmOMyQi7Jk+ocUSBgu2
=G6lL
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2013-02-14 9:43 UTC|newest]
Thread overview: 134+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-13 14:21 [PATCH 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers Archit Taneja
2013-02-13 14:33 ` Archit Taneja
2013-02-13 14:21 ` [PATCH 01/33] OMAPDSS: panels: keep platform data of all panels in a single header Archit Taneja
2013-02-13 14:33 ` Archit Taneja
2013-02-13 14:21 ` [PATCH 02/33] OMAPDSS: generic dpi panel: handle gpios in panel driver Archit Taneja
2013-02-13 14:33 ` Archit Taneja
2013-02-13 14:21 ` [PATCH 03/33] arm: omap: board-2430: use generic dpi panel's gpio handling Archit Taneja
2013-02-13 14:33 ` Archit Taneja
2013-02-13 14:21 ` [PATCH 04/33] arm: omap: board-devkit8000: " Archit Taneja
2013-02-13 14:33 ` Archit Taneja
2013-02-13 14:21 ` [PATCH 05/33] arm: omap: board-cm-t35: " Archit Taneja
2013-02-13 14:33 ` Archit Taneja
2013-02-13 15:16 ` Igor Grinberg
2013-02-13 15:16 ` Igor Grinberg
2013-02-13 15:28 ` Tomi Valkeinen
2013-02-13 15:28 ` Tomi Valkeinen
2013-02-13 15:59 ` Tomi Valkeinen
2013-02-13 15:59 ` Tomi Valkeinen
2013-02-14 6:56 ` Igor Grinberg
2013-02-14 6:56 ` Igor Grinberg
2013-02-14 7:09 ` Tomi Valkeinen
2013-02-14 7:09 ` Tomi Valkeinen
2013-02-14 8:37 ` Igor Grinberg
2013-02-14 8:37 ` Igor Grinberg
2013-02-14 9:09 ` Tomi Valkeinen
2013-02-14 9:09 ` Tomi Valkeinen
2013-02-14 9:43 ` Igor Grinberg [this message]
2013-02-14 9:43 ` Igor Grinberg
2013-02-14 10:59 ` Tomi Valkeinen
2013-02-14 10:59 ` Tomi Valkeinen
2013-02-14 12:37 ` Igor Grinberg
2013-02-14 12:37 ` Igor Grinberg
2013-02-14 12:52 ` Tomi Valkeinen
2013-02-14 12:52 ` Tomi Valkeinen
2013-02-14 13:51 ` Igor Grinberg
2013-02-14 13:51 ` Igor Grinberg
2013-04-03 12:02 ` Tomi Valkeinen
2013-04-03 12:02 ` Tomi Valkeinen
2013-04-04 7:17 ` Igor Grinberg
2013-04-04 7:17 ` Igor Grinberg
2013-02-13 14:21 ` [PATCH 06/33] arm: omap: board-apollon: " Archit Taneja
2013-02-13 14:33 ` Archit Taneja
2013-02-13 14:21 ` [PATCH 07/33] arm: omap: board-am3517: " Archit Taneja
2013-02-13 14:33 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 08/33] arm: omap: board-ldp: " Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 09/33] OMAPDSS: lb035q02: handle gpios in panel driver Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 10/33] arm: omap: board-overo: use lb035q02 dpi panel's gpio handling Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 11/33] OMAPDSS: lb035q02 panel: remove platform_enable/disable callbacks Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 12/33] OMAPDSS: generic dpi panel: remove platform_enable/disable ops from platform_data Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 13/33] arm: omap: board-omap3evm: use sharp panel's gpio handling Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 14/33] arm: omap: board-sdp3430: " Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 15/33] OMAPDSS: sharp-ls panel: remove platform_enable/disable callbacks Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 16/33] OMAPDSS: acx565akm panel: handle gpios in panel driver Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 17:29 ` Aaro Koskinen
2013-02-13 17:29 ` Aaro Koskinen
2013-02-14 6:51 ` Archit Taneja
2013-02-14 6:52 ` Archit Taneja
2013-02-14 6:58 ` Tomi Valkeinen
2013-02-14 6:58 ` Tomi Valkeinen
2013-02-14 7:08 ` Archit Taneja
2013-02-14 7:20 ` Archit Taneja
2013-02-18 7:33 ` Archit Taneja
2013-02-18 7:45 ` Archit Taneja
2013-02-18 8:11 ` Tomi Valkeinen
2013-02-18 8:11 ` Tomi Valkeinen
2013-02-18 8:23 ` Archit Taneja
2013-02-18 8:35 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 17/33] arm: omap: board-rx-51: use acx565akm panel's gpio handling Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 18/33] OMAPDSS: nec-nl8048 panel: handle gpios ins panel driver Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 19/33] arm: omap: board-zoom: use NEC panel's gpio handling Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 20/33] OMAPDSS: nec-nl8048 panel: remove platform_enable/disable callbacks Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 21/33] OMAPDSS: tpo-td043 panel: handle gpios in panel driver Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 22/33] arm: omap: board-omap3pandora: use tpo panel's gpio handling Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 23/33] OMAPDSS: tpo-td043: remove platform_enable/disable callbacks Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 24/33] OMAPDSS: picodlp panel: handle gpio data in panel driver Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 25/33] arm: omap: dss-common: use picodlp panel's gpio handling Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 26/33] OMAPDSS: picodlp panel: remove platform_enable/disable callbacks Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 27/33] OMAPDSS: n8x0 panel: handle gpio data in panel driver Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 17:35 ` Aaro Koskinen
2013-02-13 17:35 ` Aaro Koskinen
2013-02-14 6:34 ` Archit Taneja
2013-02-14 6:46 ` Archit Taneja
2013-02-14 12:45 ` Aaro Koskinen
2013-02-14 12:45 ` Aaro Koskinen
2013-02-13 14:22 ` [PATCH 28/33] OMAPDSS: n8x0 panel: remove platform_enable/disable callbacks Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 29/33] arm: omap boards: Remove unnecessary platform_enable/disable callbacks for VENC devices Archit Taneja
2013-02-13 14:34 ` [PATCH 29/33] arm: omap boards: Remove unnecessary platform_enable/disable callbacks for VENC device Archit Taneja
2013-02-13 14:22 ` [PATCH 30/33] OMAPDSS: VENC: remove platform_enable/disable calls Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 31/33] OMAPDSS: remove platform_enable/disable callbacks from omap_dss_device Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 32/33] arm: dss-common: don't use reset_gpio from omap4_panda_dvi_device Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 14:22 ` [PATCH 33/33] OMAPDSS: remove reset_gpio field from omap_dss_device Archit Taneja
2013-02-13 14:34 ` Archit Taneja
2013-02-13 16:46 ` [PATCH 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers Tony Lindgren
2013-02-13 16:46 ` Tony Lindgren
2013-02-14 7:17 ` Archit Taneja
2013-02-14 7:29 ` Archit Taneja
2013-04-03 12:28 ` Tomi Valkeinen
2013-04-03 12:28 ` Tomi Valkeinen
2013-04-03 15:46 ` Tony Lindgren
2013-04-03 15:46 ` Tony Lindgren
2013-04-15 9:29 ` Tomi Valkeinen
2013-04-15 9:29 ` Tomi Valkeinen
2013-04-15 21:20 ` Tony Lindgren
2013-04-15 21:20 ` Tony Lindgren
2013-04-16 4:20 ` Tomi Valkeinen
2013-04-16 4:20 ` Tomi Valkeinen
2013-04-18 0:34 ` Tony Lindgren
2013-04-18 0:34 ` Tony Lindgren
2013-04-18 3:40 ` Tomi Valkeinen
2013-04-18 3:40 ` Tomi Valkeinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=511CB1B3.80605@compulab.co.il \
--to=grinberg@compulab.co.il \
--cc=archit@ti.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=tomi.valkeinen@ti.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.