[RFC PATCH 0/4] Common Display Framework-TF

[Tomi Valkeinen]

On 2013-02-11 11:31, Marcus Lorentzon wrote:

> Ok, so what about a compromise which I think would work for "both" HWs
> ... we allow the "configure" operation during video on, then each HW
> driver could decide if this means you have to stop or not to do the
> changes required. But then it is also important that we keep all config
> in one struct and not split it up. Otherwise HW like ours that has so be
> stopped could need to stop once for each setting/operation called.
> So in short, allow configure(bus_params) during video on, keep all
> bus_params in the struct. It is in kernel struct so it can easily be
> changed/refactored.

Right, we need some way to group the configuration parameters. Either
one big struct, or something like start_config() and end_config(). I
think we could also think what parameters make no sense to be configured
on the fly, and possibly have those separately. Although it may be a bit
difficult to think of all the (weird) use cases.

> Again, this probing and bus muxing is platform/bus specific and not
> panel specific. Any panel of that type will only ever work on Omap (or

The parameters used for configuration itself is platform specific, and
that's why it needs to be defined in the DT data. But the API itself is
not platform specific. The parameters are information about how the
panel is connected, just like, say, number of data lines is for DPI.
Which is also something I think should be configured by the panel.

> someone else implementing the same muxing features) as I see it. So why

No, it works for everyone. Well, at least I still don't see anything
omap or platform specific in the API. Of course, if the platform/device
doesn't support modifying the pin functions, then the function does nothing.

> not just put that config on the bus master, dispc? I still can't see how
> this is panel config. You are only pushing CDF API and meta data to
> describe something that is only needed by one bus master. I have never

The information about how the panel is connected (the wiring) has to be
somewhere in the DT data. We could have the info in the DSI master or in
the DSI slave. Or, in some platforms where the DSS is not involved in
the muxing/config, the info could be totally separate, in the boards
pinmuxing data.

I think all those work ok for normal cases without hotplug. But if you
have hotplug, then you need separate pinmuxing/config data for each panel.

You could possibly have a list of panels in your DSI master node,
containing the muxing data, but that sounds rather hacky, and also very
hardcoded, i.e. you need to know each panel that is ever going to be
connected.

If, on the other hand, you have the info in the panel node, it "just
works". When a new panel is connected, the relevant panel DT data comes
from somewhere (it's not relevant where), and it tells the DSI master
how it's connected.

Something like this is probably needed for the BeagleBone capes, if you
have happened to follow the discussion. Although it could be argued that
the capes may perhaps be not runtime hotswappable, and thus the
configuration can be done only once during boot after the cape has been
probed. But I'd rather not design the API so that we prevent hot swapping.

> seen any DSI slave that can change their pin config. And since there is

Well, if omap is the only SoC/device out there that supports configuring
the pin functions, and everybody is against the API, I'm not going to
press it.

But then again, I think similar configuration support may be needed even
for the normal pinmuxing, even in the case where you can't reconfigure
the DSI pin functions. You still need to mux the pins (perhaps, say,
between DSI and a GPIO), depending on how many lanes the panel uses.

In fact, speaking about all pins in general, I'm not very fond of having
a static pinmuxing in the board DT data, handled by the board setup
code. I think generally the pins should be muxed to safe-mode by the
board setup code, and then configured to their proper function by the
driver when it is initializing.

> no generic hot plug detect of DSI panels, at least not before DSI bus is
> available, I have to assume this probing it very platform specific. We
> have some products that provide 1-2 gpios to specify what panel is
> available, some use I2C sensor probing to then assume the panel plugged.

Yes, the hotplug mechanism is platform/board specific. But that's not
relevant here.

> At least in the first step I don't think this type of hot plug should be
> in the API. Then once the base panel driver is in we could discuss
> different solutions for you hot plug scenario.

Yes, as I said, I also think we shouldn't aim for hotplug in the v1. But
we also shouldn't prevent it.

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: 

[RFC PATCH 0/4] Common Display Framework-TF

[Marcus Lorentzon]

On 02/11/2013 09:21 AM, Tomi Valkeinen wrote:
> On 2013-02-08 16:54, Marcus Lorentzon wrote:
>> On 02/08/2013 03:02 PM, Tomi Valkeinen wrote:
>>> On 2013-02-08 15:28, Marcus Lorentzon wrote:
>>>
 When we do that we stop->setup->start during blanking. So our "DSS" is
 optimized to be able to do that without getting blocked. All DSI video
 mode panels (and DPI) products we have done so far have not had any
 issue with that (as long as DSI HS clock is set to continuous). I think
 this approach is less platform dependant, as long as there is no SoC
 that take more than a blanking period to reconfigure.
>>> So do you stop, setup and start the link with CPU, and this has to be
>>> happen during blanking? Isn't that prone to errors? Or did you mean that
>>> the hardware handles that automatically?
>>>
>>> In OMAP DSS there are so called shadow registers, that can be programmed
>>> at any time. The you set a bit (GO bit), which tells the hardware to
>>> take the new settings into use at the next vblank.
>>>
>>>   From DSI driver's perspective the link is never stopped when
>>> reconfiguring the video timings. However, many other settings have to be
>>> configured when the link is disabled.
>> Yeah, you lucky guys with the GO bit ;). No, we actually do CPU
>> stop,setup,start. But since it is video mode, master is driving the sync
>> so it is not a hard deadline. It is enough to restart before pixels
>> start to degrade. On an LCD that is not so much time, but on an OLED it
>> could be 10 secs :). Anyway, we have had several mass products with this
>> soft solution and it has worked well.
> Ah, ok. But in that case what you said in an earlier mail is not quite
> correct: "I think this approach is less platform dependant, as long as
> there is no SoC that take more than a blanking period to reconfigure.".
> So in your approach the reconfiguration doesn't have to be done inside
> the blanking period, but before the panel's picture starts to fade?
>
> I don't know... It's early Monday morning, and not enough coffee yet,
> but I get a bit uneasy feeling if I think that your method of
> reconfiguring would be the only think allowed by the CDF API.
>
> Some SoCs do support reconfiguring on the fly, without disabling the
> link. It would not be nice if we didn't allow this to happen. And
> actually, we're not only talking about SoCs here, but also any display
> devices, like external buffer chips etc. They may also offer means to
> change configs on the fly.
>
> Well, I don't have any hard point about this at the moment, but I think
> we should think different approaches how the configuration can be done.

Ok, so what about a compromise which I think would work for "both" HWs 
... we allow the "configure" operation during video on, then each HW 
driver could decide if this means you have to stop or not to do the 
changes required. But then it is also important that we keep all config 
in one struct and not split it up. Otherwise HW like ours that has so be 
stopped could need to stop once for each setting/operation called.
So in short, allow configure(bus_params) during video on, keep all 
bus_params in the struct. It is in kernel struct so it can easily be 
changed/refactored.
>
>> I understand, but removing the omap prefix doesn't mean it has to go in
>> the panel slave port/bus settings. I still can't see why this should be
>> configuration on the panel driver and not the DSI master driver. Number
>> of pins might be useful since you might start with one lane and then
>> activate the rest. But partial muxing (pre pinmux) doesn't seem to be
>> something the panel should control or know anything about. Sounds like
>> normal platform/DT data per product/board.
> I think one case where this kind of pin configuration is needed, and
> which also dictates that all panel related configuration has to be in
> the panel's data, not in the DSI master's data, is hotplug.
>
> If you have a board that has two panels connected to the same video
> output, probably via some kind of mux, at least for the sensitive pins
> like DSI, only one of the panels can be enabled at a time. The panels
> can have different wiring, and thus the panel driver would need to
> configure everything related to the bus when it's starting up.
>
> The same also happens if you have a true hotplug, i.e. you can remove
> the panel totally and plug in a new one. Again the wiring can be
> different, and needs to be set up.
>
> And, as I said, this means that all relevant data about the video bus
> has to be in the panel's data, so that each panel can have its own set
> of, say, pin configuration.
>
> Hotplug is not a use case we should aim to support for the CDF v1, but I
> think we should strive not to prevent hotplug either. So if we can
> design the API so that hotplug is possible, I say let's do that.
>
Again, this probing and bus muxing is platform/bus specific and not 
panel specific. Any panel of that type will only ever work on Omap 

[RFC PATCH 0/4] Common Display Framework-TF

[Tomi Valkeinen]

On 2013-02-08 16:54, Marcus Lorentzon wrote:
> On 02/08/2013 03:02 PM, Tomi Valkeinen wrote:
>> On 2013-02-08 15:28, Marcus Lorentzon wrote:
>>
>>> When we do that we stop->setup->start during blanking. So our "DSS" is
>>> optimized to be able to do that without getting blocked. All DSI video
>>> mode panels (and DPI) products we have done so far have not had any
>>> issue with that (as long as DSI HS clock is set to continuous). I think
>>> this approach is less platform dependant, as long as there is no SoC
>>> that take more than a blanking period to reconfigure.
>> So do you stop, setup and start the link with CPU, and this has to be
>> happen during blanking? Isn't that prone to errors? Or did you mean that
>> the hardware handles that automatically?
>>
>> In OMAP DSS there are so called shadow registers, that can be programmed
>> at any time. The you set a bit (GO bit), which tells the hardware to
>> take the new settings into use at the next vblank.
>>
>>  From DSI driver's perspective the link is never stopped when
>> reconfiguring the video timings. However, many other settings have to be
>> configured when the link is disabled.
> 
> Yeah, you lucky guys with the GO bit ;). No, we actually do CPU
> stop,setup,start. But since it is video mode, master is driving the sync
> so it is not a hard deadline. It is enough to restart before pixels
> start to degrade. On an LCD that is not so much time, but on an OLED it
> could be 10 secs :). Anyway, we have had several mass products with this
> soft solution and it has worked well.

Ah, ok. But in that case what you said in an earlier mail is not quite
correct: "I think this approach is less platform dependant, as long as
there is no SoC that take more than a blanking period to reconfigure.".
So in your approach the reconfiguration doesn't have to be done inside
the blanking period, but before the panel's picture starts to fade?

I don't know... It's early Monday morning, and not enough coffee yet,
but I get a bit uneasy feeling if I think that your method of
reconfiguring would be the only think allowed by the CDF API.

Some SoCs do support reconfiguring on the fly, without disabling the
link. It would not be nice if we didn't allow this to happen. And
actually, we're not only talking about SoCs here, but also any display
devices, like external buffer chips etc. They may also offer means to
change configs on the fly.

Well, I don't have any hard point about this at the moment, but I think
we should think different approaches how the configuration can be done.

> I understand, but removing the omap prefix doesn't mean it has to go in
> the panel slave port/bus settings. I still can't see why this should be
> configuration on the panel driver and not the DSI master driver. Number
> of pins might be useful since you might start with one lane and then
> activate the rest. But partial muxing (pre pinmux) doesn't seem to be
> something the panel should control or know anything about. Sounds like
> normal platform/DT data per product/board.

I think one case where this kind of pin configuration is needed, and
which also dictates that all panel related configuration has to be in
the panel's data, not in the DSI master's data, is hotplug.

If you have a board that has two panels connected to the same video
output, probably via some kind of mux, at least for the sensitive pins
like DSI, only one of the panels can be enabled at a time. The panels
can have different wiring, and thus the panel driver would need to
configure everything related to the bus when it's starting up.

The same also happens if you have a true hotplug, i.e. you can remove
the panel totally and plug in a new one. Again the wiring can be
different, and needs to be set up.

And, as I said, this means that all relevant data about the video bus
has to be in the panel's data, so that each panel can have its own set
of, say, pin configuration.

Hotplug is not a use case we should aim to support for the CDF v1, but I
think we should strive not to prevent hotplug either. So if we can
design the API so that hotplug is possible, I say let's do that.

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: 

Re: [RFC PATCH 0/4] Common Display Framework-TF

[Tomi Valkeinen]

On 2013-02-08 16:54, Marcus Lorentzon wrote:
 On 02/08/2013 03:02 PM, Tomi Valkeinen wrote:
 On 2013-02-08 15:28, Marcus Lorentzon wrote:

 When we do that we stop-setup-start during blanking. So our DSS is
 optimized to be able to do that without getting blocked. All DSI video
 mode panels (and DPI) products we have done so far have not had any
 issue with that (as long as DSI HS clock is set to continuous). I think
 this approach is less platform dependant, as long as there is no SoC
 that take more than a blanking period to reconfigure.
 So do you stop, setup and start the link with CPU, and this has to be
 happen during blanking? Isn't that prone to errors? Or did you mean that
 the hardware handles that automatically?

 In OMAP DSS there are so called shadow registers, that can be programmed
 at any time. The you set a bit (GO bit), which tells the hardware to
 take the new settings into use at the next vblank.

  From DSI driver's perspective the link is never stopped when
 reconfiguring the video timings. However, many other settings have to be
 configured when the link is disabled.
 
 Yeah, you lucky guys with the GO bit ;). No, we actually do CPU
 stop,setup,start. But since it is video mode, master is driving the sync
 so it is not a hard deadline. It is enough to restart before pixels
 start to degrade. On an LCD that is not so much time, but on an OLED it
 could be 10 secs :). Anyway, we have had several mass products with this
 soft solution and it has worked well.

Ah, ok. But in that case what you said in an earlier mail is not quite
correct: I think this approach is less platform dependant, as long as
there is no SoC that take more than a blanking period to reconfigure..
So in your approach the reconfiguration doesn't have to be done inside
the blanking period, but before the panel's picture starts to fade?

I don't know... It's early Monday morning, and not enough coffee yet,
but I get a bit uneasy feeling if I think that your method of
reconfiguring would be the only think allowed by the CDF API.

Some SoCs do support reconfiguring on the fly, without disabling the
link. It would not be nice if we didn't allow this to happen. And
actually, we're not only talking about SoCs here, but also any display
devices, like external buffer chips etc. They may also offer means to
change configs on the fly.

Well, I don't have any hard point about this at the moment, but I think
we should think different approaches how the configuration can be done.

 I understand, but removing the omap prefix doesn't mean it has to go in
 the panel slave port/bus settings. I still can't see why this should be
 configuration on the panel driver and not the DSI master driver. Number
 of pins might be useful since you might start with one lane and then
 activate the rest. But partial muxing (pre pinmux) doesn't seem to be
 something the panel should control or know anything about. Sounds like
 normal platform/DT data per product/board.

I think one case where this kind of pin configuration is needed, and
which also dictates that all panel related configuration has to be in
the panel's data, not in the DSI master's data, is hotplug.

If you have a board that has two panels connected to the same video
output, probably via some kind of mux, at least for the sensitive pins
like DSI, only one of the panels can be enabled at a time. The panels
can have different wiring, and thus the panel driver would need to
configure everything related to the bus when it's starting up.

The same also happens if you have a true hotplug, i.e. you can remove
the panel totally and plug in a new one. Again the wiring can be
different, and needs to be set up.

And, as I said, this means that all relevant data about the video bus
has to be in the panel's data, so that each panel can have its own set
of, say, pin configuration.

Hotplug is not a use case we should aim to support for the CDF v1, but I
think we should strive not to prevent hotplug either. So if we can
design the API so that hotplug is possible, I say let's do that.

 Tomi




signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 0/4] Common Display Framework-TF

[Tomi Valkeinen]

On 2013-02-11 11:31, Marcus Lorentzon wrote:

 Ok, so what about a compromise which I think would work for both HWs
 ... we allow the configure operation during video on, then each HW
 driver could decide if this means you have to stop or not to do the
 changes required. But then it is also important that we keep all config
 in one struct and not split it up. Otherwise HW like ours that has so be
 stopped could need to stop once for each setting/operation called.
 So in short, allow configure(bus_params) during video on, keep all
 bus_params in the struct. It is in kernel struct so it can easily be
 changed/refactored.

Right, we need some way to group the configuration parameters. Either
one big struct, or something like start_config() and end_config(). I
think we could also think what parameters make no sense to be configured
on the fly, and possibly have those separately. Although it may be a bit
difficult to think of all the (weird) use cases.

 Again, this probing and bus muxing is platform/bus specific and not
 panel specific. Any panel of that type will only ever work on Omap (or

The parameters used for configuration itself is platform specific, and
that's why it needs to be defined in the DT data. But the API itself is
not platform specific. The parameters are information about how the
panel is connected, just like, say, number of data lines is for DPI.
Which is also something I think should be configured by the panel.

 someone else implementing the same muxing features) as I see it. So why

No, it works for everyone. Well, at least I still don't see anything
omap or platform specific in the API. Of course, if the platform/device
doesn't support modifying the pin functions, then the function does nothing.

 not just put that config on the bus master, dispc? I still can't see how
 this is panel config. You are only pushing CDF API and meta data to
 describe something that is only needed by one bus master. I have never

The information about how the panel is connected (the wiring) has to be
somewhere in the DT data. We could have the info in the DSI master or in
the DSI slave. Or, in some platforms where the DSS is not involved in
the muxing/config, the info could be totally separate, in the boards
pinmuxing data.

I think all those work ok for normal cases without hotplug. But if you
have hotplug, then you need separate pinmuxing/config data for each panel.

You could possibly have a list of panels in your DSI master node,
containing the muxing data, but that sounds rather hacky, and also very
hardcoded, i.e. you need to know each panel that is ever going to be
connected.

If, on the other hand, you have the info in the panel node, it just
works. When a new panel is connected, the relevant panel DT data comes
from somewhere (it's not relevant where), and it tells the DSI master
how it's connected.

Something like this is probably needed for the BeagleBone capes, if you
have happened to follow the discussion. Although it could be argued that
the capes may perhaps be not runtime hotswappable, and thus the
configuration can be done only once during boot after the cape has been
probed. But I'd rather not design the API so that we prevent hot swapping.

 seen any DSI slave that can change their pin config. And since there is

Well, if omap is the only SoC/device out there that supports configuring
the pin functions, and everybody is against the API, I'm not going to
press it.

But then again, I think similar configuration support may be needed even
for the normal pinmuxing, even in the case where you can't reconfigure
the DSI pin functions. You still need to mux the pins (perhaps, say,
between DSI and a GPIO), depending on how many lanes the panel uses.

In fact, speaking about all pins in general, I'm not very fond of having
a static pinmuxing in the board DT data, handled by the board setup
code. I think generally the pins should be muxed to safe-mode by the
board setup code, and then configured to their proper function by the
driver when it is initializing.

 no generic hot plug detect of DSI panels, at least not before DSI bus is
 available, I have to assume this probing it very platform specific. We
 have some products that provide 1-2 gpios to specify what panel is
 available, some use I2C sensor probing to then assume the panel plugged.

Yes, the hotplug mechanism is platform/board specific. But that's not
relevant here.

 At least in the first step I don't think this type of hot plug should be
 in the API. Then once the base panel driver is in we could discuss
 different solutions for you hot plug scenario.

Yes, as I said, I also think we shouldn't aim for hotplug in the v1. But
we also shouldn't prevent it.

 Tomi




signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 0/4] Common Display Framework-TF

[Tomi Valkeinen]

On 2013-02-08 14:40, Marcus Lorentzon wrote:

 I agree, but I think it should be
 setup-enable-video_on-video_off-disable-setup-...
 I don't think there is any interface parameters that should be changed
 while link is enabled. And if there are, they should be identified and
 split out into a separate operation.

Hmm. At least on OMAP and DSI video mode, it is possible to change at
least timings on the fly. But yes, generally the link has to be disabled
first before changing any parameters.

 In OMAP you can configure the DSI pins quite freely. We have the
 following struct:

 struct omap_dsi_pin_config {
 int num_pins;
 /*
  * pin numbers in the following order:
  * clk+, clk-
  * data1+, data1-
  * data2+, data2-
  * ...
  */
 int pins[OMAP_DSS_MAX_DSI_PINS];
 };

 Do you reroute after boot? Or is this just board/product setup. We
 have some pinmuxing as well and DPhy sharing, but we have never used it
 after init/boot. If not runtime, I think this could be put in DT config
 for product instead of under dynamic control from panel.

The pin config with the struct above is done later, when the panel
driver configures the DSI bus. So in OMAP we have two distinct things
that need to be configured:

- The actual pin muxing, i.e. selecting the functions for pin N on the
OMAP package. The functions for a single pin could be for example GPIO
70, DSI DX0, UART1_CTS, etc. This is normally done once during board init.

- DSI pin configuration in the display subsystem. This is used to map
the pins to DSI functions. I.e. DSI DX0 pin is mapped to DATA1+. This is
done by the DSS driver, when the panel driver gives it the parameters.

So the first muxing basically assigns the pin to DSI in general, and
then DSI will internally route the pin to a an actual DSI function.

Whether the muxing needs to changed during runtime... I'm not sure. On
OMAP the DSI pin config also tells how many lanes are used. So if a DSI
panel would first want to use only one lane, and later change it to n
lanes, we'd need this kind of function.

I think it conceptually fits better if the pin config data is passed to
the panel via DT data, and the panel then gives the config to the DSI
master. It's just a part of the DSI bus parameters, like, say, clock
speed or whether to use HS or LP. That way the DT node for the panel
contains the information about the panel. (versus having pin config data
in the DSI master, in which case the DSI master's node contains data
about a specific DSI panel).

 Tomi




signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 0/4] Common Display Framework-TF

[Tomi Valkeinen]

On 2013-02-08 15:28, Marcus Lorentzon wrote:

 When we do that we stop-setup-start during blanking. So our DSS is
 optimized to be able to do that without getting blocked. All DSI video
 mode panels (and DPI) products we have done so far have not had any
 issue with that (as long as DSI HS clock is set to continuous). I think
 this approach is less platform dependant, as long as there is no SoC
 that take more than a blanking period to reconfigure.

So do you stop, setup and start the link with CPU, and this has to be
happen during blanking? Isn't that prone to errors? Or did you mean that
the hardware handles that automatically?

In OMAP DSS there are so called shadow registers, that can be programmed
at any time. The you set a bit (GO bit), which tells the hardware to
take the new settings into use at the next vblank.

From DSI driver's perspective the link is never stopped when
reconfiguring the video timings. However, many other settings have to be
configured when the link is disabled.

 In OMAP you can configure the DSI pins quite freely. We have the
 following struct:

 struct omap_dsi_pin_config {
  int num_pins;
  /*
   * pin numbers in the following order:
   * clk+, clk-
   * data1+, data1-
   * data2+, data2-
   * ...
   */
  int pins[OMAP_DSS_MAX_DSI_PINS];
 };


 I think it still is OMAP specifics and doesn't belong in the panel
 drivers any longer. If you revisit this requirement in the CDF context
 where DSI ifc parameters should describe how to interface with a panel
 outside the SoC, there can't really be any dependencies on SoC internal
 routing. As you say, this is inside pinmux, so how can that affect the
 SoC external interface? I would suggest moving this to dispc-dsilink DT
 settings that are activated on dsilink-enable/disable. At least that is
 how I plan to solve similar STE SoC specific DSI config settings that
 are not really CDF panel generic, like some DPhy trim settings. They do
 depend on the panel and clock speed, but they are more product specific
 than panel driver specific. Then if there are these type of settings
 that every SoC have, then we could look at standardize those. But for
 starters I would try to keep it in product/board-DT per DSI link. So we
 should try to differentiate between DSI host and slave bus params and
 keep slave params in panel driver.

Ok, I think I was being a bit vague here. I explained the OMAP DSI
routing not because I meant that this API is specific to that, but
because it explains why this kind of routing info is needed, and a
bitmask is not enough.

If you look at the omap_dsi_pin_config struct, there's nothing OMAP
specific there (except the names =). All it tells is that this device
uses N DSI pins, and the device's clk+ function should be connected to
pin X on the DSI master, clk- should be connected to pin Y, etc. X and Y
are integers, and what they mean is specific to the DSI master.

When the DSI master is OMAP's DSI, the OMAP DSI driver does the pin
configuration as I explained. When the DSI master is something else,
say, a DSI bridge, it does whatever it needs to do (which could be
nothing) to assign a particular DSI function to a pin.

 Tomi




signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 0/4] Common Display Framework-TF

[Tomi Valkeinen]

On 2013-02-08 15:28, Marcus Lorentzon wrote:

> When we do that we stop->setup->start during blanking. So our "DSS" is
> optimized to be able to do that without getting blocked. All DSI video
> mode panels (and DPI) products we have done so far have not had any
> issue with that (as long as DSI HS clock is set to continuous). I think
> this approach is less platform dependant, as long as there is no SoC
> that take more than a blanking period to reconfigure.

So do you stop, setup and start the link with CPU, and this has to be
happen during blanking? Isn't that prone to errors? Or did you mean that
the hardware handles that automatically?

In OMAP DSS there are so called shadow registers, that can be programmed
at any time. The you set a bit (GO bit), which tells the hardware to
take the new settings into use at the next vblank.

[RFC PATCH 0/4] Common Display Framework-TF

[Marcus Lorentzon]

On 02/08/2013 03:02 PM, Tomi Valkeinen wrote:
> On 2013-02-08 15:28, Marcus Lorentzon wrote:
>
>> When we do that we stop->setup->start during blanking. So our "DSS" is
>> optimized to be able to do that without getting blocked. All DSI video
>> mode panels (and DPI) products we have done so far have not had any
>> issue with that (as long as DSI HS clock is set to continuous). I think
>> this approach is less platform dependant, as long as there is no SoC
>> that take more than a blanking period to reconfigure.
> So do you stop, setup and start the link with CPU, and this has to be
> happen during blanking? Isn't that prone to errors? Or did you mean that
> the hardware handles that automatically?
>
> In OMAP DSS there are so called shadow registers, that can be programmed
> at any time. The you set a bit (GO bit), which tells the hardware to
> take the new settings into use at the next vblank.
>
>  From DSI driver's perspective the link is never stopped when
> reconfiguring the video timings. However, many other settings have to be
> configured when the link is disabled.

Yeah, you lucky guys with the GO bit ;). No, we actually do CPU 
stop,setup,start. But since it is video mode, master is driving the sync 
so it is not a hard deadline. It is enough to restart before pixels 
start to degrade. On an LCD that is not so much time, but on an OLED it 
could be 10 secs :). Anyway, we have had several mass products with this 
soft solution and it has worked well.
> In OMAP you can configure the DSI pins quite freely. We have the
> following struct:
>
> struct omap_dsi_pin_config {
>   int num_pins;
>   /*
>* pin numbers in the following order:
>* clk+, clk-
>* data1+, data1-
>* data2+, data2-
>* ...
>*/
>   int pins[OMAP_DSS_MAX_DSI_PINS];
> };
>
>> I think it still is OMAP specifics and doesn't belong in the panel
>> drivers any longer. If you revisit this requirement in the CDF context
>> where DSI ifc parameters should describe how to interface with a panel
>> outside the SoC, there can't really be any dependencies on SoC internal
>> routing. As you say, this is inside pinmux, so how can that affect the
>> SoC external interface? I would suggest moving this to dispc-dsilink DT
>> settings that are activated on dsilink->enable/disable. At least that is
>> how I plan to solve similar STE SoC specific DSI config settings that
>> are not really CDF panel generic, like some DPhy trim settings. They do
>> depend on the panel and clock speed, but they are more product specific
>> than panel driver specific. Then if there are these type of settings
>> that every SoC have, then we could look at standardize those. But for
>> starters I would try to keep it in product/board-DT per DSI link. So we
>> should try to differentiate between DSI host and slave bus params and
>> keep slave params in panel driver.
> Ok, I think I was being a bit vague here. I explained the OMAP DSI
> routing not because I meant that this API is specific to that, but
> because it explains why this kind of routing info is needed, and a
> bitmask is not enough.
>
> If you look at the omap_dsi_pin_config struct, there's nothing OMAP
> specific there (except the names =). All it tells is that this device
> uses N DSI pins, and the device's clk+ function should be connected to
> pin X on the DSI master, clk- should be connected to pin Y, etc. X and Y
> are integers, and what they mean is specific to the DSI master.
>
> When the DSI master is OMAP's DSI, the OMAP DSI driver does the pin
> configuration as I explained. When the DSI master is something else,
> say, a DSI bridge, it does whatever it needs to do (which could be
> nothing) to assign a particular DSI function to a pin.
>
I understand, but removing the omap prefix doesn't mean it has to go in 
the panel slave port/bus settings. I still can't see why this should be 
configuration on the panel driver and not the DSI master driver. Number 
of pins might be useful since you might start with one lane and then 
activate the rest. But partial muxing (pre pinmux) doesn't seem to be 
something the panel should control or know anything about. Sounds like 
normal platform/DT data per product/board.

/BR
/Marcus

[RFC PATCH 0/4] Common Display Framework-TF

[Tomi Valkeinen]

On 2013-02-08 14:40, Marcus Lorentzon wrote:

> I agree, but I think it should be
> setup->enable->video_on->video_off->disable->setup->...
> I don't think there is any interface parameters that should be changed
> while link is enabled. And if there are, they should be identified and
> split out into a separate operation.

Hmm. At least on OMAP and DSI video mode, it is possible to change at
least timings on the fly. But yes, generally the link has to be disabled
first before changing any parameters.

>> In OMAP you can configure the DSI pins quite freely. We have the
>> following struct:
>>
>> struct omap_dsi_pin_config {
>> int num_pins;
>> /*
>>  * pin numbers in the following order:
>>  * clk+, clk-
>>  * data1+, data1-
>>  * data2+, data2-
>>  * ...
>>  */
>> int pins[OMAP_DSS_MAX_DSI_PINS];
>> };
>>
> Do you reroute after boot? Or is this just "board/product setup". We
> have some pinmuxing as well and DPhy sharing, but we have never used it
> after init/boot. If not runtime, I think this could be put in DT config
> for product instead of under dynamic control from panel.

The pin config with the struct above is done later, when the panel
driver configures the DSI bus. So in OMAP we have two distinct things
that need to be configured:

- The actual pin muxing, i.e. selecting the functions for pin N on the
OMAP package. The functions for a single pin could be for example GPIO
70, DSI DX0, UART1_CTS, etc. This is normally done once during board init.

- DSI pin configuration in the display subsystem. This is used to map
the pins to DSI functions. I.e. DSI DX0 pin is mapped to DATA1+. This is
done by the DSS driver, when the panel driver gives it the parameters.

So the first muxing basically assigns the pin to DSI in general, and
then DSI will internally route the pin to a an actual DSI function.

Whether the muxing needs to changed during runtime... I'm not sure. On
OMAP the DSI pin config also tells how many lanes are used. So if a DSI
panel would first want to use only one lane, and later change it to n
lanes, we'd need this kind of function.

I think it conceptually fits better if the pin config data is passed to
the panel via DT data, and the panel then gives the config to the DSI
master. It's just a part of the DSI bus parameters, like, say, clock
speed or whether to use HS or LP. That way the DT node for the panel
contains the information about the panel. (versus having pin config data
in the DSI master, in which case the DSI master's node contains data
about a specific DSI panel).

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: 

[RFC PATCH 0/4] Common Display Framework-TF

[Marcus Lorentzon]

On 02/08/2013 02:04 PM, Tomi Valkeinen wrote:
> On 2013-02-08 14:40, Marcus Lorentzon wrote:
>
>> I agree, but I think it should be
>> setup->enable->video_on->video_off->disable->setup->...
>> I don't think there is any interface parameters that should be changed
>> while link is enabled. And if there are, they should be identified and
>> split out into a separate operation.
> Hmm. At least on OMAP and DSI video mode, it is possible to change at
> least timings on the fly. But yes, generally the link has to be disabled
> first before changing any parameters.

When we do that we stop->setup->start during blanking. So our "DSS" is 
optimized to be able to do that without getting blocked. All DSI video 
mode panels (and DPI) products we have done so far have not had any 
issue with that (as long as DSI HS clock is set to continuous). I think 
this approach is less platform dependant, as long as there is no SoC 
that take more than a blanking period to reconfigure.
>>> In OMAP you can configure the DSI pins quite freely. We have the
>>> following struct:
>>>
>>> struct omap_dsi_pin_config {
>>>  int num_pins;
>>>  /*
>>>   * pin numbers in the following order:
>>>   * clk+, clk-
>>>   * data1+, data1-
>>>   * data2+, data2-
>>>   * ...
>>>   */
>>>  int pins[OMAP_DSS_MAX_DSI_PINS];
>>> };
>>>
>> Do you reroute after boot? Or is this just "board/product setup". We
>> have some pinmuxing as well and DPhy sharing, but we have never used it
>> after init/boot. If not runtime, I think this could be put in DT config
>> for product instead of under dynamic control from panel.
> The pin config with the struct above is done later, when the panel
> driver configures the DSI bus. So in OMAP we have two distinct things
> that need to be configured:
>
> - The actual pin muxing, i.e. selecting the functions for pin N on the
> OMAP package. The functions for a single pin could be for example GPIO
> 70, DSI DX0, UART1_CTS, etc. This is normally done once during board init.
>
> - DSI pin configuration in the display subsystem. This is used to map
> the pins to DSI functions. I.e. DSI DX0 pin is mapped to DATA1+. This is
> done by the DSS driver, when the panel driver gives it the parameters.
>
> So the first muxing basically assigns the pin to DSI in general, and
> then DSI will internally route the pin to a an actual DSI function.
>
> Whether the muxing needs to changed during runtime... I'm not sure. On
> OMAP the DSI pin config also tells how many lanes are used. So if a DSI
> panel would first want to use only one lane, and later change it to n
> lanes, we'd need this kind of function.
>
> I think it conceptually fits better if the pin config data is passed to
> the panel via DT data, and the panel then gives the config to the DSI
> master. It's just a part of the DSI bus parameters, like, say, clock
> speed or whether to use HS or LP. That way the DT node for the panel
> contains the information about the panel. (versus having pin config data
> in the DSI master, in which case the DSI master's node contains data
> about a specific DSI panel).
>
I think it still is OMAP specifics and doesn't belong in the panel 
drivers any longer. If you revisit this requirement in the CDF context 
where DSI ifc parameters should describe how to interface with a panel 
outside the SoC, there can't really be any dependencies on SoC internal 
routing. As you say, this is inside pinmux, so how can that affect the 
SoC external interface? I would suggest moving this to dispc-dsilink DT 
settings that are activated on dsilink->enable/disable. At least that is 
how I plan to solve similar STE SoC specific DSI config settings that 
are not really CDF panel generic, like some DPhy trim settings. They do 
depend on the panel and clock speed, but they are more product specific 
than panel driver specific. Then if there are these type of settings 
that every SoC have, then we could look at standardize those. But for 
starters I would try to keep it in product/board-DT per DSI link. So we 
should try to differentiate between DSI host and slave bus params and 
keep slave params in panel driver.

/BR
/Marcus

[RFC PATCH 0/4] Common Display Framework-TF

[Marcus Lorentzon]

On 02/08/2013 12:40 PM, Tomi Valkeinen wrote:
> Hi,
>
> On 2013-02-03 21:17, Tomasz Figa wrote:
>> Hi Laurent,
>>
>> On Saturday 02 of February 2013 11:39:59 Laurent Pinchart wrote:
>>> Hi Tomasz,
>>>
>>> Thank you for your RFC.
>>>
>>> On Wednesday 30 January 2013 16:38:59 Tomasz Figa wrote:
 Changes done to Tomi's edition of CDF:
   - Replaced set_operation_mode, set_pixel_format and set_size video
   source>
 operations with get_params display entity operation, as it was
 originally in Laurent's version.
 
 We have discussed this matter on the mailing list and decided that
 it
 would be better to have the source ask the sink for its parameter
 structure and do whatever appropriate with it.
>>> Could you briefly outline the rationale behind this ?
>> Display interfaces may be described by an arbitrary number of parameters.
>> Some will require just video timings, others like DSI will require a
>> significant number of additional bus-specific ones.
>>
>> Separating all the parameters (all of which are usually set at the same
>> time) into a lot of ops setting single parameter will just add unnecessary
>> complexity.
> I have nothing against combining the parameters that way. I think the
> important thing here is just that we have to allow changing of the
> parameters, whenever the display device needs that. So the bus
> parameters cannot be a one time constant setting.

I agree, but I think it should be 
setup->enable->video_on->video_off->disable->setup->...
I don't think there is any interface parameters that should be changed 
while link is enabled. And if there are, they should be identified and 
split out into a separate operation.
>>> I'm wondering whether get_params could limit us if a device needs to
>>> modify parameters at runtime. For instance a panel might need to change
>>> clock frequencies or number of used data lane depending on various
>>> runtime conditions. I don't have a real use case here, so it might just
>>> be a bit of over-engineering.
>> Hmm, isn't it in the opposite direction (the user requests the display
>> interface to change, for example, video mode, which in turn reconfigures
>> the link and requests the panel to update its settings)?
> Well, now, that's the question.
>
> Let's consider a simplified case with DSI output from the SoC, and a DSI
> panel. If the panel is a rather simple one, you could well call a method
> in the API in the DSI output driver, which would do necessary
> configuration and inform the panel driver to do any configuration it
> needs to do, based on the parameters.
>
> However, in my experience display devices, DSI devices in particular,
> are often quite "interesting". If the control of the operation in
> question is in the DSI output side, we are limited about what kind of
> DSI panels we can use, as the DSI output driver has to know all the
> tricks needed to make the panels work.
>
> I'm having hard time trying to explain this, so let's try an example.
> Consider the initial powering up of the bus. If the DSI output driver is
> in control, something like the following probably happens:
>
> - output driver asks for the parameters from the panel driver
> - output driver programs the DSI output according to these parameters
> - output driver informs the panel that the bus is now up and running
>
> Then consider a totally invented case, but which perhaps describes the
> problem with the above approach: The DSI panel requires the DSI bus
> first to be started in HS mode, but with a certain predefined bus speed,
> and only one lane used. This predefined bus setup is used to send
> configuration commands to the panel hardware, and only after that can
> you reconfigure the bus with proper speed and lanes.
>
> That kind of thing is a bit difficult to manage with the DSI output
> driver is in control. However, if the DSI panel driver is in control,
> it's simple:
>
> - panel driver calls config methods in the DSI output driver, setting
> the predefined speed and one lane
> - panel driver sends configuration commands to the panel
> - panel driver calls config methods in the DSI output driver, setting
> the final bus config

We have similar use cases and so I agree (and have implemented) the 
latter approach where panel driver is in control. I think it is 
important to separate the panel calling dispc (which it should not) from 
panel calling bus/videosource ops. Compare to I2C, no one would expect 
panel to call dispc to do I2C ops, instead panel call bus ops directly 
in response to the CDF ops request panel is running.
 5. Mask of used data lanes (each bit represents single lane).
>>>  From my experience with MIPI CSI (Camera Serial Interface, similar to
>>> DSI) some transceivers can reroute data lanes internally. Is that true
>>> for DSI as well ? In that case we would need a list of data lanes, not
>>> just a mask.
>> Hmm, I don't remember at the moment, will have to look to 

[RFC PATCH 0/4] Common Display Framework-TF

[Tomi Valkeinen]

Hi,

On 2013-02-03 21:17, Tomasz Figa wrote:
> Hi Laurent,
> 
> On Saturday 02 of February 2013 11:39:59 Laurent Pinchart wrote:
>> Hi Tomasz,
>>
>> Thank you for your RFC.
>>
>> On Wednesday 30 January 2013 16:38:59 Tomasz Figa wrote:

>>> Changes done to Tomi's edition of CDF:
>>>  - Replaced set_operation_mode, set_pixel_format and set_size video
>>>  source>  
>>>operations with get_params display entity operation, as it was
>>>originally in Laurent's version.
>>>
>>>We have discussed this matter on the mailing list and decided that
>>>it
>>>would be better to have the source ask the sink for its parameter
>>>structure and do whatever appropriate with it.
>>
>> Could you briefly outline the rationale behind this ?
> 
> Display interfaces may be described by an arbitrary number of parameters. 
> Some will require just video timings, others like DSI will require a 
> significant number of additional bus-specific ones.
> 
> Separating all the parameters (all of which are usually set at the same 
> time) into a lot of ops setting single parameter will just add unnecessary 
> complexity.

I have nothing against combining the parameters that way. I think the
important thing here is just that we have to allow changing of the
parameters, whenever the display device needs that. So the bus
parameters cannot be a one time constant setting.

>> I'm wondering whether get_params could limit us if a device needs to
>> modify parameters at runtime. For instance a panel might need to change
>> clock frequencies or number of used data lane depending on various
>> runtime conditions. I don't have a real use case here, so it might just
>> be a bit of over-engineering.
> 
> Hmm, isn't it in the opposite direction (the user requests the display 
> interface to change, for example, video mode, which in turn reconfigures 
> the link and requests the panel to update its settings)?

Well, now, that's the question.

Let's consider a simplified case with DSI output from the SoC, and a DSI
panel. If the panel is a rather simple one, you could well call a method
in the API in the DSI output driver, which would do necessary
configuration and inform the panel driver to do any configuration it
needs to do, based on the parameters.

However, in my experience display devices, DSI devices in particular,
are often quite "interesting". If the control of the operation in
question is in the DSI output side, we are limited about what kind of
DSI panels we can use, as the DSI output driver has to know all the
tricks needed to make the panels work.

I'm having hard time trying to explain this, so let's try an example.
Consider the initial powering up of the bus. If the DSI output driver is
in control, something like the following probably happens:

- output driver asks for the parameters from the panel driver
- output driver programs the DSI output according to these parameters
- output driver informs the panel that the bus is now up and running

Then consider a totally invented case, but which perhaps describes the
problem with the above approach: The DSI panel requires the DSI bus
first to be started in HS mode, but with a certain predefined bus speed,
and only one lane used. This predefined bus setup is used to send
configuration commands to the panel hardware, and only after that can
you reconfigure the bus with proper speed and lanes.

That kind of thing is a bit difficult to manage with the DSI output
driver is in control. However, if the DSI panel driver is in control,
it's simple:

- panel driver calls config methods in the DSI output driver, setting
the predefined speed and one lane
- panel driver sends configuration commands to the panel
- panel driver calls config methods in the DSI output driver, setting
the final bus config

>>>5. Mask of used data lanes (each bit represents single lane).
>>
>> From my experience with MIPI CSI (Camera Serial Interface, similar to
>> DSI) some transceivers can reroute data lanes internally. Is that true
>> for DSI as well ? In that case we would need a list of data lanes, not
>> just a mask.
> 
> Hmm, I don't remember at the moment, will have to look to the 
> specification. Exynos DSI master doesn't support such feature.

In OMAP you can configure the DSI pins quite freely. We have the
following struct:

struct omap_dsi_pin_config {
int num_pins;
/*
 * pin numbers in the following order:
 * clk+, clk-
 * data1+, data1-
 * data2+, data2-
 * ...
 */
int pins[OMAP_DSS_MAX_DSI_PINS];
};

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: 

Re: [RFC PATCH 0/4] Common Display Framework-TF

[Marcus Lorentzon]

On 02/08/2013 12:40 PM, Tomi Valkeinen wrote:

Hi,

On 2013-02-03 21:17, Tomasz Figa wrote:

Hi Laurent,

On Saturday 02 of February 2013 11:39:59 Laurent Pinchart wrote:

Hi Tomasz,

Thank you for your RFC.

On Wednesday 30 January 2013 16:38:59 Tomasz Figa wrote:

Changes done to Tomi's edition of CDF:
  - Replaced set_operation_mode, set_pixel_format and set_size video
  source
operations with get_params display entity operation, as it was
originally in Laurent's version.

We have discussed this matter on the mailing list and decided that

it
would be better to have the source ask the sink for its parameter
structure and do whatever appropriate with it.

Could you briefly outline the rationale behind this ?

Display interfaces may be described by an arbitrary number of parameters.
Some will require just video timings, others like DSI will require a
significant number of additional bus-specific ones.

Separating all the parameters (all of which are usually set at the same
time) into a lot of ops setting single parameter will just add unnecessary
complexity.

I have nothing against combining the parameters that way. I think the
important thing here is just that we have to allow changing of the
parameters, whenever the display device needs that. So the bus
parameters cannot be a one time constant setting.


I agree, but I think it should be 
setup-enable-video_on-video_off-disable-setup-...
I don't think there is any interface parameters that should be changed 
while link is enabled. And if there are, they should be identified and 
split out into a separate operation.

I'm wondering whether get_params could limit us if a device needs to
modify parameters at runtime. For instance a panel might need to change
clock frequencies or number of used data lane depending on various
runtime conditions. I don't have a real use case here, so it might just
be a bit of over-engineering.

Hmm, isn't it in the opposite direction (the user requests the display
interface to change, for example, video mode, which in turn reconfigures
the link and requests the panel to update its settings)?

Well, now, that's the question.

Let's consider a simplified case with DSI output from the SoC, and a DSI
panel. If the panel is a rather simple one, you could well call a method
in the API in the DSI output driver, which would do necessary
configuration and inform the panel driver to do any configuration it
needs to do, based on the parameters.

However, in my experience display devices, DSI devices in particular,
are often quite interesting. If the control of the operation in
question is in the DSI output side, we are limited about what kind of
DSI panels we can use, as the DSI output driver has to know all the
tricks needed to make the panels work.

I'm having hard time trying to explain this, so let's try an example.
Consider the initial powering up of the bus. If the DSI output driver is
in control, something like the following probably happens:

- output driver asks for the parameters from the panel driver
- output driver programs the DSI output according to these parameters
- output driver informs the panel that the bus is now up and running

Then consider a totally invented case, but which perhaps describes the
problem with the above approach: The DSI panel requires the DSI bus
first to be started in HS mode, but with a certain predefined bus speed,
and only one lane used. This predefined bus setup is used to send
configuration commands to the panel hardware, and only after that can
you reconfigure the bus with proper speed and lanes.

That kind of thing is a bit difficult to manage with the DSI output
driver is in control. However, if the DSI panel driver is in control,
it's simple:

- panel driver calls config methods in the DSI output driver, setting
the predefined speed and one lane
- panel driver sends configuration commands to the panel
- panel driver calls config methods in the DSI output driver, setting
the final bus config


We have similar use cases and so I agree (and have implemented) the 
latter approach where panel driver is in control. I think it is 
important to separate the panel calling dispc (which it should not) from 
panel calling bus/videosource ops. Compare to I2C, no one would expect 
panel to call dispc to do I2C ops, instead panel call bus ops directly 
in response to the CDF ops request panel is running.

5. Mask of used data lanes (each bit represents single lane).

 From my experience with MIPI CSI (Camera Serial Interface, similar to
DSI) some transceivers can reroute data lanes internally. Is that true
for DSI as well ? In that case we would need a list of data lanes, not
just a mask.

Hmm, I don't remember at the moment, will have to look to the
specification. Exynos DSI master doesn't support such feature.

In OMAP you can configure the DSI pins quite freely. We have the
following struct:

struct omap_dsi_pin_config {
int num_pins;
/*
 * pin 

Re: [RFC PATCH 0/4] Common Display Framework-TF

[Marcus Lorentzon]

On 02/08/2013 03:02 PM, Tomi Valkeinen wrote:

On 2013-02-08 15:28, Marcus Lorentzon wrote:


When we do that we stop-setup-start during blanking. So our DSS is
optimized to be able to do that without getting blocked. All DSI video
mode panels (and DPI) products we have done so far have not had any
issue with that (as long as DSI HS clock is set to continuous). I think
this approach is less platform dependant, as long as there is no SoC
that take more than a blanking period to reconfigure.

So do you stop, setup and start the link with CPU, and this has to be
happen during blanking? Isn't that prone to errors? Or did you mean that
the hardware handles that automatically?

In OMAP DSS there are so called shadow registers, that can be programmed
at any time. The you set a bit (GO bit), which tells the hardware to
take the new settings into use at the next vblank.

 From DSI driver's perspective the link is never stopped when
reconfiguring the video timings. However, many other settings have to be
configured when the link is disabled.


Yeah, you lucky guys with the GO bit ;). No, we actually do CPU 
stop,setup,start. But since it is video mode, master is driving the sync 
so it is not a hard deadline. It is enough to restart before pixels 
start to degrade. On an LCD that is not so much time, but on an OLED it 
could be 10 secs :). Anyway, we have had several mass products with this 
soft solution and it has worked well.

In OMAP you can configure the DSI pins quite freely. We have the
following struct:

struct omap_dsi_pin_config {
  int num_pins;
  /*
   * pin numbers in the following order:
   * clk+, clk-
   * data1+, data1-
   * data2+, data2-
   * ...
   */
  int pins[OMAP_DSS_MAX_DSI_PINS];
};


I think it still is OMAP specifics and doesn't belong in the panel
drivers any longer. If you revisit this requirement in the CDF context
where DSI ifc parameters should describe how to interface with a panel
outside the SoC, there can't really be any dependencies on SoC internal
routing. As you say, this is inside pinmux, so how can that affect the
SoC external interface? I would suggest moving this to dispc-dsilink DT
settings that are activated on dsilink-enable/disable. At least that is
how I plan to solve similar STE SoC specific DSI config settings that
are not really CDF panel generic, like some DPhy trim settings. They do
depend on the panel and clock speed, but they are more product specific
than panel driver specific. Then if there are these type of settings
that every SoC have, then we could look at standardize those. But for
starters I would try to keep it in product/board-DT per DSI link. So we
should try to differentiate between DSI host and slave bus params and
keep slave params in panel driver.

Ok, I think I was being a bit vague here. I explained the OMAP DSI
routing not because I meant that this API is specific to that, but
because it explains why this kind of routing info is needed, and a
bitmask is not enough.

If you look at the omap_dsi_pin_config struct, there's nothing OMAP
specific there (except the names =). All it tells is that this device
uses N DSI pins, and the device's clk+ function should be connected to
pin X on the DSI master, clk- should be connected to pin Y, etc. X and Y
are integers, and what they mean is specific to the DSI master.

When the DSI master is OMAP's DSI, the OMAP DSI driver does the pin
configuration as I explained. When the DSI master is something else,
say, a DSI bridge, it does whatever it needs to do (which could be
nothing) to assign a particular DSI function to a pin.

I understand, but removing the omap prefix doesn't mean it has to go in 
the panel slave port/bus settings. I still can't see why this should be 
configuration on the panel driver and not the DSI master driver. Number 
of pins might be useful since you might start with one lane and then 
activate the rest. But partial muxing (pre pinmux) doesn't seem to be 
something the panel should control or know anything about. Sounds like 
normal platform/DT data per product/board.


/BR
/Marcus

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

[RFC PATCH 0/4] Common Display Framework-TF

[Tomasz Figa]

Hi Laurent,

On Saturday 02 of February 2013 11:39:59 Laurent Pinchart wrote:
> Hi Tomasz,
> 
> Thank you for your RFC.
> 
> On Wednesday 30 January 2013 16:38:59 Tomasz Figa wrote:
> > Hi,
> > 
> > After pretty long time of trying to adapt Exynos-specific DSI display
> > support to Common Display Framework I'm ready to show some preliminary
> > RFC patches. This series shows some ideas for CDF that came to my
> > mind during my work, some changes based on comments received by
> > Tomi's edition of CDF and also preliminarys version of Exynos DSI
> > (video source part only, still with some FIXMEs) and Samsung S6E8AX0
> > DSI panel drivers.
> > 
> > It is heavily based on Tomi's work which can be found here:
> > http://thread.gmane.org/gmane.comp.video.dri.devel/78227
> > 
> > The code might be a bit hacky in places, as I wanted to get it to a
> > kind of complete and working state first. However I hope that some of
> > the ideas might useful for further works.
> > 
> > So, here comes the TF edition of Common Clock Framework.
> > 
> > 
> > Changes done to Tomi's edition of CDF:
> >  - Replaced set_operation_mode, set_pixel_format and set_size video
> >  source>  
> >operations with get_params display entity operation, as it was
> >originally in Laurent's version.
> >
> >We have discussed this matter on the mailing list and decided that
> >it
> >would be better to have the source ask the sink for its parameter
> >structure and do whatever appropriate with it.
> 
> Could you briefly outline the rationale behind this ?

Display interfaces may be described by an arbitrary number of parameters. 
Some will require just video timings, others like DSI will require a 
significant number of additional bus-specific ones.

Separating all the parameters (all of which are usually set at the same 
time) into a lot of ops setting single parameter will just add unnecessary 
complexity.

> I'm wondering whether get_params could limit us if a device needs to
> modify parameters at runtime. For instance a panel might need to change
> clock frequencies or number of used data lane depending on various
> runtime conditions. I don't have a real use case here, so it might just
> be a bit of over-engineering.

Hmm, isn't it in the opposite direction (the user requests the display 
interface to change, for example, video mode, which in turn reconfigures 
the link and requests the panel to update its settings)?

However it might be reasonable to split the parameters into constant and 
variable ones. In case of DSI bus, there is a lot of parameters that are 
considered just at link initialization time (the whole dsi params struct I 
defined). Video mode, however, is a variable parameter that can be changed 
on some displays.

> 
> >  - Defined a preliminary set of DSI bus parameters.
> >  
> >Following parameters are defined:
> >
> >1. Pixel format used for video data transmission.
> >
> >2. Mode flags (several bit flags ORed together):
> >  a) DSI_MODE_VIDEO - entity uses video mode (as opposed to command
> >  
> > mode), following DSI_MODE_VIDEO_* flags are relevant only if
> > this
> > flag is set.
> > b) DSI_MODE_VIDEO_BURST - entity uses burst transfer for video
> > data
> > c) DSI_MODE_VIDEO_SYNC_PULSE - entity uses sync pulses (as
> > opposed
> > 
> >to sync events)
> > 
> > d) DSI_MODE_VIDEO_AUTO_VERT - entity uses automatic video mode
> > 
> >detection
> > 
> > e) DSI_MODE_VIDEO_HSE - entity needs horizontal sync end
> > packets
> > f) DSI_MODE_VIDEO_HFP - entity needs horizontal front porch
> > area
> > g) DSI_MODE_VIDEO_HBP - entity needs horizontal back porch
> > area
> > h) DSI_MODE_VIDEO_HSA - entity needs horizontal sync active
> > area
> >  
> >  i) DSI_MODE_VSYNC_FLUSH - vertical sync pulse flushes video data
> >  j) DSI_MODE_EOT_PACKET - entity needs EoT packets
> >
> >3. Bit (serial) clock frequency in HS mode.
> >4. Escape mode clock frequency.
> >5. Mask of used data lanes (each bit represents single lane).
> 
> From my experience with MIPI CSI (Camera Serial Interface, similar to
> DSI) some transceivers can reroute data lanes internally. Is that true
> for DSI as well ? In that case we would need a list of data lanes, not
> just a mask.

Hmm, I don't remember at the moment, will have to look to the 
specification. Exynos DSI master doesn't support such feature.

> >6. Command allow area in video mode - amount of lines after
> >transmitting>
> >   video data when generic commands are accepted.
> >
> >Feel free to suggest anything missing or wrong, as the list of
> >parameters is based merely on what was used in original Exynos MIPI
> >DSIM driver.
> >  
> >  - 

Re: [RFC PATCH 0/4] Common Display Framework-TF

[Tomasz Figa]

Hi Laurent,

On Saturday 02 of February 2013 11:39:59 Laurent Pinchart wrote:
 Hi Tomasz,
 
 Thank you for your RFC.
 
 On Wednesday 30 January 2013 16:38:59 Tomasz Figa wrote:
  Hi,
  
  After pretty long time of trying to adapt Exynos-specific DSI display
  support to Common Display Framework I'm ready to show some preliminary
  RFC patches. This series shows some ideas for CDF that came to my
  mind during my work, some changes based on comments received by
  Tomi's edition of CDF and also preliminarys version of Exynos DSI
  (video source part only, still with some FIXMEs) and Samsung S6E8AX0
  DSI panel drivers.
  
  It is heavily based on Tomi's work which can be found here:
  http://thread.gmane.org/gmane.comp.video.dri.devel/78227
  
  The code might be a bit hacky in places, as I wanted to get it to a
  kind of complete and working state first. However I hope that some of
  the ideas might useful for further works.
  
  So, here comes the TF edition of Common Clock Framework.
  
  
  Changes done to Tomi's edition of CDF:
   - Replaced set_operation_mode, set_pixel_format and set_size video
   source  
 operations with get_params display entity operation, as it was
 originally in Laurent's version.
 
 We have discussed this matter on the mailing list and decided that
 it
 would be better to have the source ask the sink for its parameter
 structure and do whatever appropriate with it.
 
 Could you briefly outline the rationale behind this ?

Display interfaces may be described by an arbitrary number of parameters. 
Some will require just video timings, others like DSI will require a 
significant number of additional bus-specific ones.

Separating all the parameters (all of which are usually set at the same 
time) into a lot of ops setting single parameter will just add unnecessary 
complexity.

 I'm wondering whether get_params could limit us if a device needs to
 modify parameters at runtime. For instance a panel might need to change
 clock frequencies or number of used data lane depending on various
 runtime conditions. I don't have a real use case here, so it might just
 be a bit of over-engineering.

Hmm, isn't it in the opposite direction (the user requests the display 
interface to change, for example, video mode, which in turn reconfigures 
the link and requests the panel to update its settings)?

However it might be reasonable to split the parameters into constant and 
variable ones. In case of DSI bus, there is a lot of parameters that are 
considered just at link initialization time (the whole dsi params struct I 
defined). Video mode, however, is a variable parameter that can be changed 
on some displays.

 
   - Defined a preliminary set of DSI bus parameters.
   
 Following parameters are defined:
 
 1. Pixel format used for video data transmission.
 
 2. Mode flags (several bit flags ORed together):
   a) DSI_MODE_VIDEO - entity uses video mode (as opposed to command
   
  mode), following DSI_MODE_VIDEO_* flags are relevant only if
  this
  flag is set.
  b) DSI_MODE_VIDEO_BURST - entity uses burst transfer for video
  data
  c) DSI_MODE_VIDEO_SYNC_PULSE - entity uses sync pulses (as
  opposed
  
 to sync events)
  
  d) DSI_MODE_VIDEO_AUTO_VERT - entity uses automatic video mode
  
 detection
  
  e) DSI_MODE_VIDEO_HSE - entity needs horizontal sync end
  packets
  f) DSI_MODE_VIDEO_HFP - entity needs horizontal front porch
  area
  g) DSI_MODE_VIDEO_HBP - entity needs horizontal back porch
  area
  h) DSI_MODE_VIDEO_HSA - entity needs horizontal sync active
  area
   
   i) DSI_MODE_VSYNC_FLUSH - vertical sync pulse flushes video data
   j) DSI_MODE_EOT_PACKET - entity needs EoT packets
 
 3. Bit (serial) clock frequency in HS mode.
 4. Escape mode clock frequency.
 5. Mask of used data lanes (each bit represents single lane).
 
 From my experience with MIPI CSI (Camera Serial Interface, similar to
 DSI) some transceivers can reroute data lanes internally. Is that true
 for DSI as well ? In that case we would need a list of data lanes, not
 just a mask.

Hmm, I don't remember at the moment, will have to look to the 
specification. Exynos DSI master doesn't support such feature.

 6. Command allow area in video mode - amount of lines after
 transmitting
video data when generic commands are accepted.
 
 Feel free to suggest anything missing or wrong, as the list of
 parameters is based merely on what was used in original Exynos MIPI
 DSIM driver.
   
   - Redesigned source-entity matching.
   
 Now each source has name string and integer id and each entity has
 source name and source id. In addition, they can have of_node

[RFC PATCH 0/4] Common Display Framework-TF

[Laurent Pinchart]

Hi Tomasz,

Thank you for your RFC.

On Wednesday 30 January 2013 16:38:59 Tomasz Figa wrote:
> Hi,
> 
> After pretty long time of trying to adapt Exynos-specific DSI display
> support to Common Display Framework I'm ready to show some preliminary RFC
> patches. This series shows some ideas for CDF that came to my mind during
> my work, some changes based on comments received by Tomi's edition of CDF
> and also preliminarys version of Exynos DSI (video source part only, still
> with some FIXMEs) and Samsung S6E8AX0 DSI panel drivers.
> 
> It is heavily based on Tomi's work which can be found here:
> http://thread.gmane.org/gmane.comp.video.dri.devel/78227
> 
> The code might be a bit hacky in places, as I wanted to get it to a kind
> of complete and working state first. However I hope that some of the ideas
> might useful for further works.
> 
> So, here comes the TF edition of Common Clock Framework.
> 
> 
> Changes done to Tomi's edition of CDF:
> 
>  - Replaced set_operation_mode, set_pixel_format and set_size video source
>operations with get_params display entity operation, as it was originally
>in Laurent's version.
> 
>We have discussed this matter on the mailing list and decided that it
>would be better to have the source ask the sink for its parameter
>structure and do whatever appropriate with it.

Could you briefly outline the rationale behind this ?

I'm wondering whether get_params could limit us if a device needs to modify 
parameters at runtime. For instance a panel might need to change clock 
frequencies or number of used data lane depending on various runtime 
conditions. I don't have a real use case here, so it might just be a bit of 
over-engineering.

>  - Defined a preliminary set of DSI bus parameters.
> 
>Following parameters are defined:
> 
>1. Pixel format used for video data transmission.
>2. Mode flags (several bit flags ORed together):
>  a) DSI_MODE_VIDEO - entity uses video mode (as opposed to command
> mode), following DSI_MODE_VIDEO_* flags are relevant only if this
> flag is set.
> b) DSI_MODE_VIDEO_BURST - entity uses burst transfer for video data
> c) DSI_MODE_VIDEO_SYNC_PULSE - entity uses sync pulses (as opposed
>to sync events)
> d) DSI_MODE_VIDEO_AUTO_VERT - entity uses automatic video mode
>detection
> e) DSI_MODE_VIDEO_HSE - entity needs horizontal sync end packets
> f) DSI_MODE_VIDEO_HFP - entity needs horizontal front porch area
> g) DSI_MODE_VIDEO_HBP - entity needs horizontal back porch area
> h) DSI_MODE_VIDEO_HSA - entity needs horizontal sync active area
>  i) DSI_MODE_VSYNC_FLUSH - vertical sync pulse flushes video data
>  j) DSI_MODE_EOT_PACKET - entity needs EoT packets
>3. Bit (serial) clock frequency in HS mode.
>4. Escape mode clock frequency.
>5. Mask of used data lanes (each bit represents single lane).

>From my experience with MIPI CSI (Camera Serial Interface, similar to DSI) 
some transceivers can reroute data lanes internally. Is that true for DSI as 
well ? In that case we would need a list of data lanes, not just a mask.

>6. Command allow area in video mode - amount of lines after transmitting
>   video data when generic commands are accepted.
> 
>Feel free to suggest anything missing or wrong, as the list of
>parameters is based merely on what was used in original Exynos MIPI
>DSIM driver.
> 
>  - Redesigned source-entity matching.
> 
>Now each source has name string and integer id and each entity has
>source name and source id. In addition, they can have of_node specified,
>which is used for Device Tree-based matching.
> 
>The matching procedure is as follows:
> 
>1. Matching takes place when display entity registers.
>  a) If there is of_node specified for the entity then "video-source"
> phandle of this node is being parsed and list of registered sources
> is traversed in search of a source with of_node received from
> parsing the phandle.
>  b) Otherwise the matching key is a pair of source name and id.
>2. If no matching source is found, display_entity_register returns
>   -EPROBE_DEFER error which causes the entity driver to defer its
>   probe until the source registers.
>3. Otherwise an optional bind operation of video source is called,
>   sink field of source and source field of entity are set and the
>   matching ends successfully.
> 
>  - Some initial concept of source-entity cross-locking.
> 
>Only video source is protected at the moment, as I still have to think
>a bit about locking the entity in a way where removing it by user request
>is still possible.

One of the main locking issues here are cross-references. The display entity 
holds a reference to the video source (for video operations), and the display 

Re: [RFC PATCH 0/4] Common Display Framework-TF

[Laurent Pinchart]

Hi Tomasz,

Thank you for your RFC.

On Wednesday 30 January 2013 16:38:59 Tomasz Figa wrote:
 Hi,
 
 After pretty long time of trying to adapt Exynos-specific DSI display
 support to Common Display Framework I'm ready to show some preliminary RFC
 patches. This series shows some ideas for CDF that came to my mind during
 my work, some changes based on comments received by Tomi's edition of CDF
 and also preliminarys version of Exynos DSI (video source part only, still
 with some FIXMEs) and Samsung S6E8AX0 DSI panel drivers.
 
 It is heavily based on Tomi's work which can be found here:
 http://thread.gmane.org/gmane.comp.video.dri.devel/78227
 
 The code might be a bit hacky in places, as I wanted to get it to a kind
 of complete and working state first. However I hope that some of the ideas
 might useful for further works.
 
 So, here comes the TF edition of Common Clock Framework.
 
 
 Changes done to Tomi's edition of CDF:
 
  - Replaced set_operation_mode, set_pixel_format and set_size video source
operations with get_params display entity operation, as it was originally
in Laurent's version.
 
We have discussed this matter on the mailing list and decided that it
would be better to have the source ask the sink for its parameter
structure and do whatever appropriate with it.

Could you briefly outline the rationale behind this ?

I'm wondering whether get_params could limit us if a device needs to modify 
parameters at runtime. For instance a panel might need to change clock 
frequencies or number of used data lane depending on various runtime 
conditions. I don't have a real use case here, so it might just be a bit of 
over-engineering.

  - Defined a preliminary set of DSI bus parameters.
 
Following parameters are defined:
 
1. Pixel format used for video data transmission.
2. Mode flags (several bit flags ORed together):
  a) DSI_MODE_VIDEO - entity uses video mode (as opposed to command
 mode), following DSI_MODE_VIDEO_* flags are relevant only if this
 flag is set.
 b) DSI_MODE_VIDEO_BURST - entity uses burst transfer for video data
 c) DSI_MODE_VIDEO_SYNC_PULSE - entity uses sync pulses (as opposed
to sync events)
 d) DSI_MODE_VIDEO_AUTO_VERT - entity uses automatic video mode
detection
 e) DSI_MODE_VIDEO_HSE - entity needs horizontal sync end packets
 f) DSI_MODE_VIDEO_HFP - entity needs horizontal front porch area
 g) DSI_MODE_VIDEO_HBP - entity needs horizontal back porch area
 h) DSI_MODE_VIDEO_HSA - entity needs horizontal sync active area
  i) DSI_MODE_VSYNC_FLUSH - vertical sync pulse flushes video data
  j) DSI_MODE_EOT_PACKET - entity needs EoT packets
3. Bit (serial) clock frequency in HS mode.
4. Escape mode clock frequency.
5. Mask of used data lanes (each bit represents single lane).

From my experience with MIPI CSI (Camera Serial Interface, similar to DSI) 
some transceivers can reroute data lanes internally. Is that true for DSI as 
well ? In that case we would need a list of data lanes, not just a mask.

6. Command allow area in video mode - amount of lines after transmitting
   video data when generic commands are accepted.
 
Feel free to suggest anything missing or wrong, as the list of
parameters is based merely on what was used in original Exynos MIPI
DSIM driver.
 
  - Redesigned source-entity matching.
 
Now each source has name string and integer id and each entity has
source name and source id. In addition, they can have of_node specified,
which is used for Device Tree-based matching.
 
The matching procedure is as follows:
 
1. Matching takes place when display entity registers.
  a) If there is of_node specified for the entity then video-source
 phandle of this node is being parsed and list of registered sources
 is traversed in search of a source with of_node received from
 parsing the phandle.
  b) Otherwise the matching key is a pair of source name and id.
2. If no matching source is found, display_entity_register returns
   -EPROBE_DEFER error which causes the entity driver to defer its
   probe until the source registers.
3. Otherwise an optional bind operation of video source is called,
   sink field of source and source field of entity are set and the
   matching ends successfully.
 
  - Some initial concept of source-entity cross-locking.
 
Only video source is protected at the moment, as I still have to think
a bit about locking the entity in a way where removing it by user request
is still possible.

One of the main locking issues here are cross-references. The display entity 
holds a reference to the video source (for video operations), and the display 
controller driver holds a reference to the display entity (for control 
operations), resulting 

[RFC PATCH 0/4] Common Display Framework-TF

[Tomasz Figa]

Hi,

After pretty long time of trying to adapt Exynos-specific DSI display support
to Common Display Framework I'm ready to show some preliminary RFC patches.
This series shows some ideas for CDF that came to my mind during my work,
some changes based on comments received by Tomi's edition of CDF and also
preliminarys version of Exynos DSI (video source part only, still with some
FIXMEs) and Samsung S6E8AX0 DSI panel drivers.

It is heavily based on Tomi's work which can be found here:
http://thread.gmane.org/gmane.comp.video.dri.devel/78227

The code might be a bit hacky in places, as I wanted to get it to a kind
of complete and working state first. However I hope that some of the ideas
might useful for further works.

So, here comes the TF edition of Common Clock Framework.


Changes done to Tomi's edition of CDF:

 - Replaced set_operation_mode, set_pixel_format and set_size video source
   operations with get_params display entity operation, as it was originally
   in Laurent's version.

   We have discussed this matter on the mailing list
   and decided that it would be better to have the source ask the sink for
   its parameter structure and do whatever appropriate with it.

 - Defined a preliminary set of DSI bus parameters.

   Following parameters are defined:

   1. Pixel format used for video data transmission.
   2. Mode flags (several bit flags ORed together):
 a) DSI_MODE_VIDEO - entity uses video mode (as opposed to command mode),
following DSI_MODE_VIDEO_* flags are relevant only if this flag is set.
b) DSI_MODE_VIDEO_BURST - entity uses burst transfer for video data
c) DSI_MODE_VIDEO_SYNC_PULSE - entity uses sync pulses (as opposed
   to sync events)
d) DSI_MODE_VIDEO_AUTO_VERT - entity uses automatic video mode
   detection
e) DSI_MODE_VIDEO_HSE - entity needs horizontal sync end packets
f) DSI_MODE_VIDEO_HFP - entity needs horizontal front porch area
g) DSI_MODE_VIDEO_HBP - entity needs horizontal back porch area
h) DSI_MODE_VIDEO_HSA - entity needs horizontal sync active area
 i) DSI_MODE_VSYNC_FLUSH - vertical sync pulse flushes video data
 j) DSI_MODE_EOT_PACKET - entity needs EoT packets
   3. Bit (serial) clock frequency in HS mode.
   4. Escape mode clock frequency.
   5. Mask of used data lanes (each bit represents single lane).
   6. Command allow area in video mode - amount of lines after transmitting
  video data when generic commands are accepted.

   Feel free to suggest anything missing or wrong, as the list of
   parameters is based merely on what was used in original Exynos MIPI
   DSIM driver.

 - Redesigned source-entity matching.

   Now each source has name string and integer id and each entity has
   source name and source id. In addition, they can have of_node specified,
   which is used for Device Tree-based matching.

   The matching procedure is as follows:

   1. Matching takes place when display entity registers.
 a) If there is of_node specified for the entity then "video-source"
phandle of this node is being parsed and list of registered sources
is traversed in search of a source with of_node received from
parsing the phandle.
 b) Otherwise the matching key is a pair of source name and id.
   2. If no matching source is found, display_entity_register returns
  -EPROBE_DEFER error which causes the entity driver to defer its
  probe until the source registers.
   3. Otherwise an optional bind operation of video source is called,
  sink field of source and source field of entity are set and the
  matching ends successfully.

 - Some initial concept of source-entity cross-locking.

   Only video source is protected at the moment, as I still have to think
   a bit about locking the entity in a way where removing it by user request
   is still possible.

 - Dropped any panels and chips that I can't test.

   They are irrelevant for this series, so there is no point in including them.

 - Added Exynos DSI video source driver.

   This is a new driver for the DSI controller found in Exynos SoCs. It still
   needs some work, but in current state can be considered an example of DSI
   video source implementation for my version of CDF.

 - Added Samsung S6E8AX0 DSI panel driver.

   This is the old Exynos-specific driver, just migrated to CDF and with
   some hacks to provide control over entity state to userspace using
   lcd device. However it can be used to demonstrate video source ops in use.

Feel free to comment as much as you can.

Tomasz Figa (4):
  video: add display-core
  video: add makefile & kconfig
  video: display: Add exynos-dsi video source driver
  video: display: Add Samsung s6e8ax0 display panel driver

 drivers/video/Kconfig |1 +
 drivers/video/Makefile|1 +
 drivers/video/display/Kconfig |   16 

[RFC PATCH 0/4] Common Display Framework-TF

[Tomasz Figa]

Hi,

After pretty long time of trying to adapt Exynos-specific DSI display support
to Common Display Framework I'm ready to show some preliminary RFC patches.
This series shows some ideas for CDF that came to my mind during my work,
some changes based on comments received by Tomi's edition of CDF and also
preliminarys version of Exynos DSI (video source part only, still with some
FIXMEs) and Samsung S6E8AX0 DSI panel drivers.

It is heavily based on Tomi's work which can be found here:
http://thread.gmane.org/gmane.comp.video.dri.devel/78227

The code might be a bit hacky in places, as I wanted to get it to a kind
of complete and working state first. However I hope that some of the ideas
might useful for further works.

So, here comes the TF edition of Common Clock Framework.


Changes done to Tomi's edition of CDF:

 - Replaced set_operation_mode, set_pixel_format and set_size video source
   operations with get_params display entity operation, as it was originally
   in Laurent's version.

   We have discussed this matter on the mailing list
   and decided that it would be better to have the source ask the sink for
   its parameter structure and do whatever appropriate with it.

 - Defined a preliminary set of DSI bus parameters.

   Following parameters are defined:

   1. Pixel format used for video data transmission.
   2. Mode flags (several bit flags ORed together):
 a) DSI_MODE_VIDEO - entity uses video mode (as opposed to command mode),
following DSI_MODE_VIDEO_* flags are relevant only if this flag is set.
b) DSI_MODE_VIDEO_BURST - entity uses burst transfer for video data
c) DSI_MODE_VIDEO_SYNC_PULSE - entity uses sync pulses (as opposed
   to sync events)
d) DSI_MODE_VIDEO_AUTO_VERT - entity uses automatic video mode
   detection
e) DSI_MODE_VIDEO_HSE - entity needs horizontal sync end packets
f) DSI_MODE_VIDEO_HFP - entity needs horizontal front porch area
g) DSI_MODE_VIDEO_HBP - entity needs horizontal back porch area
h) DSI_MODE_VIDEO_HSA - entity needs horizontal sync active area
 i) DSI_MODE_VSYNC_FLUSH - vertical sync pulse flushes video data
 j) DSI_MODE_EOT_PACKET - entity needs EoT packets
   3. Bit (serial) clock frequency in HS mode.
   4. Escape mode clock frequency.
   5. Mask of used data lanes (each bit represents single lane).
   6. Command allow area in video mode - amount of lines after transmitting
  video data when generic commands are accepted.

   Feel free to suggest anything missing or wrong, as the list of
   parameters is based merely on what was used in original Exynos MIPI
   DSIM driver.

 - Redesigned source-entity matching.

   Now each source has name string and integer id and each entity has
   source name and source id. In addition, they can have of_node specified,
   which is used for Device Tree-based matching.

   The matching procedure is as follows:

   1. Matching takes place when display entity registers.
 a) If there is of_node specified for the entity then video-source
phandle of this node is being parsed and list of registered sources
is traversed in search of a source with of_node received from
parsing the phandle.
 b) Otherwise the matching key is a pair of source name and id.
   2. If no matching source is found, display_entity_register returns
  -EPROBE_DEFER error which causes the entity driver to defer its
  probe until the source registers.
   3. Otherwise an optional bind operation of video source is called,
  sink field of source and source field of entity are set and the
  matching ends successfully.

 - Some initial concept of source-entity cross-locking.

   Only video source is protected at the moment, as I still have to think
   a bit about locking the entity in a way where removing it by user request
   is still possible.

 - Dropped any panels and chips that I can't test.

   They are irrelevant for this series, so there is no point in including them.

 - Added Exynos DSI video source driver.

   This is a new driver for the DSI controller found in Exynos SoCs. It still
   needs some work, but in current state can be considered an example of DSI
   video source implementation for my version of CDF.

 - Added Samsung S6E8AX0 DSI panel driver.

   This is the old Exynos-specific driver, just migrated to CDF and with
   some hacks to provide control over entity state to userspace using
   lcd device. However it can be used to demonstrate video source ops in use.

Feel free to comment as much as you can.

Tomasz Figa (4):
  video: add display-core
  video: add makefile  kconfig
  video: display: Add exynos-dsi video source driver
  video: display: Add Samsung s6e8ax0 display panel driver

 drivers/video/Kconfig |1 +
 drivers/video/Makefile|1 +
 drivers/video/display/Kconfig |   16 +