* Re: [PATCH] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
From: Belisko Marek @ 2013-10-11 8:59 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Dr. H. Nikolaus Schaller, Lars-Peter Clausen,
Jean-Christophe PLAGNIOL-VILLARD, LKML,
linux-omap@vger.kernel.org, linux-fbdev
In-Reply-To: <5257B420.10808@ti.com>
Hi Tomi,
On Fri, Oct 11, 2013 at 10:17 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 11/10/13 10:42, Dr. H. Nikolaus Schaller wrote:
>
>> I am not sure if there is a SPI driver for a McBSP port [1]? And to make that
>> work (reliably) and tested it might need a lot of work for us. At least I think
>> such a change (e.g. setting up clock polarity etc.) is not done in some minutes.
>> And the only feedback we have from the panel is "does not work"/"works". I.e.
>> if we are not lucky that it works immediately we have no real means to debug.
>>
>> IMHO it also gives more flexibility to board designers to choose GPIOs instead
>> of enforcing some SPI interface by the driver (and encapsulate this arguable
>> protocol in the driver). Maybe some board has 3 spare GPIOs but neither
>> McBSPs nor McSPIs available.
>
> This has been an interesting thread, I've learnt a lot =).
>
> I still think the panel driver should not handle this, but there should
> be a separate spi bitbang driver for it.
>
> I understand you're not enthusiastic going that way, as the current
> version works for you. However, when using DT, we need to think how to
> represent the hardware in the device tree data, and it has to be right
> from the beginning.
>
> That's why I won't allow representing this panel as having 4 gpios in
> the DT data, because that is not correct. The panel has 3 pins. But
> then, the panel does allow reading, which could be implemented using 4
> gpios as you have done. This data should be in the spi-bitbang data, and
> the panel should just use the standard SPI framework.
I disagree. There are different drivers which pass in platform data
gpios (encoder-tfp410.c or encoder-tpd12s015.c)
and those must be covered by DT then. I cannot see problem why to have
for td028 panel 3 or 4 gpios defined in DT.
>
> Using SPI framework does not mean you should use McBSP or McSPI. It's up
> to you how the 3-wire SPI is implemented on the SoC side, the panel
> would just work in all the cases.
>
> Tomi
>
>
BR,
marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
^ permalink raw reply
* Re: [PATCH] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
From: Tomi Valkeinen @ 2013-10-11 9:04 UTC (permalink / raw)
To: Belisko Marek
Cc: Dr. H. Nikolaus Schaller, Lars-Peter Clausen,
Jean-Christophe PLAGNIOL-VILLARD, LKML,
linux-omap@vger.kernel.org, linux-fbdev
In-Reply-To: <CAAfyv36HSb4FOxaYnqcwBusqSuhtVnT0gEAoGgcW_rBkhWhf0A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]
On 11/10/13 11:59, Belisko Marek wrote:
>> That's why I won't allow representing this panel as having 4 gpios in
>> the DT data, because that is not correct. The panel has 3 pins. But
>> then, the panel does allow reading, which could be implemented using 4
>> gpios as you have done. This data should be in the spi-bitbang data, and
>> the panel should just use the standard SPI framework.
> I disagree. There are different drivers which pass in platform data
> gpios (encoder-tfp410.c or encoder-tpd12s015.c)
> and those must be covered by DT then. I cannot see problem why to have
> for td028 panel 3 or 4 gpios defined in DT.
Yes, they are plain GPIOs, and defined in the spec for the respective
chip. There's no alternative to how they could be represented.
Here, with the td028, the spec speaks of 3 pins for the serial bus. Not
4. So there cannot be 4 gpios defined in the panel's data, that just
doesn't make sense.
Additionally, what we have here are not "normal" gpios, but pins for a
serial bus, 3-wire SPI. If the panel data specifies the gpios, then it's
not possible to use real SPI hardware with the panel.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
From: Lars-Peter Clausen @ 2013-10-11 9:06 UTC (permalink / raw)
To: Belisko Marek
Cc: Tomi Valkeinen, Dr. H. Nikolaus Schaller,
Jean-Christophe PLAGNIOL-VILLARD, LKML,
linux-omap@vger.kernel.org, linux-fbdev
In-Reply-To: <CAAfyv36HSb4FOxaYnqcwBusqSuhtVnT0gEAoGgcW_rBkhWhf0A@mail.gmail.com>
On 10/11/2013 10:59 AM, Belisko Marek wrote:
> Hi Tomi,
>
> On Fri, Oct 11, 2013 at 10:17 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 11/10/13 10:42, Dr. H. Nikolaus Schaller wrote:
>>
>>> I am not sure if there is a SPI driver for a McBSP port [1]? And to make that
>>> work (reliably) and tested it might need a lot of work for us. At least I think
>>> such a change (e.g. setting up clock polarity etc.) is not done in some minutes.
>>> And the only feedback we have from the panel is "does not work"/"works". I.e.
>>> if we are not lucky that it works immediately we have no real means to debug.
>>>
>>> IMHO it also gives more flexibility to board designers to choose GPIOs instead
>>> of enforcing some SPI interface by the driver (and encapsulate this arguable
>>> protocol in the driver). Maybe some board has 3 spare GPIOs but neither
>>> McBSPs nor McSPIs available.
>>
>> This has been an interesting thread, I've learnt a lot =).
>>
>> I still think the panel driver should not handle this, but there should
>> be a separate spi bitbang driver for it.
>>
>> I understand you're not enthusiastic going that way, as the current
>> version works for you. However, when using DT, we need to think how to
>> represent the hardware in the device tree data, and it has to be right
>> from the beginning.
>>
>> That's why I won't allow representing this panel as having 4 gpios in
>> the DT data, because that is not correct. The panel has 3 pins. But
>> then, the panel does allow reading, which could be implemented using 4
>> gpios as you have done. This data should be in the spi-bitbang data, and
>> the panel should just use the standard SPI framework.
> I disagree. There are different drivers which pass in platform data
> gpios (encoder-tfp410.c or encoder-tpd12s015.c)
> and those must be covered by DT then. I cannot see problem why to have
> for td028 panel 3 or 4 gpios defined in DT.
The problem is not representing it in the devicetree, but representing it
correctly. This is a SPI slave device, hence it should be presented in the
devicetree as a SPI slave device and not as a platform device with 4 GPIOs.
- Lars
^ permalink raw reply
* Re: [PATCH] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
From: Dr. H. Nikolaus Schaller @ 2013-10-11 9:50 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Belisko Marek, Tomi Valkeinen, Jean-Christophe PLAGNIOL-VILLARD,
LKML, linux-omap@vger.kernel.org, linux-fbdev
In-Reply-To: <5257BFA3.9090202@metafoo.de>
Hi all,
Am 11.10.2013 um 11:06 schrieb Lars-Peter Clausen:
> On 10/11/2013 10:59 AM, Belisko Marek wrote:
>> Hi Tomi,
>>
>> On Fri, Oct 11, 2013 at 10:17 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>> On 11/10/13 10:42, Dr. H. Nikolaus Schaller wrote:
>>>
>>>> I am not sure if there is a SPI driver for a McBSP port [1]? And to make that
>>>> work (reliably) and tested it might need a lot of work for us. At least I think
>>>> such a change (e.g. setting up clock polarity etc.) is not done in some minutes.
>>>> And the only feedback we have from the panel is "does not work"/"works". I.e.
>>>> if we are not lucky that it works immediately we have no real means to debug.
>>>>
>>>> IMHO it also gives more flexibility to board designers to choose GPIOs instead
>>>> of enforcing some SPI interface by the driver (and encapsulate this arguable
>>>> protocol in the driver). Maybe some board has 3 spare GPIOs but neither
>>>> McBSPs nor McSPIs available.
>>>
>>> This has been an interesting thread, I've learnt a lot =).
>>>
>>> I still think the panel driver should not handle this, but there should
>>> be a separate spi bitbang driver for it.
>>>
>>> I understand you're not enthusiastic going that way, as the current
>>> version works for you. However, when using DT, we need to think how to
>>> represent the hardware in the device tree data, and it has to be right
>>> from the beginning.
>>>
>>> That's why I won't allow representing this panel as having 4 gpios in
>>> the DT data, because that is not correct. The panel has 3 pins. But
>>> then, the panel does allow reading, which could be implemented using 4
>>> gpios as you have done. This data should be in the spi-bitbang data, and
>>> the panel should just use the standard SPI framework.
>> I disagree. There are different drivers which pass in platform data
>> gpios (encoder-tfp410.c or encoder-tpd12s015.c)
>> and those must be covered by DT then. I cannot see problem why to have
>> for td028 panel 3 or 4 gpios defined in DT.
>
> The problem is not representing it in the devicetree, but representing it
> correctly. This is a SPI slave device, hence it should be presented in the
> devicetree as a SPI slave device and not as a platform device with 4 GPIOs.
Hm. Is this a SPI or does it just look like one? Or is it some - otherwise
unknown - "3 wire serial interface". Or is it a "3(+1) GPIO slave device"?
I am still not sure about this.
If we really want to do it correctly, we may have to write a driver for that
special serial protocol as well. If it turns out that we can't mis-use and tweak
it into a standard SPI driver with bit-bang backend.
I simply fear that we get dependencies with the SPI subsystem and have
to test, debug and maintain it. Maintaining the GPIO thing we currently have
is easy.
What would be against taking the GPIO approach first and then upgrade as soon
as someone raises his/her finger that he/she wants to really interface this display
differently and is not happy with the 3/4 GPIOs? Either they come up with a patch
or contact the driver author (=me).
BR,
Nikolaus
^ permalink raw reply
* Re: [PATCH] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
From: Tomi Valkeinen @ 2013-10-11 10:09 UTC (permalink / raw)
To: Dr. H. Nikolaus Schaller, Lars-Peter Clausen
Cc: Belisko Marek, Jean-Christophe PLAGNIOL-VILLARD, LKML,
linux-omap@vger.kernel.org, linux-fbdev
In-Reply-To: <B8F44C8A-362C-4E78-BE91-D9C0783B998B@goldelico.com>
[-- Attachment #1: Type: text/plain, Size: 2296 bytes --]
On 11/10/13 12:50, Dr. H. Nikolaus Schaller wrote:
> Hm. Is this a SPI or does it just look like one? Or is it some - otherwise
> unknown - "3 wire serial interface". Or is it a "3(+1) GPIO slave device"?
> I am still not sure about this.
Lars-Peter said "Back in the OpenMoko days we used the panel in normal
4-wire SPI mode with the GPIO bitbang SPI master."
I don't know much about SPI, so I can't answer to that. If the serial
bus is indeed not any kind of more or less standard SPI version, but
really a custom bus for this controller, then the case is a bit unclear.
> If we really want to do it correctly, we may have to write a driver for that
> special serial protocol as well. If it turns out that we can't mis-use and tweak
> it into a standard SPI driver with bit-bang backend.
>
> I simply fear that we get dependencies with the SPI subsystem and have
> to test, debug and maintain it. Maintaining the GPIO thing we currently have
> is easy.
>
> What would be against taking the GPIO approach first and then upgrade as soon
> as someone raises his/her finger that he/she wants to really interface this display
> differently and is not happy with the 3/4 GPIOs? Either they come up with a patch
> or contact the driver author (=me).
I don't have anything against that as long as we use only platform data.
But DT data is not an in-kernel API, it's an external API. Once we
define that the DT data for this panel is something, that's it, we
should stick to it. Of course, we can build compatibility layers for old
DT data, but I would avoid that if at all possible.
If we now create the DT data with gpios, and the panel as platform
device, it'd be rather nasty change to make it a child of an spi bus. (I
presume, I have never made such a change).
And, as the gpios and platform device approach is clearly wrong way to
describe the hardware, I'm quite against using that description in the
DT data.
That said, one option is to describe the hardware correctly in the DT
data, but have a platform device for the panel, with panel driver doing
the bitbanging. In that case it is possible to update the system to use
SPI framework if needed, without changing the DT data. However, I'm not
sure how easy that would be.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
From: Dr. H. Nikolaus Schaller @ 2013-10-11 11:03 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Lars-Peter Clausen, Belisko Marek,
Jean-Christophe PLAGNIOL-VILLARD, LKML,
linux-omap@vger.kernel.org, linux-fbdev
In-Reply-To: <5257CE55.3090902@ti.com>
Hi Tomi,
Am 11.10.2013 um 12:09 schrieb Tomi Valkeinen:
> On 11/10/13 12:50, Dr. H. Nikolaus Schaller wrote:
>
>> Hm. Is this a SPI or does it just look like one? Or is it some - otherwise
>> unknown - "3 wire serial interface". Or is it a "3(+1) GPIO slave device"?
>> I am still not sure about this.
>
> Lars-Peter said "Back in the OpenMoko days we used the panel in normal
> 4-wire SPI mode with the GPIO bitbang SPI master."
>
> I don't know much about SPI, so I can't answer to that. If the serial
> bus is indeed not any kind of more or less standard SPI version, but
> really a custom bus for this controller, then the case is a bit unclear.
I have thought over lunch time that it is worth to look into how the Openmoko
did physically hook up the display and if parts of that code (it was for 2.6.26
or so and for a Samsung SoC) is understandable and reusable (e.g. hints
how to set up the board file for a bitbang SPI on OMAP3 - we have never
done this before).
>
>> If we really want to do it correctly, we may have to write a driver for that
>> special serial protocol as well. If it turns out that we can't mis-use and tweak
>> it into a standard SPI driver with bit-bang backend.
>>
>> I simply fear that we get dependencies with the SPI subsystem and have
>> to test, debug and maintain it. Maintaining the GPIO thing we currently have
>> is easy.
>>
>> What would be against taking the GPIO approach first and then upgrade as soon
>> as someone raises his/her finger that he/she wants to really interface this display
>> differently and is not happy with the 3/4 GPIOs? Either they come up with a patch
>> or contact the driver author (=me).
>
> I don't have anything against that as long as we use only platform data.
>
> But DT data is not an in-kernel API, it's an external API. Once we
> define that the DT data for this panel is something, that's it, we
> should stick to it. Of course, we can build compatibility layers for old
> DT data, but I would avoid that if at all possible.
Ah, I see. I already think that using the DT makes such things not easier
but more difficult - but I am not at all familiar with it.
> If we now create the DT data with gpios, and the panel as platform
> device, it'd be rather nasty change to make it a child of an spi bus. (I
> presume, I have never made such a change).
>
> And, as the gpios and platform device approach is clearly wrong way to
> describe the hardware, I'm quite against using that description in the
> DT data.
Since we are not familiar with DT yet, it is difficult to see the consequences
of such a step.
> That said, one option is to describe the hardware correctly in the DT
> data, but have a platform device for the panel, with panel driver doing
> the bitbanging. In that case it is possible to update the system to use
> SPI framework if needed, without changing the DT data. However, I'm not
> sure how easy that would be.
Sounds quite complex, indeed.
So our next step will be to look into the GTA02 SPI thing to get more knowlegde
about thier solution.
BR,
Nikolaus
^ permalink raw reply
* Re: [PATCH/RFC v3 00/19] Common Display Framework
From: Andrzej Hajda @ 2013-10-11 11:19 UTC (permalink / raw)
To: Tomi Valkeinen, Laurent Pinchart
Cc: linux-fbdev, dri-devel, Jesse Barnes, Benjamin Gaignard, Tom Gall,
Kyungmin Park, linux-media, Stephen Warren, Mark Zhang,
Alexandre Courbot, Ragesh Radhakrishnan, Thomas Petazzoni,
Sunil Joshi, Maxime Ripard, Vikas Sajjan, Marcus Lorentzon
In-Reply-To: <52579CB2.8050601@ti.com>
On 10/11/2013 08:37 AM, Tomi Valkeinen wrote:
> On 09/10/13 17:08, Andrzej Hajda wrote:
>
>> As I have adopted existing internal driver for MIPI-DSI bus, I did not
>> take too much
>> care for DT. You are right, 'bta-timeout' is a configuration parameter
>> (however its
>> minimal value is determined by characteristic of the DSI-slave). On the
>> other
>> side currently there is no good place for such configuration parameters
>> AFAIK.
> The minimum bta-timeout should be deducable from the DSI bus speed,
> shouldn't it? Thus there's no need to define it anywhere.
Hmm, specification says "This specified period shall be longer then
the maximum possible turnaround delay for the unit to which the
turnaround request was sent".
>
>>> - enable_hs and enable_te, used to enable/disable HS mode and
>>> tearing-elimination
>> It seems there should be a way to synchronize TE signal with panel,
>> in case signal is provided only to dsi-master. Some callback I suppose?
>> Or transfer synchronization should be done by dsi-master.
> Hmm, can you explain a bit what you mean?
>
> Do you mean that the panel driver should get a callback when DSI TE
> trigger happens?
>
> On OMAP, when using DSI TE trigger, the dsi-master does it all. So the
> panel driver just calls update() on the dsi-master, and then the
> dsi-master will wait for TE, and then start the transfer. There's also a
> callback to the panel driver when the transfer has completed.
Yes I though about a callback, but approach with DSI-master taking care
of synchronization in fact better fits to exynos-dsi and I suspect to
omap also.
>
>>> - set_max_rx_packet_size, used to configure the max rx packet size.
>> Similar callbacks should be added to mipi-dsi-bus ops as well, to
>> make it complete/generic.
> Do you mean the same calls should exist both in the mipi-dbi-bus ops and
> on the video ops? If they are called with different values, which one
> "wins"?
No, I meant that if mipi-dbi-bus want to be complete it should have
similar ops.
I did not think about scenario with two overlaping APIs.
>
>>> http://article.gmane.org/gmane.comp.video.dri.devel/90651
>>> http://article.gmane.org/gmane.comp.video.dri.devel/91269
>>> http://article.gmane.org/gmane.comp.video.dri.devel/91272
>>>
>>> I still think that it's best to consider DSI and DBI as a video bus (not
>>> as a separate video bus and a control bus), and provide the packet
>>> transfer methods as part of the video ops.
>> I have read all posts regarding this issue and currently I tend
>> to solution where CDF is used to model only video streams,
>> with control bus implemented in different framework.
>> The only concerns I have if we should use Linux bus for that.
> Ok. I have many other concerns, as I've expressed in the mails =). I
> still don't see how it could work. So I'd very much like to see a more
> detailed explanation how the separate control & video bus approach would
> deal with different scenarios.
>
> Let's consider a DSI-to-HDMI encoder chip. Version A of the chip is
> controlled via DSI, version B is controlled via i2c. As the output of
> the chip goes to HDMI connector, the DSI bus speed needs to be set
> according to the resolution of the HDMI monitor.
>
> So, with version A, the encoder driver would have some kind of pointers
> to ctrl_ops and video_ops (or, pointers to dsi_bus instance and
> video_bus instance), right? The ctrl_ops would need to have ops like
> set_bus_speed, enable_hs, etc, to configure the DSI bus.
>
> When the encoder driver is started, it'd probably set some safe bus
> speed, configure the encoder a bit, read the EDID, enable HS,
> re-configure the bus speed to match the monitor's video mode, configure
> the encoder, and at last enable the video stream.
>
> Version B would have i2c_client and video_ops. When the driver starts,
> it'd probably do the same things as above, except the control messages
> would go through i2c. That means that setting the bus speed, enabling
> HS, etc, would happen through video_ops, as the i2c side has no
> knowledge of the DSI side, right? Would there be identical ops on both
> DSI ctrl and video ops?
>
> That sounds very bad. What am I missing here? How would it work?
If I undrestand correctly you think about CDF topology like below:
DispContr(SoC) ---> DSI-master(SoC) ---> encoder(DSI or I2C)
But I think with mipi-dsi-bus topology could look like:
DispContr(SoC) ---> encoder(DSI or I2C)
DSI-master will not have its own entity, in the graph it could be
represented
by the link(--->), as it really does not process the video, only
transports it.
In case of version A I think everything is clear.
In case of version B it does not seems so nice at the first sight, but
still seems quite straightforward to me - special plink in encoder's
node pointing
to DSI-master, driver will find the device in runtime and use ops as needed
(additional ops/helpers required).
This is also the way to support devices which can be controlled by DSI
and I2C
in the same time. Anyway I suspect such scenario will be quite rare.
>
> And, if we want to separate the video and control, I see no reason to
> explicitly require the video side to be present. I.e. we could as well
> have a DSI peripheral that has only the control bus used. How would that
> reflect to, say, the DT presentation? Say, if we have a version A of the
> encoder, we could have DT data like this (just a rough example):
>
> soc-dsi {
> encoder {
> input: endpoint {
> remote-endpoint = <&soc-dsi-ep>;
Here I would replace &soc-dsi-ep by phandle to display controller/crtc/....
> /* configuration for the DSI lanes */
> dsi-lanes = <0 1 2 3 4 5>;
Wow, quite advanced DSI.
> };
> };
> };
>
> So the encoder would be places inside the SoC's DSI node, similar to how
> an i2c device would be placed inside SoC's i2c node. DSI configuration
> would be inside the video endpoint data.
>
> Version B would be almost the same:
>
> &i2c0 {
> encoder {
> input: endpoint {
> remote-endpoint = <&soc-dsi-ep>;
&soc-dsi-ep => &disp-ctrl-ep
> /* configuration for the DSI lanes */
> dsi-lanes = <0 1 2 3 4 5>;
> };
> };
> };
>
> Now, how would the video-bus-less device be defined?
> It'd be inside the
> soc-dsi node, that's clear. Where would the DSI lane configuration be?
> Not inside 'endpoint' node, as that's for video and wouldn't exist in
> this case. Would we have the same lane configuration in two places, once
> for video and once for control?
I think it is control setting, so it should be put outside endpoint node.
Probably it could be placed in encoder node.
>
> I agree that having DSI/DBI control and video separated would be
> elegant. But I'd like to hear what is the technical benefit of that? At
> least to me it's clearly more complex to separate them than to keep them
> together (to the extent that I don't yet see how it is even possible),
> so there must be a good reason for the separation. I don't understand
> that reason. What is it?
Roughly speaking it is a question where is the more convenient place to
put bunch
of opses, technically both solutions can be somehow implemented.
Pros of mipi bus:
- no fake entity in CDF, with fake opses, I have to use similar entities
in MIPI-CSI
camera pipelines and it complicates life without any benefit(at least
from user side),
- CDF models only video buses, control bus is a domain of Linux buses,
- less platform_bus abusing,
- better device tree topology (at least for common cases),
- quite simple in case of typical devices.
Regards
Andrzej
>
> Tomi
>
>
^ permalink raw reply
* Re: [PATCH/RFC v3 00/19] Common Display Framework
From: Tomi Valkeinen @ 2013-10-11 12:30 UTC (permalink / raw)
To: Andrzej Hajda, Laurent Pinchart
Cc: linux-fbdev, dri-devel, Jesse Barnes, Benjamin Gaignard, Tom Gall,
Kyungmin Park, linux-media, Stephen Warren, Mark Zhang,
Alexandre Courbot, Ragesh Radhakrishnan, Thomas Petazzoni,
Sunil Joshi, Maxime Ripard, Vikas Sajjan, Marcus Lorentzon
In-Reply-To: <5257DEB5.6000708@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 7199 bytes --]
On 11/10/13 14:19, Andrzej Hajda wrote:
> On 10/11/2013 08:37 AM, Tomi Valkeinen wrote:
>> The minimum bta-timeout should be deducable from the DSI bus speed,
>> shouldn't it? Thus there's no need to define it anywhere.
> Hmm, specification says "This specified period shall be longer then
> the maximum possible turnaround delay for the unit to which the
> turnaround request was sent".
Ah, you're right. We can't know how long the peripheral will take
responding. I was thinking of something that only depends on the
bus-speed and the timings for that.
> If I undrestand correctly you think about CDF topology like below:
>
> DispContr(SoC) ---> DSI-master(SoC) ---> encoder(DSI or I2C)
>
> But I think with mipi-dsi-bus topology could look like:
>
> DispContr(SoC) ---> encoder(DSI or I2C)
>
> DSI-master will not have its own entity, in the graph it could be
> represented
> by the link(--->), as it really does not process the video, only
> transports it.
At least in OMAP, the SoC's DSI-master receives parallel RGB data from
DISPC, and encodes it to DSI. Isn't that processing? It's basically a
DPI-to-DSI encoder. And it's not a simple pass-through, the DSI video
timings could be considerably different than the DPI timings.
> In case of version A I think everything is clear.
> In case of version B it does not seems so nice at the first sight, but
> still seems quite straightforward to me - special plink in encoder's
> node pointing
> to DSI-master, driver will find the device in runtime and use ops as needed
> (additional ops/helpers required).
> This is also the way to support devices which can be controlled by DSI
> and I2C
> in the same time. Anyway I suspect such scenario will be quite rare.
Okay, so if I gather it right, you say there would be something like
'dsi_adapter' (like i2c_adapter), which represents the dsi-master. And a
driver could get pointer to this, regardless of whether it the linux
device is a DSI device.
At least one issue with this approach is the endpoint problem (see below).
>> And, if we want to separate the video and control, I see no reason to
>> explicitly require the video side to be present. I.e. we could as well
>> have a DSI peripheral that has only the control bus used. How would that
>> reflect to, say, the DT presentation? Say, if we have a version A of the
>> encoder, we could have DT data like this (just a rough example):
>>
>> soc-dsi {
>> encoder {
>> input: endpoint {
>> remote-endpoint = <&soc-dsi-ep>;
> Here I would replace &soc-dsi-ep by phandle to display controller/crtc/....
>
>> /* configuration for the DSI lanes */
>> dsi-lanes = <0 1 2 3 4 5>;
> Wow, quite advanced DSI.
Wha? That just means there is one clock lane and two datalanes, nothing
more =). We can select the polarity of a lane, so we describe both the
positive and negative lines there. So it says clk- is connected to pin
0, clk+ connected to pin 1, etc.
>> };
>> };
>> };
>>
>> So the encoder would be places inside the SoC's DSI node, similar to how
>> an i2c device would be placed inside SoC's i2c node. DSI configuration
>> would be inside the video endpoint data.
>>
>> Version B would be almost the same:
>>
>> &i2c0 {
>> encoder {
>> input: endpoint {
>> remote-endpoint = <&soc-dsi-ep>;
> &soc-dsi-ep => &disp-ctrl-ep
>> /* configuration for the DSI lanes */
>> dsi-lanes = <0 1 2 3 4 5>;
>> };
>> };
>> };
>>
>> Now, how would the video-bus-less device be defined?
>> It'd be inside the
>> soc-dsi node, that's clear. Where would the DSI lane configuration be?
>> Not inside 'endpoint' node, as that's for video and wouldn't exist in
>> this case. Would we have the same lane configuration in two places, once
>> for video and once for control?
> I think it is control setting, so it should be put outside endpoint node.
> Probably it could be placed in encoder node.
Well, one point of the endpoints is also to allow "switching" of video
devices.
For example, I could have a board with a SoC's DSI output, connected to
two DSI panels. There would be some kind of mux between, so that I can
select which of the panels is actually connected to the SoC.
Here the first panel could use 2 datalanes, the second one 4. Thus, the
DSI master would have two endpoints, the other one using 2 and the other
4 datalanes.
If we decide that kind of support is not needed, well, is there even
need for the V4L2 endpoints in the DT data at all?
>> I agree that having DSI/DBI control and video separated would be
>> elegant. But I'd like to hear what is the technical benefit of that? At
>> least to me it's clearly more complex to separate them than to keep them
>> together (to the extent that I don't yet see how it is even possible),
>> so there must be a good reason for the separation. I don't understand
>> that reason. What is it?
> Roughly speaking it is a question where is the more convenient place to
> put bunch
> of opses, technically both solutions can be somehow implemented.
Well, it's also about dividing a single physical bus into two separate
interfaces to it. It sounds to me that it would be much more complex
with locking. With a single API, we can just say "the caller handles
locking". With two separate interfaces, there must be locking at the
lower level.
> Pros of mipi bus:
> - no fake entity in CDF, with fake opses, I have to use similar entities
> in MIPI-CSI
> camera pipelines and it complicates life without any benefit(at least
> from user side),
You mean the DSI-master? I don't see how it's "fake", it's a video
processing unit that has to be configured. Even if we forget the control
side, and just think about plain video stream with DSI video mode,
there's are things to configure with it.
What kind of issues you have in the CSI side, then?
> - CDF models only video buses, control bus is a domain of Linux buses,
Yes, but in this case the buses are the same. It makes me a bit nervous
to have two separate ways (video and control) to use the same bus, in a
case like video where timing is critical.
So yes, we can consider video and control buses as "virtual" buses, and
the actual transport is the DSI bus. Maybe it can be done. It just makes
me a bit nervous =).
> - less platform_bus abusing,
Well, platform.txt says
"This pseudo-bus
is used to connect devices on busses with minimal infrastructure,
like those used to integrate peripherals on many system-on-chip
processors, or some "legacy" PC interconnects; as opposed to large
formally specified ones like PCI or USB."
I don't think DSI and DBI as platform bus is that far from the
description. They are "simple", no probing point-to-point (in practice)
buses. There's not much "bus" to speak of, just a point-to-point link.
> - better device tree topology (at least for common cases),
Even if we use platform devices for DSI peripherals, we can have them
described under the DSI master node.
> - quite simple in case of typical devices.
Still more complex than single API for both video and control =).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC v3 00/19] Common Display Framework
From: Andrzej Hajda @ 2013-10-11 14:16 UTC (permalink / raw)
To: Tomi Valkeinen, Laurent Pinchart
Cc: linux-fbdev, dri-devel, Jesse Barnes, Benjamin Gaignard, Tom Gall,
Kyungmin Park, linux-media, Stephen Warren, Mark Zhang,
Alexandre Courbot, Ragesh Radhakrishnan, Thomas Petazzoni,
Sunil Joshi, Maxime Ripard, Vikas Sajjan, Marcus Lorentzon
In-Reply-To: <5257EF6A.4020005@ti.com>
On 10/11/2013 02:30 PM, Tomi Valkeinen wrote:
> On 11/10/13 14:19, Andrzej Hajda wrote:
>> On 10/11/2013 08:37 AM, Tomi Valkeinen wrote:
>>> The minimum bta-timeout should be deducable from the DSI bus speed,
>>> shouldn't it? Thus there's no need to define it anywhere.
>> Hmm, specification says "This specified period shall be longer then
>> the maximum possible turnaround delay for the unit to which the
>> turnaround request was sent".
> Ah, you're right. We can't know how long the peripheral will take
> responding. I was thinking of something that only depends on the
> bus-speed and the timings for that.
>
>> If I undrestand correctly you think about CDF topology like below:
>>
>> DispContr(SoC) ---> DSI-master(SoC) ---> encoder(DSI or I2C)
>>
>> But I think with mipi-dsi-bus topology could look like:
>>
>> DispContr(SoC) ---> encoder(DSI or I2C)
>>
>> DSI-master will not have its own entity, in the graph it could be
>> represented
>> by the link(--->), as it really does not process the video, only
>> transports it.
> At least in OMAP, the SoC's DSI-master receives parallel RGB data from
> DISPC, and encodes it to DSI. Isn't that processing? It's basically a
> DPI-to-DSI encoder. And it's not a simple pass-through, the DSI video
> timings could be considerably different than the DPI timings.
Picture size, content and format is the same on input and on output of DSI.
The same bits which enters DSI appears on the output. Internally bits
order can
be different but practically you are configuring DSI master and slave
with the same format.
If you create DSI entity you will have to always set the same format and
size on DSI input, DSI output and encoder input.
If you skip creating DSI entity you loose nothing, and you do not need
to take care of it.
>
>> In case of version A I think everything is clear.
>> In case of version B it does not seems so nice at the first sight, but
>> still seems quite straightforward to me - special plink in encoder's
>> node pointing
>> to DSI-master, driver will find the device in runtime and use ops as needed
>> (additional ops/helpers required).
>> This is also the way to support devices which can be controlled by DSI
>> and I2C
>> in the same time. Anyway I suspect such scenario will be quite rare.
> Okay, so if I gather it right, you say there would be something like
> 'dsi_adapter' (like i2c_adapter), which represents the dsi-master. And a
> driver could get pointer to this, regardless of whether it the linux
> device is a DSI device.
>
> At least one issue with this approach is the endpoint problem (see below).
>
>>> And, if we want to separate the video and control, I see no reason to
>>> explicitly require the video side to be present. I.e. we could as well
>>> have a DSI peripheral that has only the control bus used. How would that
>>> reflect to, say, the DT presentation? Say, if we have a version A of the
>>> encoder, we could have DT data like this (just a rough example):
>>>
>>> soc-dsi {
>>> encoder {
>>> input: endpoint {
>>> remote-endpoint = <&soc-dsi-ep>;
>> Here I would replace &soc-dsi-ep by phandle to display controller/crtc/....
>>
>>> /* configuration for the DSI lanes */
>>> dsi-lanes = <0 1 2 3 4 5>;
>> Wow, quite advanced DSI.
> Wha? That just means there is one clock lane and two datalanes, nothing
> more =). We can select the polarity of a lane, so we describe both the
> positive and negative lines there. So it says clk- is connected to pin
> 0, clk+ connected to pin 1, etc.
OK in V4L binding world it means DSI with six lanes :)
>
>>> };
>>> };
>>> };
>>>
>>> So the encoder would be places inside the SoC's DSI node, similar to how
>>> an i2c device would be placed inside SoC's i2c node. DSI configuration
>>> would be inside the video endpoint data.
>>>
>>> Version B would be almost the same:
>>>
>>> &i2c0 {
>>> encoder {
>>> input: endpoint {
>>> remote-endpoint = <&soc-dsi-ep>;
>> &soc-dsi-ep => &disp-ctrl-ep
>>> /* configuration for the DSI lanes */
>>> dsi-lanes = <0 1 2 3 4 5>;
>>> };
>>> };
>>> };
>>>
>>> Now, how would the video-bus-less device be defined?
>>> It'd be inside the
>>> soc-dsi node, that's clear. Where would the DSI lane configuration be?
>>> Not inside 'endpoint' node, as that's for video and wouldn't exist in
>>> this case. Would we have the same lane configuration in two places, once
>>> for video and once for control?
>> I think it is control setting, so it should be put outside endpoint node.
>> Probably it could be placed in encoder node.
> Well, one point of the endpoints is also to allow "switching" of video
> devices.
>
> For example, I could have a board with a SoC's DSI output, connected to
> two DSI panels. There would be some kind of mux between, so that I can
> select which of the panels is actually connected to the SoC.
>
> Here the first panel could use 2 datalanes, the second one 4. Thus, the
> DSI master would have two endpoints, the other one using 2 and the other
> 4 datalanes.
>
> If we decide that kind of support is not needed, well, is there even
> need for the V4L2 endpoints in the DT data at all?
Hmm, both panels connected to one endpoint of dispc ?
The problem I see is which driver should handle panel switching,
but this is question about hardware design as well. If this is realized
by dispc I have told already the solution. If this is realized by other
device I do not see a problem to create corresponding CDF entity,
or maybe it can be handled by "Pipeline Controller" ???
>
>>> I agree that having DSI/DBI control and video separated would be
>>> elegant. But I'd like to hear what is the technical benefit of that? At
>>> least to me it's clearly more complex to separate them than to keep them
>>> together (to the extent that I don't yet see how it is even possible),
>>> so there must be a good reason for the separation. I don't understand
>>> that reason. What is it?
>> Roughly speaking it is a question where is the more convenient place to
>> put bunch
>> of opses, technically both solutions can be somehow implemented.
> Well, it's also about dividing a single physical bus into two separate
> interfaces to it. It sounds to me that it would be much more complex
> with locking. With a single API, we can just say "the caller handles
> locking". With two separate interfaces, there must be locking at the
> lower level.
We say then: callee handles locking :)
>
>> Pros of mipi bus:
>> - no fake entity in CDF, with fake opses, I have to use similar entities
>> in MIPI-CSI
>> camera pipelines and it complicates life without any benefit(at least
>> from user side),
> You mean the DSI-master? I don't see how it's "fake", it's a video
> processing unit that has to be configured. Even if we forget the control
> side, and just think about plain video stream with DSI video mode,
> there's are things to configure with it.
>
> What kind of issues you have in the CSI side, then?
Not real issues, just needless calls to configure CSI entity pads,
with the same format and picture sizes as in camera.
>
>> - CDF models only video buses, control bus is a domain of Linux buses,
> Yes, but in this case the buses are the same. It makes me a bit nervous
> to have two separate ways (video and control) to use the same bus, in a
> case like video where timing is critical.
>
> So yes, we can consider video and control buses as "virtual" buses, and
> the actual transport is the DSI bus. Maybe it can be done. It just makes
> me a bit nervous =).
>
>> - less platform_bus abusing,
> Well, platform.txt says
>
> "This pseudo-bus
> is used to connect devices on busses with minimal infrastructure,
> like those used to integrate peripherals on many system-on-chip
> processors, or some "legacy" PC interconnects; as opposed to large
> formally specified ones like PCI or USB."
>
> I don't think DSI and DBI as platform bus is that far from the
> description. They are "simple", no probing point-to-point (in practice)
> buses. There's not much "bus" to speak of, just a point-to-point link.
Next section:
Platform devices
~~~~~~~~~~~~~~~~
Platform devices are devices that typically appear as autonomous
entities in the system. This includes legacy port-based devices and
host bridges to peripheral buses, and most controllers integrated
into system-on-chip platforms. What they usually have in common
is direct addressing from a CPU bus. Rarely, a platform_device will
be connected through a segment of some other kind of bus; but its
registers will still be directly addressable.
>> - better device tree topology (at least for common cases),
> Even if we use platform devices for DSI peripherals, we can have them
> described under the DSI master node.
Sorry, I meant rather Linux device tree topology, not DT.
>
>> - quite simple in case of typical devices.
> Still more complex than single API for both video and control =).
I agree.
Andrzej
> Tomi
>
>
^ permalink raw reply
* Re: [PATCH/RFC v3 00/19] Common Display Framework
From: Tomi Valkeinen @ 2013-10-11 14:45 UTC (permalink / raw)
To: Andrzej Hajda, Laurent Pinchart
Cc: linux-fbdev, dri-devel, Jesse Barnes, Benjamin Gaignard, Tom Gall,
Kyungmin Park, linux-media, Stephen Warren, Mark Zhang,
Alexandre Courbot, Ragesh Radhakrishnan, Thomas Petazzoni,
Sunil Joshi, Maxime Ripard, Vikas Sajjan, Marcus Lorentzon
In-Reply-To: <5258084A.9000509@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 6916 bytes --]
On 11/10/13 17:16, Andrzej Hajda wrote:
> Picture size, content and format is the same on input and on output of DSI.
> The same bits which enters DSI appears on the output. Internally bits
> order can
> be different but practically you are configuring DSI master and slave
> with the same format.
>
> If you create DSI entity you will have to always set the same format and
> size on DSI input, DSI output and encoder input.
> If you skip creating DSI entity you loose nothing, and you do not need
> to take care of it.
Well, this is really a different question from the bus problem. But
nothing says the DSI master cannot change the format or even size. For
sure it can change the video timings. The DSI master could even take two
parallel inputs, and combine them into one DSI output. You don't can't
what all the possible pieces of hardware do =).
If you have a bigger IP block that internally contains the DISPC and the
DSI, then, yes, you can combine them into one display entity. I don't
think that's correct, though. And if the DISPC and DSI are independent
blocks, then especially I think there must be an entity for the DSI
block, which will enable the powers, clocks, etc, when needed.
>> Well, one point of the endpoints is also to allow "switching" of video
>> devices.
>>
>> For example, I could have a board with a SoC's DSI output, connected to
>> two DSI panels. There would be some kind of mux between, so that I can
>> select which of the panels is actually connected to the SoC.
>>
>> Here the first panel could use 2 datalanes, the second one 4. Thus, the
>> DSI master would have two endpoints, the other one using 2 and the other
>> 4 datalanes.
>>
>> If we decide that kind of support is not needed, well, is there even
>> need for the V4L2 endpoints in the DT data at all?
> Hmm, both panels connected to one endpoint of dispc ?
> The problem I see is which driver should handle panel switching,
> but this is question about hardware design as well. If this is realized
> by dispc I have told already the solution. If this is realized by other
> device I do not see a problem to create corresponding CDF entity,
> or maybe it can be handled by "Pipeline Controller" ???
Well the switching could be automatic, when the panel power is enabled,
the DSI mux is switched for that panel. It's not relevant.
We still have two different endpoint configurations for the same
DSI-master port. If that configuration is in the DSI-master's port node,
not inside an endpoint data, then that can't be supported.
>>>> I agree that having DSI/DBI control and video separated would be
>>>> elegant. But I'd like to hear what is the technical benefit of that? At
>>>> least to me it's clearly more complex to separate them than to keep them
>>>> together (to the extent that I don't yet see how it is even possible),
>>>> so there must be a good reason for the separation. I don't understand
>>>> that reason. What is it?
>>> Roughly speaking it is a question where is the more convenient place to
>>> put bunch
>>> of opses, technically both solutions can be somehow implemented.
>> Well, it's also about dividing a single physical bus into two separate
>> interfaces to it. It sounds to me that it would be much more complex
>> with locking. With a single API, we can just say "the caller handles
>> locking". With two separate interfaces, there must be locking at the
>> lower level.
> We say then: callee handles locking :)
Sure, but my point was that the caller handling the locking is much
simpler than the callee handling locking. And the latter causes
atomicity issues, as the other API could be invoked in between two calls
for the first API.
But note that I'm not saying we should not implement bus model just
because it's more complex. We should go for bus model if it's better. I
just want to bring up these complexities, which I feel are quite more
difficult than with the simpler model.
>>> Pros of mipi bus:
>>> - no fake entity in CDF, with fake opses, I have to use similar entities
>>> in MIPI-CSI
>>> camera pipelines and it complicates life without any benefit(at least
>>> from user side),
>> You mean the DSI-master? I don't see how it's "fake", it's a video
>> processing unit that has to be configured. Even if we forget the control
>> side, and just think about plain video stream with DSI video mode,
>> there's are things to configure with it.
>>
>> What kind of issues you have in the CSI side, then?
> Not real issues, just needless calls to configure CSI entity pads,
> with the same format and picture sizes as in camera.
Well, the output of a component A is surely the same as the input of
component B, if B receives the data from A. So that does sound useless.
I don't do that kind of calls in my model.
>>> - CDF models only video buses, control bus is a domain of Linux buses,
>> Yes, but in this case the buses are the same. It makes me a bit nervous
>> to have two separate ways (video and control) to use the same bus, in a
>> case like video where timing is critical.
>>
>> So yes, we can consider video and control buses as "virtual" buses, and
>> the actual transport is the DSI bus. Maybe it can be done. It just makes
>> me a bit nervous =).
>>
>>> - less platform_bus abusing,
>> Well, platform.txt says
>>
>> "This pseudo-bus
>> is used to connect devices on busses with minimal infrastructure,
>> like those used to integrate peripherals on many system-on-chip
>> processors, or some "legacy" PC interconnects; as opposed to large
>> formally specified ones like PCI or USB."
>>
>> I don't think DSI and DBI as platform bus is that far from the
>> description. They are "simple", no probing point-to-point (in practice)
>> buses. There's not much "bus" to speak of, just a point-to-point link.
> Next section:
>
> Platform devices
> ~~~~~~~~~~~~~~~~
> Platform devices are devices that typically appear as autonomous
> entities in the system. This includes legacy port-based devices and
> host bridges to peripheral buses, and most controllers integrated
> into system-on-chip platforms. What they usually have in common
> is direct addressing from a CPU bus. Rarely, a platform_device will
> be connected through a segment of some other kind of bus; but its
> registers will still be directly addressable.
Yep, "typically" and "rarely" =). I agree, it's not clear. I think there
are things with DBI/DSI that clearly point to a platform device, but
also the other way.
>>> - better device tree topology (at least for common cases),
>> Even if we use platform devices for DSI peripherals, we can have them
>> described under the DSI master node.
> Sorry, I meant rather Linux device tree topology, not DT.
We can have the DSI peripheral platform devices as children of the
DSI-master device.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* [PATCH] do_register_framebuffer() fix potential deadlock
From: Alexei Starovoitov @ 2013-10-11 22:00 UTC (permalink / raw)
To: linux-fbdev
commit 50e244cc79
"fb: rework locking to fix lock ordering on takeover"
fixed the locking, but in one place the console_lock() and lock_fb_info()
seem to be in the wrong order vs the rest
to reproduce just boot and wait till blank
===========================
[ INFO: possible circular locking dependency detected ]
3.12.0-rc3+ #50 Not tainted
-------------------------------------------------------
kworker/0:0/4 is trying to acquire lock:
(&fb_info->lock){+.+.+.}, at: [<ffffffff813ec786>] lock_fb_info+0x26/0x60
but task is already holding lock:
(console_lock){+.+.+.}, at: [<ffffffff8146acf3>] console_callback+0x13/0x140
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (console_lock){+.+.+.}:
[<ffffffff810cf002>] lock_acquire+0x92/0x1d0
[<ffffffff810b3467>] console_lock+0x77/0x80
[<ffffffff813edc14>] register_framebuffer+0x1d4/0x320
[<ffffffff81403e4a>] vesafb_probe+0x5ba/0xa70
[<ffffffff814b7393>] platform_drv_probe+0x43/0x80
[<ffffffff814b52cb>] driver_probe_device+0x7b/0x220
[<ffffffff814b551b>] __driver_attach+0xab/0xb0
[<ffffffff814b32bd>] bus_for_each_dev+0x5d/0xa0
[<ffffffff814b4cde>] driver_attach+0x1e/0x20
[<ffffffff814b486f>] bus_add_driver+0x10f/0x2a0
[<ffffffff814b5be4>] driver_register+0x64/0xf0
[<ffffffff814b6b8a>] __platform_driver_register+0x4a/0x50
[<ffffffff81d5e863>] vesafb_driver_init+0x12/0x14
[<ffffffff8100031a>] do_one_initcall+0x11a/0x170
[<ffffffff81d21fed>] kernel_init_freeable+0x13e/0x1cd
[<ffffffff8174a49e>] kernel_init+0xe/0xf0
[<ffffffff8176c86c>] ret_from_fork+0x7c/0xb0
-> #0 (&fb_info->lock){+.+.+.}:
[<ffffffff810ce883>] __lock_acquire+0x1c63/0x1d50
[<ffffffff810cf002>] lock_acquire+0x92/0x1d0
[<ffffffff8175dc94>] mutex_lock_nested+0x74/0x380
[<ffffffff813ec786>] lock_fb_info+0x26/0x60
[<ffffffff813fb08b>] fbcon_blank+0x29b/0x2e0
[<ffffffff81468898>] do_blank_screen+0x1d8/0x280
[<ffffffff8146ad44>] console_callback+0x64/0x140
[<ffffffff81074b48>] process_one_work+0x1d8/0x6a0
[<ffffffff810754bb>] worker_thread+0x11b/0x370
[<ffffffff8107e36a>] kthread+0xea/0xf0
[<ffffffff8176c86c>] ret_from_fork+0x7c/0xb0
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(console_lock);
lock(&fb_info->lock);
lock(console_lock);
lock(&fb_info->lock);
*** DEADLOCK ***
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
---
drivers/video/fbmem.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index dacaf74..f12ab1c 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1660,12 +1660,14 @@ static int do_register_framebuffer(struct fb_info *fb_info)
registered_fb[i] = fb_info;
event.info = fb_info;
- if (!lock_fb_info(fb_info))
- return -ENODEV;
console_lock();
+ if (!lock_fb_info(fb_info)) {
+ console_unlock();
+ return -ENODEV;
+ }
fb_notifier_call_chain(FB_EVENT_FB_REGISTERED, &event);
- console_unlock();
unlock_fb_info(fb_info);
+ console_unlock();
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH] fbdev: fix error return code in metronomefb_probe()
From: Wei Yongjun @ 2013-10-12 6:25 UTC (permalink / raw)
To: linux-fbdev
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/video/metronomefb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/metronomefb.c b/drivers/video/metronomefb.c
index f30150d..0b36160 100644
--- a/drivers/video/metronomefb.c
+++ b/drivers/video/metronomefb.c
@@ -690,7 +690,8 @@ static int metronomefb_probe(struct platform_device *dev)
goto err_csum_table;
}
- if (board->setup_irq(info))
+ retval = board->setup_irq(info);
+ if (retval)
goto err_csum_table;
retval = metronome_init_regs(par);
^ permalink raw reply related
* Re: [PATCH 2/2] framebuffer: Remove pmag-aa-fb
From: Maciej W. Rozycki @ 2013-10-12 13:08 UTC (permalink / raw)
To: Joe Perches
Cc: Geert Uytterhoeven, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, Linux Fbdev development list,
linux-kernel@vger.kernel.org, Linux MIPS Mailing List
In-Reply-To: <alpine.LFD.2.03.1309201946430.8379@linux-mips.org>
Joe,
Just a quick update.
On Sun, 22 Sep 2013, Maciej W. Rozycki wrote:
> As to the PMAG-AA board itself -- well, this is indeed a very rare item,
> but I happen to have a specimen. To support it properly I'll first have
> to wire it to a monitor somehow though; signalling is standard, 1.0 Vpp
> composite monochrome, but what looks to me like a type F connector is used
> for video output, quite unusually for a graphics card (and for DEC itself
> too as 3W3 was their usual video socket). It looks to me like converting
> it to BNC and then a standard DE-15 VGA connector (via the green line)
> will be the easiest way to get image produced by the adapter on a
> contemporary monitor (sync-on-green required of course, but with LCD
> devices being the norm now that seems less of a problem these days).
So more weirdly even that's actually a TNC connector rather than a type F
one. I've got a suitable TNC->BNC adapter now (although regrettably such
adapters seem to be available as 50Ù parts only; hopefully any distortion
won't be too significant or maybe my digital monitor will even be able to
compensate it, but at £1.76 (~$2.64) per item it's certainly worth trying
before resorting to the original DEC TNC->BNC cable still apparently
available from second-hand part suppliers at ~£80/$120 per a mere 1ft
part) and a BNC->DE-15 cable is on the way.
> > --- a/drivers/video/pmag-aa-fb.c
> > +++ b/drivers/video/pmag-aa-fb.c
> > @@ -459,7 +459,7 @@ static int __init init_one(int slot)
> > return -EINVAL;
> >
> > printk(KERN_INFO "fb%d: %s frame buffer in TC slot %d\n",
> > - GET_FB_IDX(ip->info.node), ip->info.modename, slot);
> > + ip->info.node, ip->info.modename, slot);
> >
> > return 0;
> > }
>
> Thanks, but the changes required are actually much more than that -- the
> driver has never been converted to the modern TURBOchannel API. I have
> now dug out an old patch I was working on back in 2006 to convert this
> driver as well as drivers/video/maxinefb.c. I'll try to complete the two
> drivers as soon as possible (unfortunately I can't test the latter at all;
> it's for an onboard graphics adapter of another DECstation model),
> although I now remember the main reason I didn't complete them back then
> was they used an old internal API that was removed and no suitable
> replacement provided. I need to investigate again what that actually was
> though (hw cursor probably).
So I think I've got all the basic stuff covered now, including a change
similar to your proposal as well as a conversion to the driver model/new
TURBOchannel support infrastructure. But what I remembered is actually
right, the issue is wiring hardware cursor support into fbcon. The driver
uses its own display_switch structure with its own aafbcon_cursor handler
to use the twin onboard Bt431 chips for cursor generation (there's also
aafbcon_set_font that pokes at the Bt431s for cursor dimension changes).
I need to figure out what the best way will be to make the fbcon subsystem
support such an arrangement and that'll take me a little bit yet, so
please be patient.
Note that the board is weird enough to have a 1-bit (true monochrome)
graphics plane, however the Bt455 used by the MX graphics adapter for
screen image generation is a 4-bit grey-scale video RAMDAC (only the LSB
inputs of its pixel port are wired to the graphics plane) and the twin
Bt431s use the overlay plane to produce a 2-bit grey-scale cursor. So we
do want to use the hardware cursor to be able to make it prominent among
the characters displayed throughout the screen and a software-generated
cursor cannot really substitute what hardware provides.
Maciej
^ permalink raw reply
* Re: [PATCH 2/2] framebuffer: Remove pmag-aa-fb
From: Joe Perches @ 2013-10-12 16:08 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Geert Uytterhoeven, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, Linux Fbdev development list,
linux-kernel@vger.kernel.org, Linux MIPS Mailing List
In-Reply-To: <alpine.LFD.2.03.1310121308310.10951@linux-mips.org>
On Sat, 2013-10-12 at 14:08 +0100, Maciej W. Rozycki wrote:
[]
> So I think I've got all the basic stuff covered now, including a change
> similar to your proposal as well as a conversion to the driver model/new
> TURBOchannel support infrastructure. But what I remembered is actually
> right, the issue is wiring hardware cursor support into fbcon. The driver
> uses its own display_switch structure with its own aafbcon_cursor handler
> to use the twin onboard Bt431 chips for cursor generation (there's also
> aafbcon_set_font that pokes at the Bt431s for cursor dimension changes).
> I need to figure out what the best way will be to make the fbcon subsystem
> support such an arrangement and that'll take me a little bit yet, so
> please be patient.
>
> Note that the board is weird enough to have a 1-bit (true monochrome)
> graphics plane, however the Bt455 used by the MX graphics adapter for
> screen image generation is a 4-bit grey-scale video RAMDAC (only the LSB
> inputs of its pixel port are wired to the graphics plane) and the twin
> Bt431s use the overlay plane to produce a 2-bit grey-scale cursor. So we
> do want to use the hardware cursor to be able to make it prominent among
> the characters displayed throughout the screen and a software-generated
> cursor cannot really substitute what hardware provides.
I hope you're enjoying tinkering with old toys.
Best of luck getting it going.
^ permalink raw reply
* Re: [PATCH 1/2] framebuffer: Add fb_<level> convenience logging macros
From: Joe Perches @ 2013-10-13 17:39 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard
Cc: Tomi Valkeinen, linux-fbdev, linux-kernel
In-Reply-To: <0926c7a34ac51c4cbb67debd0d883f41891e75d9.1379640011.git.joe@perches.com>
On Thu, 2013-09-19 at 18:35 -0700, Joe Perches wrote:
> Add fb_<level> convenience macros for emitting the
> "fb%d: ", struct fb_info->node value.
>
> Neatens and shortens the code a bit.
ping?
^ permalink raw reply
* Re: [PATCH 2/2] framebuffer: Use fb_<level>
From: Joe Perches @ 2013-10-13 17:39 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard
Cc: Tomi Valkeinen, linux-fbdev, linux-kernel
In-Reply-To: <8e7d2ced3f358961988c2602b8d1dff673f569c0.1379640011.git.joe@perches.com>
On Thu, 2013-09-19 at 18:35 -0700, Joe Perches wrote:
> Neaten and shorten the code using the new fb_<level> macros.
[]
> 59 files changed, 186 insertions(+), 224 deletions(-)
ping?
^ permalink raw reply
* [PATCH] set data enable logic level to low
From: Roel Kluin @ 2013-10-13 22:44 UTC (permalink / raw)
To: Tomi Valkeinen, Jean-Christophe Plagniol-Villard, linux-omap,
linux-fbdev, linux-kernel
Cc: Roel Kluin
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
drivers/video/omap2/dss/display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/display.c b/drivers/video/omap2/dss/display.c
index fafe7c9..669a81f 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -266,7 +266,7 @@ void videomode_to_omap_video_timings(const struct videomode *vm,
OMAPDSS_SIG_ACTIVE_LOW;
ovt->de_level = vm->flags & DISPLAY_FLAGS_DE_HIGH ?
OMAPDSS_SIG_ACTIVE_HIGH :
- OMAPDSS_SIG_ACTIVE_HIGH;
+ OMAPDSS_SIG_ACTIVE_LOW;
ovt->data_pclk_edge = vm->flags & DISPLAY_FLAGS_PIXDATA_POSEDGE ?
OMAPDSS_DRIVE_SIG_RISING_EDGE :
OMAPDSS_DRIVE_SIG_FALLING_EDGE;
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH] do_register_framebuffer() fix potential deadlock
From: Tomi Valkeinen @ 2013-10-14 6:22 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1381528835-3351-1-git-send-email-ast@plumgrid.com>
[-- Attachment #1: Type: text/plain, Size: 561 bytes --]
Hi,
On 12/10/13 01:00, Alexei Starovoitov wrote:
> commit 50e244cc79
> "fb: rework locking to fix lock ordering on takeover"
>
> fixed the locking, but in one place the console_lock() and lock_fb_info()
> seem to be in the wrong order vs the rest
The order seems to be lock_fb_info(), console_lock() everywhere. Your
change makes it the other way in one function, so I don't understand how
that could be a correct fix...
I wonder if you're seeing the same issue as John Tapsell in "fbcon: fix
deadlock in fbcon_generic_blank()"?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* [PATCH 0/3] omapdss: venc: Add support for bypass and acbias.
From: Marek Belisko @ 2013-10-14 21:02 UTC (permalink / raw)
To: linux-arm-kernel
This patches is adding bypass and acbias functionality to omapdss venc driver.
In first patch we export updatin bypass and acbias in devconf1 register. Next patch
add handling for updating in venc driver and last patch add driver for opa362 which
is used on gta04 board and set bypass + acbias.
Marek Belisko (3):
arm: omap2: Export devconf1 bypass and acbias.
video: venc: Add new callback and handling for bypass and acbias
setup.
omapdss: Add OPA362 analog video amplifier driver.
arch/arm/mach-omap2/Makefile | 2 +
arch/arm/mach-omap2/control.h | 2 +
arch/arm/mach-omap2/omap3-tvout.c | 36 +++
drivers/video/omap2/displays-new/Kconfig | 6 +
drivers/video/omap2/displays-new/Makefile | 1 +
.../video/omap2/displays-new/amplifier-opa362.c | 294 +++++++++++++++++++++
drivers/video/omap2/dss/venc.c | 21 ++
include/linux/omap-tvout.h | 14 +
include/video/omap-panel-data.h | 17 ++
include/video/omapdss.h | 2 +
10 files changed, 395 insertions(+)
create mode 100644 arch/arm/mach-omap2/omap3-tvout.c
create mode 100644 drivers/video/omap2/displays-new/amplifier-opa362.c
create mode 100644 include/linux/omap-tvout.h
--
1.8.1.2
^ permalink raw reply
* [PATCH 1/3] arm: omap2: Export devconf1 bypass and acbias.
From: Marek Belisko @ 2013-10-14 21:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1381784555-18344-1-git-send-email-marek@goldelico.com>
devconf1 reg access is localized only in mach-omap2 and we need to export
updating of devconf1 from omapdss venc driver (bypass and acbias bits).
Add simple api call which update only necessary bits.
Signed-off-by: Marek Belisko <marek@goldelico.com>
---
arch/arm/mach-omap2/Makefile | 2 ++
arch/arm/mach-omap2/control.h | 2 ++
arch/arm/mach-omap2/omap3-tvout.c | 36 ++++++++++++++++++++++++++++++++++++
include/linux/omap-tvout.h | 14 ++++++++++++++
4 files changed, 54 insertions(+)
create mode 100644 arch/arm/mach-omap2/omap3-tvout.c
create mode 100644 include/linux/omap-tvout.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index afb457c..15e0f28 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -306,3 +306,5 @@ emac-$(CONFIG_TI_DAVINCI_EMAC) := am35xx-emac.o
obj-y += $(emac-m) $(emac-y)
obj-y += common-board-devices.o twl-common.o dss-common.o
+
+obj-$(CONFIG_ARCH_OMAP3) += omap3-tvout.o
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index f7d7c2e..65277f1 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -279,6 +279,8 @@
/* CONTROL_DEVCONF1 bits */
#define OMAP243X_MMC1_ACTIVE_OVERWRITE (1 << 31)
+#define OMAP2_TVOUTBYPASS (1 << 18)
+#define OMAP2_TVACEN (1 << 11)
#define OMAP2_MMCSDIO2ADPCLKISEL (1 << 6) /* MMC2 loop back clock */
#define OMAP2_MCBSP5_CLKS_MASK (1 << 4) /* > 242x */
#define OMAP2_MCBSP4_CLKS_MASK (1 << 2) /* > 242x */
diff --git a/arch/arm/mach-omap2/omap3-tvout.c b/arch/arm/mach-omap2/omap3-tvout.c
new file mode 100644
index 0000000..eaed225
--- /dev/null
+++ b/arch/arm/mach-omap2/omap3-tvout.c
@@ -0,0 +1,36 @@
+/*
+ * linux/arch/arm/mach-omap2/omap3-tvout.c
+ *
+ * Copyright (C) 2013 Golden Delicious Computers
+ * Author: Marek Belisko <marek@goldelico.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/kernel.h>
+#include <linux/omap-tvout.h>
+
+#include "soc.h"
+#include "control.h"
+
+void update_bypass_acbias(bool bypass, bool acbias)
+{
+#ifdef CONFIG_ARCH_OMAP3
+ int val = omap_ctrl_readl(OMAP343X_CONTROL_DEVCONF1);
+
+ if (bypass)
+ val |= OMAP2_TVOUTBYPASS;
+ else
+ val &= ~OMAP2_TVOUTBYPASS;
+
+ if (acbias)
+ val |= OMAP2_TVACEN;
+ else
+ val &= ~OMAP2_TVACEN;
+
+ omap_ctrl_writel(val, OMAP343X_CONTROL_DEVCONF1);
+#endif
+}
+
diff --git a/include/linux/omap-tvout.h b/include/linux/omap-tvout.h
new file mode 100644
index 0000000..25f676d
--- /dev/null
+++ b/include/linux/omap-tvout.h
@@ -0,0 +1,14 @@
+/*
+ * OMAP TV-out support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __LINUX_OMAP_TVOUT_H
+#define __LINUX_OMAP_TVOUT_H
+
+extern void update_bypass_acbias(bool bypass, bool acbias);
+
+#endif
+
--
1.8.1.2
^ permalink raw reply related
* [PATCH 2/3] video: venc: Add new callback and handling for bypass and acbias setup.
From: Marek Belisko @ 2013-10-14 21:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1381784555-18344-1-git-send-email-marek@goldelico.com>
Add new callback to set bypass and acbias. During venc enble disable those
bit are updated in devconf1 register.
Signed-off-by: Marek Belisko <marek@goldelico.com>
---
drivers/video/omap2/dss/venc.c | 21 +++++++++++++++++++++
include/video/omapdss.h | 2 ++
2 files changed, 23 insertions(+)
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 5f88ac4..17bd45b 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -34,6 +34,7 @@
#include <linux/platform_device.h>
#include <linux/regulator/consumer.h>
#include <linux/pm_runtime.h>
+#include <linux/omap-tvout.h>
#include <video/omapdss.h>
@@ -303,6 +304,8 @@ static struct {
struct omap_video_timings timings;
enum omap_dss_venc_type type;
bool invert_polarity;
+ bool bypass;
+ bool acbias;
struct omap_dss_device output;
} venc;
@@ -455,6 +458,9 @@ static int venc_power_on(struct omap_dss_device *dssdev)
venc_write_reg(VENC_OUTPUT_CONTROL, l);
+ /* apply bypass and acbias */
+ update_bypass_acbias(venc.bypass, venc.acbias);
+
dss_mgr_set_timings(mgr, &venc.timings);
r = regulator_enable(venc.vdda_dac_reg);
@@ -485,6 +491,9 @@ static void venc_power_off(struct omap_dss_device *dssdev)
venc_write_reg(VENC_OUTPUT_CONTROL, 0);
dss_set_dac_pwrdn_bgz(0);
+ /* clear bypass and acbias */
+ update_bypass_acbias(false, false);
+
dss_mgr_disable(mgr);
regulator_disable(venc.vdda_dac_reg);
@@ -629,6 +638,17 @@ static void venc_invert_vid_out_polarity(struct omap_dss_device *dssdev,
mutex_unlock(&venc.venc_lock);
}
+static void venc_bypass_and_acbias(struct omap_dss_device *dssdev,
+ bool bypass, bool acbias)
+{
+ mutex_lock(&venc.venc_lock);
+
+ venc.bypass = bypass;
+ venc.acbias = acbias;
+
+ mutex_unlock(&venc.venc_lock);
+}
+
static int venc_init_regulator(void)
{
struct regulator *vdda_dac;
@@ -777,6 +797,7 @@ static const struct omapdss_atv_ops venc_ops = {
.set_type = venc_set_type,
.invert_vid_out_polarity = venc_invert_vid_out_polarity,
+ .bypass_and_acbias = venc_bypass_and_acbias,
.set_wss = venc_set_wss,
.get_wss = venc_get_wss,
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 3d7c51a..54a185f 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -607,6 +607,8 @@ struct omapdss_atv_ops {
enum omap_dss_venc_type type);
void (*invert_vid_out_polarity)(struct omap_dss_device *dssdev,
bool invert_polarity);
+ void (*bypass_and_acbias)(struct omap_dss_device *dssdev,
+ bool bypass, bool acbias);
int (*set_wss)(struct omap_dss_device *dssdev, u32 wss);
u32 (*get_wss)(struct omap_dss_device *dssdev);
--
1.8.1.2
^ permalink raw reply related
* [PATCH 3/3] omapdss: Add OPA362 analog video amplifier driver.
From: Marek Belisko @ 2013-10-14 21:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1381784555-18344-1-git-send-email-marek@goldelico.com>
This driver add handlign for opa362 chip which is
video amplifier with internal gain and filter. Enable/disable is
controlled via single gpio. This driver was tested on gta04 board.
Signed-off-by: Marek Belisko <marek@goldelico.com>
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
drivers/video/omap2/displays-new/Kconfig | 6 +
drivers/video/omap2/displays-new/Makefile | 1 +
.../video/omap2/displays-new/amplifier-opa362.c | 294 +++++++++++++++++++++
include/video/omap-panel-data.h | 17 ++
4 files changed, 318 insertions(+)
create mode 100644 drivers/video/omap2/displays-new/amplifier-opa362.c
diff --git a/drivers/video/omap2/displays-new/Kconfig b/drivers/video/omap2/displays-new/Kconfig
index 6c90885..5097640 100644
--- a/drivers/video/omap2/displays-new/Kconfig
+++ b/drivers/video/omap2/displays-new/Kconfig
@@ -1,6 +1,12 @@
menu "OMAP Display Device Drivers (new device model)"
depends on OMAP2_DSS
+config DISPLAY_AMPLIFIER_OPA362
+ tristate "Analog amplifier with output disable/high-Z"
+ help
+ Driver to enable an external analog TV amplifier (e.g. OPA362)
+ through a GPIO.
+
config DISPLAY_ENCODER_TFP410
tristate "TFP410 DPI to DVI Encoder"
help
diff --git a/drivers/video/omap2/displays-new/Makefile b/drivers/video/omap2/displays-new/Makefile
index 5aeb11b..2e8af8f 100644
--- a/drivers/video/omap2/displays-new/Makefile
+++ b/drivers/video/omap2/displays-new/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_DISPLAY_AMPLIFIER_OPA362) += amplifier-opa362.o
obj-$(CONFIG_DISPLAY_ENCODER_TFP410) += encoder-tfp410.o
obj-$(CONFIG_DISPLAY_ENCODER_TPD12S015) += encoder-tpd12s015.o
obj-$(CONFIG_DISPLAY_CONNECTOR_DVI) += connector-dvi.o
diff --git a/drivers/video/omap2/displays-new/amplifier-opa362.c b/drivers/video/omap2/displays-new/amplifier-opa362.c
new file mode 100644
index 0000000..677499c
--- /dev/null
+++ b/drivers/video/omap2/displays-new/amplifier-opa362.c
@@ -0,0 +1,294 @@
+/*
+ * OPA362 analog video amplifier with output/power control
+ *
+ * Copyright (C) 2013 Golden Delicious Computers
+ * Author: H. Nikolaus Schaller <hns@goldelico.com>
+ *
+ * based on encoder-tfp410
+ *
+ * Copyright (C) 2013 Texas Instruments
+ * Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include <linux/gpio.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#include <video/omapdss.h>
+#include <video/omap-panel-data.h>
+
+struct panel_drv_data {
+ struct omap_dss_device dssdev;
+ struct omap_dss_device *in;
+
+ int enable_gpio;
+ bool bypass;
+ bool acbias;
+
+ struct omap_video_timings timings;
+};
+
+#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
+
+static int opa362_connect(struct omap_dss_device *dssdev,
+ struct omap_dss_device *dst)
+{
+ struct panel_drv_data *ddata = to_panel_data(dssdev);
+ struct omap_dss_device *in = ddata->in;
+ int r;
+
+ if (omapdss_device_is_connected(dssdev))
+ return -EBUSY;
+
+ r = in->ops.atv->connect(in, dssdev);
+ if (r)
+ return r;
+
+ dst->src = dssdev;
+ dssdev->dst = dst;
+
+ return 0;
+}
+
+static void opa362_disconnect(struct omap_dss_device *dssdev,
+ struct omap_dss_device *dst)
+{
+ struct panel_drv_data *ddata = to_panel_data(dssdev);
+ struct omap_dss_device *in = ddata->in;
+
+ WARN_ON(!omapdss_device_is_connected(dssdev));
+ if (!omapdss_device_is_connected(dssdev))
+ return;
+
+ WARN_ON(dst != dssdev->dst);
+ if (dst != dssdev->dst)
+ return;
+
+ dst->src = NULL;
+ dssdev->dst = NULL;
+
+ in->ops.atv->disconnect(in, &ddata->dssdev);
+}
+
+static int opa362_enable(struct omap_dss_device *dssdev)
+{
+ struct panel_drv_data *ddata = to_panel_data(dssdev);
+ struct omap_dss_device *in = ddata->in;
+ int r;
+
+ if (!omapdss_device_is_connected(dssdev))
+ return -ENODEV;
+
+ if (omapdss_device_is_enabled(dssdev))
+ return 0;
+
+ in->ops.atv->set_timings(in, &ddata->timings);
+ in->ops.atv->invert_vid_out_polarity(in, true);
+ in->ops.atv->bypass_and_acbias(in, ddata->bypass, ddata->acbias);
+
+ r = in->ops.atv->enable(in);
+ if (r)
+ return r;
+
+ if (gpio_is_valid(ddata->enable_gpio))
+ gpio_set_value_cansleep(ddata->enable_gpio, 1);
+
+ dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
+
+ return 0;
+}
+
+static void opa362_disable(struct omap_dss_device *dssdev)
+{
+ struct panel_drv_data *ddata = to_panel_data(dssdev);
+ struct omap_dss_device *in = ddata->in;
+
+ if (!omapdss_device_is_enabled(dssdev))
+ return;
+
+ if (gpio_is_valid(ddata->enable_gpio))
+ gpio_set_value_cansleep(ddata->enable_gpio, 0);
+
+ in->ops.atv->disable(in);
+
+ dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
+}
+
+static void opa362_set_timings(struct omap_dss_device *dssdev,
+ struct omap_video_timings *timings)
+{
+ struct panel_drv_data *ddata = to_panel_data(dssdev);
+ struct omap_dss_device *in = ddata->in;
+
+ ddata->timings = *timings;
+ dssdev->panel.timings = *timings;
+
+ in->ops.atv->set_timings(in, timings);
+}
+
+static void opa362_get_timings(struct omap_dss_device *dssdev,
+ struct omap_video_timings *timings)
+{
+ struct panel_drv_data *ddata = to_panel_data(dssdev);
+
+ *timings = ddata->timings;
+}
+
+static int opa362_check_timings(struct omap_dss_device *dssdev,
+ struct omap_video_timings *timings)
+{
+ struct panel_drv_data *ddata = to_panel_data(dssdev);
+ struct omap_dss_device *in = ddata->in;
+
+ return in->ops.atv->check_timings(in, timings);
+}
+
+static void opa362_set_type(struct omap_dss_device *dssdev,
+ enum omap_dss_venc_type type)
+{
+ /* we can only drive a COMPOSITE output */
+ WARN_ON(type != OMAP_DSS_VENC_TYPE_COMPOSITE);
+
+}
+
+static void opa362_invert_vid_out_polarity(struct omap_dss_device *dssdev,
+ bool invert_polarity)
+{
+ struct panel_drv_data *ddata = to_panel_data(dssdev);
+ struct omap_dss_device *in = ddata->in;
+
+ /* OPA362 inverts the polarity */
+ in->ops.atv->invert_vid_out_polarity(in, !invert_polarity);
+}
+
+static const struct omapdss_atv_ops opa362_atv_ops = {
+ .connect = opa362_connect,
+ .disconnect = opa362_disconnect,
+
+ .enable = opa362_enable,
+ .disable = opa362_disable,
+
+ .check_timings = opa362_check_timings,
+ .set_timings = opa362_set_timings,
+ .get_timings = opa362_get_timings,
+
+ .set_type = opa362_set_type,
+ .invert_vid_out_polarity = opa362_invert_vid_out_polarity,
+};
+
+static int opa362_probe_pdata(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct amplifier_opa362_platform_data *pdata;
+ struct omap_dss_device *dssdev, *in;
+
+ pdata = dev_get_platdata(&pdev->dev);
+
+ ddata->enable_gpio = pdata->enable_gpio;
+ ddata->bypass = pdata->bypass;
+ ddata->acbias = pdata->acbias;
+
+ in = omap_dss_find_output(pdata->source);
+ if (in = NULL) {
+ dev_err(&pdev->dev, "Failed to find video source\n");
+ return -ENODEV;
+ }
+
+ ddata->in = in;
+
+ dssdev = &ddata->dssdev;
+ dssdev->name = pdata->name;
+
+ return 0;
+}
+
+static int opa362_probe(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata;
+ struct omap_dss_device *dssdev;
+ int r;
+
+ ddata = devm_kzalloc(&pdev->dev, sizeof(*ddata), GFP_KERNEL);
+ if (!ddata)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, ddata);
+
+ if (dev_get_platdata(&pdev->dev)) {
+ r = opa362_probe_pdata(pdev);
+ if (r)
+ return r;
+ } else {
+ return -ENODEV;
+ }
+
+ if (gpio_is_valid(ddata->enable_gpio)) {
+ r = devm_gpio_request_one(&pdev->dev, ddata->enable_gpio,
+ GPIOF_OUT_INIT_LOW, "opa362 enable");
+ if (r) {
+ dev_err(&pdev->dev, "Failed to request enable GPIO %d\n",
+ ddata->enable_gpio);
+ goto err_gpio;
+ }
+ }
+
+ dssdev = &ddata->dssdev;
+ dssdev->ops.atv = &opa362_atv_ops;
+ dssdev->dev = &pdev->dev;
+ dssdev->type = OMAP_DISPLAY_TYPE_VENC;
+ dssdev->output_type = OMAP_DISPLAY_TYPE_VENC;
+ dssdev->owner = THIS_MODULE;
+
+ r = omapdss_register_output(dssdev);
+ if (r) {
+ dev_err(&pdev->dev, "Failed to register output\n");
+ goto err_reg;
+ }
+
+ return 0;
+err_reg:
+err_gpio:
+ omap_dss_put_device(ddata->in);
+ return r;
+}
+
+static int __exit opa362_remove(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct omap_dss_device *dssdev = &ddata->dssdev;
+ struct omap_dss_device *in = ddata->in;
+
+ omapdss_unregister_output(&ddata->dssdev);
+
+ WARN_ON(omapdss_device_is_enabled(dssdev));
+ if (omapdss_device_is_enabled(dssdev))
+ opa362_disable(dssdev);
+
+ WARN_ON(omapdss_device_is_connected(dssdev));
+ if (omapdss_device_is_connected(dssdev))
+ opa362_disconnect(dssdev, dssdev->dst);
+
+ omap_dss_put_device(in);
+
+ return 0;
+}
+
+static struct platform_driver opa362_driver = {
+ .probe = opa362_probe,
+ .remove = __exit_p(opa362_remove),
+ .driver = {
+ .name = "amplifier-opa362",
+ .owner = THIS_MODULE,
+ },
+};
+
+module_platform_driver(opa362_driver);
+
+MODULE_AUTHOR("H. Nikolaus Schaller <hns@goldelico.com>");
+MODULE_DESCRIPTION("OPA362 analog video amplifier with output/power control");
+MODULE_LICENSE("GPL");
diff --git a/include/video/omap-panel-data.h b/include/video/omap-panel-data.h
index f7ac8d9..e1b3c13 100644
--- a/include/video/omap-panel-data.h
+++ b/include/video/omap-panel-data.h
@@ -33,6 +33,23 @@
struct omap_dss_device;
/**
+ * amplifier_opa362_platform_data platform data
+ * @name: name for this display entity
+ * @source: name of the display entity used as a video source
+ * @enable_gpio: gpio number for enable pin (or -1 if not available - but
+ * then you don't need this driver)
+ * @bypass: enable TV bypass mode for external video driver
+ * @acbias: AC coupling to remove DC offset
+ */
+struct amplifier_opa362_platform_data {
+ const char *name;
+ const char *source;
+ int enable_gpio;
+ bool bypass;
+ bool acbias;
+};
+
+/**
* encoder_tfp410 platform data
* @name: name for this display entity
* @power_down_gpio: gpio number for PD pin (or -1 if not available)
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH] do_register_framebuffer() fix potential deadlock
From: Alexei Starovoitov @ 2013-10-14 21:35 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1381528835-3351-1-git-send-email-ast@plumgrid.com>
On Sun, Oct 13, 2013 at 11:22 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Hi,
>
> On 12/10/13 01:00, Alexei Starovoitov wrote:
>> commit 50e244cc79
>> "fb: rework locking to fix lock ordering on takeover"
>>
>> fixed the locking, but in one place the console_lock() and lock_fb_info()
>> seem to be in the wrong order vs the rest
>
> The order seems to be lock_fb_info(), console_lock() everywhere. Your
> change makes it the other way in one function, so I don't understand how
> that could be a correct fix...
>
> I wonder if you're seeing the same issue as John Tapsell in "fbcon: fix
> deadlock in fbcon_generic_blank()"?
yes. It is the same issue.
console_callback() grabs the console_lock and eventually calls fbcon_blank().
So yes both mine and John's approach needs more work.
I guess it's too painful to change lock_fb_info/console_lock order
through out fb code...
Have to live with workaround for now...
^ permalink raw reply
* FOSDEM14: Graphics DevRoom: call for speakers.
From: Luc Verhaegen @ 2013-10-15 15:42 UTC (permalink / raw)
To: mesa-dev, xorg-devel, dri-devel, xorg, wayland-devel,
xorg-announce, mir-devel, directfb-dev, linux-fbdev, linux-media
Hi,
At FOSDEM on the 1st and 2nd of February 2014, there will be a graphics
DevRoom. URL https://fosdem.org/2014/
The focus of this DevRoom is the same as the X.org DevRooms of yore;
anything to do with graphics on open source software goes.
This includes:
* Graphics drivers: from display to media to 3d drivers, both in kernel
or userspace. Be it part of DRM, KMS, (direct)FB, V4L, Xorg, Mesa...
* Input drivers: kernel and userspace.
* Windowing systems: X, Wayland, Mir, directFB, ...
* Even colour management and other areas which i might have overlooked
above are accepted.
Slots are 1 hour long. This partly to avoid confusion and people running
all over the place all the time. As a speaker, you do not have to fill
your whole hour, smallish gaps are never wasted time.
Slots will be handed out on a first come, first serve basis. The best
slots will go to those who apply the soonest. The amount of slots is
currently not known yet, but i expect there to be around 16 available (8
on each day), so act quickly.
Talk Submission:
----------------
New this year is that speakers are expected to submit proposals to the
FOSDEM organizers scheduling system directly (pentabarf). This reduces
overhead for all involved (especially me - but this directive came from
the FOSDEM team), but holds a few caveats.
The biggest advantage is that you will be able to adjust your own
information and your talk information directly. And you can therefor
yourself make sure that the information is correct and complete, and you
can even make it match the structure of the FOSDEM website. This is a
vast improvement over the freeform emails i used to get, which i then
had to form up (somewhat) nicely. This does mean that i will end up
having to chase people more...
Remember that FOSDEM is not like XDC, it's not some 50 odd people
meeting with a sliding schedule which only gets filled in on the last
day. Upwards of 7000 people are visiting this event, and most of them
get a printed booklet or use the schedule on the FOSDEM website or an
app for their phone to figure out what to watch or participate in next.
So please put some effort in your talk submission and details.
As for deadlines, i hope to have a pretty much complete schedule between
christmas and the new year. The rockhard printed schedule deadline is
probably January 10th, after that you will not be featured in the
booklet and you will have a lot less visitors. I will find out to what
extent i will be able to lock down entries and descriptions during those
final days. Don't count on this deadline though. First come first serve,
and there are perhaps only 16 slots.
Submission Caveat #1:
---------------------
The first caveat is that all speakers who spoke at FOSDEM from 2011 on
should not simply create an account. If you have talked recently you
should come to me first, so i can get your details up to date, and so
that i can poke the pentabarf admin to create you an account linked to
the previous speaker entry. This saves me and the fosdem people
overhead, and will allow you to recycle your previous data.
The known speakers are:
Connor Abbott (*)
Eric Anholt
Marc Balmer
Jesse Barnes
Kai-Uwe Behrmann
Donnie Berkholz
Rob Bradford
Robert Bragg
Rob Clark
Ander Conselvan de Oliviera
Michael Hasselman
Matthieu Herrb
David Herrmann
Kristian Høgsberg
Peter Hutterer
Francisco Jerez
Sirko Kemter
Alon Levy
Chris Lilley
Peter Linnell
Keith Packard
Martin Peres
Timothée Ravier
Neil Roberts
Ian Romanick
Lucas Stach
Daniel Stone
Ville Syrjala
Daniel Vetter (*)
Chris Wilson
(*) Since Daniel Vetter and Connor Abbott are known speakers for 2014
already, they will be contacted soon with account details. They have the
questionable honour of being the guinea pigs :)
If you are not on the above list, then you can just start at:
https://penta.fosdem.org/submission/FOSDEM14
If you are on the above list, then you need to email me or poke me
(libv) on freenode.
Submission Caveat #2:
---------------------
The second caveat is what i need to see filled in when you apply for a
devroom before i consider it a valid submission. Remember: first come,
first serve. The best slots are for the earliest submissions and there
are only around 16 slots.
On your personal page:
* General:
* First and last name
* Nickname
* Image
* Contact:
* email
* mobile number (this is a very hard requirement as there will be no
other reliable form of emergency communication on the day)
* Description:
* Abstract
* Description
Create an event:
* On the General page:
* Event title
* Event subtitle.
* Track: Graphics Devroom
* Event type: Lecture (talk) or Meeting (BoF)
* Persons:
* Add yourself as speaker.
* Description:
* Abstract:
* Full Description
* Links:
* Add relevant links.
Everything else can be ignored or will be filled in by me or the FOSDEM
organizers.
That's about it. Hope to see you all at FOSDEM :)
Luc Verhaegen.
^ permalink raw reply
* [PATCH 0/7] video phy's adaptation to *generic phy framework*
From: Kishon Vijay Abraham I @ 2013-10-16 16:40 UTC (permalink / raw)
To: linux-arm-kernel
Hi Greg,
This series includes video PHY adaptation to Generic PHY Framework.
With the adaptation they were able to get rid of plat data callbacks.
Since you've taken the Generic PHY Framework, I think this series should
also go into your tree.
We should thank Sylwester for actively testing and giving comments from
the initial versions of Generic Phy Framework. Both Sylwester and Jingoo
had been floating many revisions of their adaptation to Generic PHY
Framework.
This has been in my repo for quite some time and has got acks from
samsung maintainer and video maintainer.
If you want me to change anything, please let me know.
This patch series can be found @
git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git testing
Jingoo Han (3):
phy: Add driver for Exynos DP PHY
video: exynos_dp: remove non-DT support for Exynos Display Port
video: exynos_dp: Use the generic PHY driver
Sylwester Nawrocki (4):
phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
exynos4-is: Use the generic MIPI CSIS PHY driver
video: exynos_mipi_dsim: Use the generic PHY driver
ARM: Samsung: Remove the MIPI PHY setup code
.../devicetree/bindings/phy/samsung-phy.txt | 22 +++
.../devicetree/bindings/video/exynos_dp.txt | 17 +-
arch/arm/mach-exynos/include/mach/regs-pmu.h | 5 -
arch/arm/mach-s5pv210/include/mach/regs-clock.h | 4 -
arch/arm/plat-samsung/Kconfig | 5 -
arch/arm/plat-samsung/Makefile | 1 -
arch/arm/plat-samsung/setup-mipiphy.c | 60 -------
drivers/media/platform/exynos4-is/Kconfig | 2 +-
drivers/media/platform/exynos4-is/mipi-csis.c | 13 +-
drivers/phy/Kconfig | 13 ++
drivers/phy/Makefile | 8 +-
drivers/phy/phy-exynos-dp-video.c | 111 ++++++++++++
drivers/phy/phy-exynos-mipi-video.c | 176 ++++++++++++++++++++
drivers/video/exynos/Kconfig | 3 +-
drivers/video/exynos/exynos_dp_core.c | 132 ++++-----------
drivers/video/exynos/exynos_dp_core.h | 110 ++++++++++++
drivers/video/exynos/exynos_dp_reg.c | 2 -
drivers/video/exynos/exynos_mipi_dsi.c | 19 ++-
include/linux/platform_data/mipi-csis.h | 9 -
include/video/exynos_dp.h | 131 ---------------
include/video/exynos_mipi_dsim.h | 5 +-
21 files changed, 508 insertions(+), 340 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/samsung-phy.txt
delete mode 100644 arch/arm/plat-samsung/setup-mipiphy.c
create mode 100644 drivers/phy/phy-exynos-dp-video.c
create mode 100644 drivers/phy/phy-exynos-mipi-video.c
delete mode 100644 include/video/exynos_dp.h
--
1.7.10.4
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox