* Re: [PATCH 2/3] video: xilinxfb: Use devm_kzalloc instead of kzalloc
From: Jingoo Han @ 2013-09-12 10:42 UTC (permalink / raw)
To: 'Michal Simek', linux-kernel, monstr
Cc: 'Jean-Christophe Plagniol-Villard',
'Tomi Valkeinen', linux-fbdev, 'Jingoo Han'
In-Reply-To: <f9868e54718ba467691085ff78061a447eef3635.1378965270.git.michal.simek@xilinx.com>
On Thursday, September 12, 2013 2:55 PM, Michal Simek wrote:
>
> Simplify driver probe and release function.
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Jingoo Han <jg1.han@samsung.com>
> ---
> drivers/video/xilinxfb.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
^ permalink raw reply
* Re: [PATCH 3/3] video: xilinxfb: Simplify error path
From: Jingoo Han @ 2013-09-12 10:46 UTC (permalink / raw)
To: 'Michal Simek', linux-kernel, monstr
Cc: 'Jean-Christophe Plagniol-Villard',
'Tomi Valkeinen', linux-fbdev, 'Jingoo Han'
In-Reply-To: <940bbdfc5c67282ab461b9c82b55f18fc34c959d.1378965270.git.michal.simek@xilinx.com>
On Thursday, September 12, 2013 2:55 PM, Michal Simek wrote:
>
> devm_iounmap is called automatically that's why remove it from the code
> dev_set_drvdata(dev, NULL) is called by generic code
> after device_release or on probe failure.
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Jingoo Han <jg1.han@samsung.com>
> ---
> drivers/video/xilinxfb.c | 28 ++++++----------------------
> 1 file changed, 6 insertions(+), 22 deletions(-)
^ permalink raw reply
* Re: [PATCH v2 1/2] video: ARM CLCD: Add DT support
From: Pawel Moll @ 2013-09-12 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5230AAEB.2030607@wwwdotorg.org>
On Wed, 2013-09-11 at 18:39 +0100, Stephen Warren wrote:
> > From the core's perspective it's just a bit of extra memory, you could,
> > for example, put a MTD ram disk on it. It seems to deserve a
> > representation in the tree then.
>
> Yes, that's a good point. Perhaps it is reasonable to represent the
> memory somewhere then.
>
> I don't see why this memory couldn't exist in the regular /memory node;
> it is after all (admittedly slow) RAM. Obviously you'd want to cover the
> region with a /memreserve/ to avoid it being used just like any other
> RAM.
This would be pretty tricky in my particular case... The sram chip lives
on a motherboard, which lives behind a static memory interface (Chip
Select + offset). And the memreserve can only take "top level" address,
which can be different depending on the test chip (SoC) or FPGA SMM
being used.
> Perhaps the CLCD could reference the memreserve then?
How do you mean reference the memreserve? It's not a node, I don't think you can get
a phandle to it...
> Alternatively, if you want to represent the region as a regular node
> rather than a /memory entry, I'd expect there to be a binding defining
> what that node was, and the node to at least have a compatible value as
> well. I'm not sure how you would indicate that the node should be MTD
> vs. a resource for CLCD though; perhaps you'd use a different compatible
> value depending on the intended use of the memory?
Yes, that's exactly what I have now:
psram@1,00000000 {
compatible = "arm,vexpress-psram", "mtd-ram";
reg = <1 0x00000000 0x02000000>;
bank-width = <4>;
};
vram@2,00000000 {
compatible = "arm,vexpress-vram";
reg = <2 0x00000000 0x00800000>;
};
which allows mtd to use the psram.
> >> I'm not sure what the benefit of making this a standalone node is; why
> >> not just put the base/size directly into the video-ram property in the
> >> CLCD node?
> >
> > This is certainly an option. I've considered this as well, but thought
> > that the above made more sense.
> >
> > Having said that, there is actually a use case, although a very
> > non-probable one, for having a direct number there... The interconnect
> > that CLCD is connected to could have different mapping than the
> > processor's one. In other word, the memory seen by the core at X, could
> > be accessed by the CLCD at Y. Or, in even more quirky situation, the
> > core may not have access to the memory at all, with the graphics being
> > generated only by GPU (or any other third party). Then the value would
> > mean "the address you have to use when generating AMBA read transactions
> > to be get some meaningful data" and would have to be known explicitly.
> >
> > I guess it won't be hard to convince me it's a better option ;-)
>
> That's true. Everything in DT is currently set up to describe the CPU's
> memory map. Either we need to add some more properties to describe the
> potentially different memory map for other bus masters, and/or we should
> represent the various buses in DT, and any driver doing DMA should ask
> each bus's driver in turn to translate the core-visible address to a bus
> address so we can eventually end up with the address needed by the bus
> masters.
>
> That is indeed complex, and could at least in many situations simple be
> short-circuited by putting the relevant base address in each other bus
> master's own node/property. Hopefully we wouldn't get bitten by how
> non-general that could be.
Ok, so I'll make it a arm,pl11x,specific property. Actually two
properties - one bit I missed was the dual STN panel case, where they
have separate frame buffers. Something along the lines of:
Optional:
- arm,pl11x,framebuffer-base: a pair of two values, address and size,
defining the framebuffer for the upper
(or the only one) panel
- arm,pl11x,lower-framebuffer-base: as above, for the lower STN panel,
when present
Being very hardware-specific, it covers all possible quirky scenarios,
at the same time does not exclude the option of using the CMA region
phandles, if a particular system needed it.
> > - max-memory-bandwidth: maximum bandwidth in bytes per second that the
> > cell's memory interface can handle
> >
> > and can be then used to calculate maximum bpp depending on the selected
> > mode.
>
> Yes, that's a better property definition.
Ok, I'll go that way then. Whether derived from the system design
characteristics or by "hands on experiments", seems hardware-y enough.
> >>> +- display-timings: standard display timings sub-node, see
> >>> + Documentation/devicetree/bindings/video/display-timing.txt
> >>
> >> Should that be in a "Required sub-nodes" section (I assume required not
> >> optional) rather than "Optional Properties"?
> >
> > Right, the whole "panel" section is kept separately in a hope that CDF
> > (or DRM or whatever ;-) generic display pipeline bindings will deprecate
> > it. So the display-timings is required when optional panel properties
> > are present. Maybe I should split them into a separate sub-node?
> > Something along these lines (including the bandwidth example):
>
> I would assume that TFT-vs-STN is a pretty direct representation of the
> HW (IO bus to panel in particular), and hence wouldn't be replaced by
> CDF? I would expect CDF to represent the more generic properties. But, I
> haven't been following CDF too closely, so perhaps that's not true.
I'm not expecting CDF *bindings* to carry this information, no. I'm
expecting CDF core to provide me with this data in runtime (here's the
panel; what kind of panel are you? what modes do you provide? etc.) and
this is what my initial experiments used. The CLCD node only had the
video-ram and bandwidth-like properties plus a phandle to the display.
> If you're expecting this binding to change if/when CDF appears, perhaps
> it'd be better to wait for CDF, or plan for a new compatible property at
> that time, or add some property indicating old-style configuration vs
> new-style configuration once CDF is supported?
I'm expecting the panel description inside the CLCD node to be
deprecated, not changed, by the mythical CDF. As to waiting for it...
well. It's been over a year since first proposal ("generic panel
framework" as was it called then ;-). And over 2 years since VE gained
"DT support except for CLCD, which should be ready soon" ;-) And than 2
or 3 new platforms had to keep auxdata only for CLCD's sake. So, sure -
we can wait :-)
Paweł
^ permalink raw reply
* Re: [PATCH v2 1/2] video: ARM CLCD: Add DT support
From: Stephen Warren @ 2013-09-12 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1378991033.13571.33.camel@hornet>
On 09/12/2013 07:03 AM, Pawel Moll wrote:
> On Wed, 2013-09-11 at 18:39 +0100, Stephen Warren wrote:
...
>> Perhaps the CLCD could reference the memreserve then?
>
> How do you mean reference the memreserve? It's not a node, I don't think you can get
> a phandle to it...
Perhaps it's an extension that hasn't actually been implemented yet. I
thought I saw some reference to it in some long-past discussions. It's
possible that this feature has been dropped in preference to the "CMA"
bindings for defining reserved memory regions?
...
> Ok, so I'll make it a arm,pl11x,specific property. Actually two
> properties - one bit I missed was the dual STN panel case, where they
> have separate frame buffers. Something along the lines of:
>
> Optional:
>
> - arm,pl11x,framebuffer-base: a pair of two values, address and size,
> defining the framebuffer for the upper
> (or the only one) panel
> - arm,pl11x,lower-framebuffer-base: as above, for the lower STN panel,
> when present
>
> Being very hardware-specific, it covers all possible quirky scenarios,
> at the same time does not exclude the option of using the CMA region
> phandles, if a particular system needed it.
What do "upper" and "lower" mean in this context? I assume this somehow
refers to placement of the displays on the board. If so, it sounds like
there should be some better terminology; something that's specific to
the CLCD controller itself, rather than the environment it's used in.
Aalthough it does sound like this is in an FPGA and hence the controller
is board-specific, but I don't see why it couldn't be re-used in some
other FPGA-based board with different panel layout. Would "A" and "B" or
"main" and "primary" or "first" and "second" work better?
^ permalink raw reply
* Re: [PATCH 1/2] video: ARM CLCD: Add DT support
From: Pawel Moll @ 2013-09-12 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5230DD1C.6060606@gmail.com>
On Wed, 2013-09-11 at 22:14 +0100, Sylwester Nawrocki wrote:
> Yes, I wasn't aware then that your "video RAM" is a separate chip attached
> to a distinct bus.
> My idea was to reuse memory node structure, including "reserved-memory"
> compatible value (note there are some fixups pending and those names are
> subject to change). Not sure about the property in CLCD device node
> containing phandle to the memory node (currently 'memory-region').
As I just told Steven, I'll just make it painfully low-level property
defining "address you have to generate to access base of the
framebuffer". Of course one can still go the CMA way, if such need
arises.
> > Ok, I see what you're saying. Yes, this could be done. No, I don't claim
> > to have enough expertise either (micrometers??? :-O ;-) The other thing
> > is that I don't really expect generic CDF bindings to cover such things.
> > They will (hopefully) only describe what's connected with what. And the
> > drivers should know how. Of course they may need the dimensions& alike
> > in the tree (of course having them standardised would help here), but
> > it's not a CDF job to provide those.
>
> Of course it's always easier to define couple of DT properties that would
> cover part of functionality of some specific device. But then such
> properties should be prefixed with vendor name AFAIU, since they are
> not approved as common ones and useful for wider set of devices.
This is a policy that changed many times already...
Anyway, I think I've got an idea how to render the problem custom panel
properties invalid. If so, I'll send another version of the patch.
> From the device tree perspective CDF is just a collection of (display
> related) devices and a complete set of DT properties will be needed to
> describe them. Certainly some share of device-specific properties should
> be expected. Links between (sub)devices can be already described in DT by
> the binding documented in video-interfaces.txt.
Whether to use the v4l scheme or not still seems to be a bone of
contention between the video and the DRM/KMS folk, so I wouldn't draw
any conclusions yet.
Paweł
^ permalink raw reply
* Re: [PATCH v2 1/2] video: ARM CLCD: Add DT support
From: Pawel Moll @ 2013-09-12 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5231D5FA.4060508@wwwdotorg.org>
On Thu, 2013-09-12 at 15:55 +0100, Stephen Warren wrote:
> > Ok, so I'll make it a arm,pl11x,specific property. Actually two
> > properties - one bit I missed was the dual STN panel case, where they
> > have separate frame buffers. Something along the lines of:
> >
> > Optional:
> >
> > - arm,pl11x,framebuffer-base: a pair of two values, address and size,
> > defining the framebuffer for the upper
> > (or the only one) panel
> > - arm,pl11x,lower-framebuffer-base: as above, for the lower STN panel,
> > when present
> >
> > Being very hardware-specific, it covers all possible quirky scenarios,
> > at the same time does not exclude the option of using the CMA region
> > phandles, if a particular system needed it.
>
> What do "upper" and "lower" mean in this context? I assume this somehow
> refers to placement of the displays on the board. If so, it sounds like
> there should be some better terminology; something that's specific to
> the CLCD controller itself,
It is very CLCD specific indeed and nothing to do with the board :-)
http://arminfo.emea.arm.com/help/topic/com.arm.doc.ddi0293c/I899134.html
"Upper and Lower Panel Frame Base Address Registers".
> rather than the environment it's used in.
> Aalthough it does sound like this is in an FPGA and hence the controller
> is board-specific, but I don't see why it couldn't be re-used in some
> other FPGA-based board with different panel layout. Would "A" and "B" or
> "main" and "primary" or "first" and "second" work better?
Funnily enough I typed "secondary-framebuffer-base" first, but than
thought "no, let's match the spec" :-)
Paweł
^ permalink raw reply
* Re: [PATCH v2 1/2] video: ARM CLCD: Add DT support
From: Pawel Moll @ 2013-09-12 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1378999581.13571.57.camel@hornet>
On Thu, 2013-09-12 at 16:26 +0100, Pawel Moll wrote:
> http://arminfo.emea.arm.com/help/topic/com.arm.doc.ddi0293c/I899134.html
Sorry, should be:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0161e/I899134.html
Paweł
^ permalink raw reply
* Re: [PATCH v2 1/2] video: ARM CLCD: Add DT support
From: Russell King - ARM Linux @ 2013-09-12 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5230AAEB.2030607@wwwdotorg.org>
On Wed, Sep 11, 2013 at 11:39:55AM -0600, Stephen Warren wrote:
> I don't know how constrained of a system CLCD is, but I do know that
> mode validation is a very complex process in some real-life graphics
> drivers.
Apart from maximum memory bus bandwidth, probably maximum output
bandwidth, maximum resolution (determined by what will fit in the
registers and RAM) there aren't that much constraints. The hardware
block is quite simple in that regard.
More the problem is to deal with two situations:
1. you have a particular panel connected to it which requires a certain
fixed timing regime.
2. you have the CLCD connected to a VGA or HDMI connector where the
timing is dependent on the connected display.
The former would be the subject of some kind of *common* DT
representation of the timing requirements of the connected panel.
For the latter, DT needs to specify how the EDID data is retrieved,
or if there is no mechanism for that, being able to provide a set
of allowable timing parameters (such as min/max vsync, min/max
hsync, max dotclock - in other words, the data which used to be
provided to X11 in the past.)
None of that is specific to CLCD though: it's the same problem as
the SA11x0 LCD controller or any other scanned video controller.
^ permalink raw reply
* Re: [PATCH v2 1/2] video: ARM CLCD: Add DT support
From: Russell King - ARM Linux @ 2013-09-12 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5231D5FA.4060508@wwwdotorg.org>
On Thu, Sep 12, 2013 at 08:55:54AM -0600, Stephen Warren wrote:
> On 09/12/2013 07:03 AM, Pawel Moll wrote:
> > Ok, so I'll make it a arm,pl11x,specific property. Actually two
> > properties - one bit I missed was the dual STN panel case, where they
> > have separate frame buffers. Something along the lines of:
> >
> > Optional:
> >
> > - arm,pl11x,framebuffer-base: a pair of two values, address and size,
> > defining the framebuffer for the upper
> > (or the only one) panel
> > - arm,pl11x,lower-framebuffer-base: as above, for the lower STN panel,
> > when present
> >
> > Being very hardware-specific, it covers all possible quirky scenarios,
> > at the same time does not exclude the option of using the CMA region
> > phandles, if a particular system needed it.
>
> What do "upper" and "lower" mean in this context? I assume this somehow
> refers to placement of the displays on the board.
CLCD is only one controller - it can only produce one image from one
framebuffer.
What this refers to is a requirement for dual STN displays - rather
than starting at one corner and working logically to the opposite
corner, these start at one corner and half way through the display at
the same time. So you scan out the upper half of the image at the
same time that you scan out the lower half of the image.
In order to give an image on the display where the conventional formula
works:
address = start + y * bytes_per_line + x * bits_per_pixel / 8
this means that the "upper" and "lower" start addresses are related to
the parameters of the display - you want the lower half to start at
the address where y = panel_y_res / 2 and x = 0.
You may also wish to change the start address (if you have enough RAM)
to support page flipping - where you switch between two framebuffers -
one which is currently being displayed while the other is being updated
by the CPU. You would use this to provide smooth video playback for
example.
So, DT has no business directly encoding this information - it should
be calculated from the information provided by the panel and the
timings required, and all that the CLCD driver should know is that
"we have this RAM which starts here, and extends for N bytes" - or
to use system memory instead.
^ permalink raw reply
* Re: [PATCH 1/2] video: ARM CLCD: Add DT support
From: Pawel Moll @ 2013-09-12 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1378999425.13571.54.camel@hornet>
On Thu, 2013-09-12 at 16:23 +0100, Pawel Moll wrote:
> Anyway, I think I've got an idea how to render the problem custom panel
> properties invalid. If so, I'll send another version of the patch.
So, instead of describing the panel I thought I'd go lower level and try
to describe the CLCD's signal functions. It gets down to something like
this:
8<----
- arm,pl11x,panel-data-pads: array of 24 cells, each of them describing
a function of one of the CLD pads,
starting from 0 up to 23; each pad can
be described by one of the following values:
- 0: reserved (not connected)
- 0x100-0x107: color upper STN panel data 0 to 7
- 0x110-0x117: color lower STN panel data 0 to 7
- 0x200-0x207: mono upper STN panel data 0 to 7
- 0x210-0x217: mono lower STN panel data 0 to 7
- 0x300-0x307: red component bit 0 to 7 of TFT panel data
- 0x310-0x317: green component bit 0 to 7 of TFT panel data
- 0x320-0x327: blue component bit 0 to 7 of TFT panel data
- 0x330: intensity bit of TFT panel data
Example set of values for standard
panel interfaces:
- PL110 single colour STN panel:
<0x107 0x106 0x105 0x104 0x103 0x102 0x101 0x100>,
<0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
- PL110 dual colour STN panel:
<0x107 0x106 0x105 0x104 0x103 0x102 0x101 0x100>,
<0x117 0x116 0x115 0x114 0x113 0x112 0x111 0x110>,
<0 0 0 0 0 0 0 0>;
- PL110 single mono 4-bit STN panel:
<0x203 0x202 0x201 0x200>,
<0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
- PL110 dual mono 4-bit STN panel:
<0x203 0x202 0x201 0x200>, <0 0 0 0>,
<0x213 0x212 0x211 0x210>,
<0 0 0 0 0 0 0 0 0 0 0 0>;
- PL110 single mono 8-bit STN panel:
<0x207 0x206 0x205 0x204 0x203 0x202 0x201 0x200>,
<0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
- PL110 dual mono 8-bit STN panel:
<0x207 0x206 0x205 0x204 0x203 0x202 0x201 0x200>,
<0x217 0x216 0x215 0x214 0x213 0x212 0x211 0x210>,
<0 0 0 0 0 0 0 0>;
- PL110 TFT (1:)5:5:5 panel:
<0x330 0x300 0x301 0x302 0x303 0x304>,
<0x330 0x310 0x311 0x312 0x313 0x314>,
<0x330 0x320 0x321 0x322 0x323 0x324>,
<0 0 0 0 0 0>
- PL110 and PL111 TFT RGB 888 panel:
<0x300 0x301 0x302 0x303 0x304 0x305 0x306 0x307>,
<0x310 0x311 0x312 0x313 0x314 0x315 0x316 0x317>,
<0x320 0x321 0x322 0x323 0x324 0x325 0x326 0x327>;
- PL111 single colour STN panel:
<0x100 0x101 0x102 0x103 0x104 0x105 0x106 0x107>,
<0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
- PL111 dual colour STN panel:
<0x100 0x101 0x102 0x103 0x104 0x105 0x106 0x107>,
<0x110 0x111 0x112 0x113 0x114 0x115 0x116 0x117>,
<0 0 0 0 0 0 0 0>;
- PL111 single mono 4-bit STN panel:
<0x200 0x201 0x202 0x203>,
<0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
- PL111 dual mono 4-bit STN panel:
<0x200 0x201 0x202 0x203>, <0 0 0 0>,
<0x210 0x211 0x212 0x213>,
<0 0 0 0 0 0 0 0 0 0 0 0>;
- PL111 single mono 8-bit STN panel:
<0x200 0x201 0x202 0x203 0x204 0x205 0x206 0x207>,
<0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
- PL111 dual mono 8-bit STN panel:
<0x200 0x201 0x202 0x203 0x204 0x205 0x206 0x207>,
<0x210 0x211 0x212 0x213 0x214 0x215 0x216 0x217>,
<0 0 0 0 0 0 0 0>;
- PL111 TFT 4:4:4 panel:
<0 0 0 0>, <0x300 0x301 0x302 0x303>,
<0 0 0 0>, <0x310 0x311 0x312 0x313>,
<0 0 0 0>, <0x320 0x321 0x322 0x323>;
- PL111 TFT 5:6:5 panel:
<0 0 0>, <0x300 0x301 0x302 0x303 0x304>,
<0 0>, <0x310 0x311 0x312 0x313 0x314 0x315>,
<0 0 0>, <0x320 0x321 0x322 0x323 0x324>;
- PL111 TFT (1):5:5:5 panel:
<0 0 0>, <0x300 0x301 0x302 0x303 0x304>,
<0 0>, <0x330 0x310 0x311 0x312 0x313 0x314>,
<0 0 0>, <0x320 0x321 0x322 0x323 0x324>;
8<----
Of course the examples above could be #defined.
Such approach would also solve problem with bizarre cases like the
Versatile's (not Express ;-) muxer Russell mentioned (where there is a
de-facto custom wiring used). And no, I had a look at pinmux bindings
and I don't think they fit here at all...
Thoughts?
Paweł
^ permalink raw reply
* [PATCH] pwm-backlight: allow for non-increasing brightness levels
From: Mike Dunn @ 2013-09-12 18:35 UTC (permalink / raw)
To: thierry.reding
Cc: Mike Dunn, Richard Purdie, Jingoo Han,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Grant Likely,
Rob Herring, linux-pwm, linux-fbdev, linux-kernel, devicetree,
Robert Jarzmik, Marek Vasut
Currently the driver assumes that the values specified in the brightness-levels
device tree property increase as they are parsed from left to right. But boards
that invert the signal between the PWM output and the backlight will need to
specify decreasing brightness-levels. This patch removes the assumption that
the last element of the array is the max value, and instead searches the array
for the max value and uses that as the normalizing value when determining the
duty cycle.
Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
---
drivers/video/backlight/pwm_bl.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 1fea627..d66aaa0 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -27,6 +27,7 @@ struct pwm_bl_data {
unsigned int period;
unsigned int lth_brightness;
unsigned int *levels;
+ unsigned int max_level;
int (*notify)(struct device *,
int brightness);
void (*notify_after)(struct device *,
@@ -57,7 +58,7 @@ static int pwm_backlight_update_status(struct backlight_device *bl)
if (pb->levels) {
duty_cycle = pb->levels[brightness];
- max = pb->levels[max];
+ max = pb->levels[pb->max_level];
} else {
duty_cycle = brightness;
}
@@ -195,7 +196,15 @@ static int pwm_backlight_probe(struct platform_device *pdev)
}
if (data->levels) {
- max = data->levels[data->max_brightness];
+ int i, max_value = 0, max_idx = 0;
+ for (i = 0; i <= data->max_brightness; i++) {
+ if (data->levels[i] > max_value) {
+ max_value = data->levels[i];
+ max_idx = i;
+ }
+ }
+ pb->max_level = max_idx;
+ max = data->levels[max_idx];
pb->levels = data->levels;
} else
max = data->max_brightness;
--
1.8.1.5
^ permalink raw reply related
* Re: [PATCH 1/2] video: ARM CLCD: Add DT support
From: Stephen Warren @ 2013-09-12 22:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1379009416.13571.68.camel@hornet>
On 09/12/2013 12:10 PM, Pawel Moll wrote:
> On Thu, 2013-09-12 at 16:23 +0100, Pawel Moll wrote:
>> Anyway, I think I've got an idea how to render the problem custom panel
>> properties invalid. If so, I'll send another version of the patch.
>
> So, instead of describing the panel I thought I'd go lower level and try
> to describe the CLCD's signal functions. It gets down to something like
> this:
>
> 8<----
> - arm,pl11x,panel-data-pads: array of 24 cells, each of them describing
> a function of one of the CLD pads,
> starting from 0 up to 23; each pad can
> be described by one of the following values:
> - 0: reserved (not connected)
> - 0x100-0x107: color upper STN panel data 0 to 7
...
> Such approach would also solve problem with bizarre cases like the
> Versatile's (not Express ;-) muxer Russell mentioned (where there is a
> de-facto custom wiring used). And no, I had a look at pinmux bindings
> and I don't think they fit here at all...
>
> Thoughts?
I think pinctrl would work just fine here. However, I suspect there's
little need for pinctrl. pinctrl is required when one module may impose
requirements on another module's muxable pins. I assume that the
configuration for pins on CLCD is only relevant for CLCD itself, so
there's no need to export an interface by which something else can
configure the pins. Now, if any of the pins could be e.g. "GPIO", then
this argument might not apply. Hence, I think pinctrl is only "possible"
here, not "required", and the approach above seems fine to me.
^ permalink raw reply
* Re: [PATCH 1/2] video: ARM CLCD: Add DT support
From: Russell King - ARM Linux @ 2013-09-12 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52323E01.2070902@wwwdotorg.org>
On Thu, Sep 12, 2013 at 04:19:45PM -0600, Stephen Warren wrote:
> On 09/12/2013 12:10 PM, Pawel Moll wrote:
> > Such approach would also solve problem with bizarre cases like the
> > Versatile's (not Express ;-) muxer Russell mentioned (where there is a
> > de-facto custom wiring used). And no, I had a look at pinmux bindings
> > and I don't think they fit here at all...
> >
> > Thoughts?
>
> I think pinctrl would work just fine here. However, I suspect there's
> little need for pinctrl. pinctrl is required when one module may impose
> requirements on another module's muxable pins. I assume that the
> configuration for pins on CLCD is only relevant for CLCD itself, so
> there's no need to export an interface by which something else can
> configure the pins.
Well, the hardware is much like this:
CLCD ---> Mux ---> output
and the mux is controlled by a register, and will manipulate the output
from the CLCD controller such that the framebuffer contents can be
RGB565, BGR565, XRGB1555, XBGR1555 or RGB888.
(Actually, the Versatile mux can only support one of the 1555 formats,
but I forget which it is.)
I'm not sure that its worth describing all these in DT explicitly, but
maybe encoding it as a special "versatile" version of the CLCD primecell
instead - especially as the external mux takes care of the colour
component order rather than the CLCD controller (and that requires a
bit of board specific code to deal with.)
^ permalink raw reply
* [PATCH V5 0/5] video: mmp: misc updates for mmp display driver
From: Zhou Zhu @ 2013-09-13 6:59 UTC (permalink / raw)
To: linux-fbdev
Resend this patch set, the V1 to V4 of which is sent by Jett Zhou.
This patch set contains some misc updates for mmp display controller:
1. Rbswap enhancement
2. Code refine.
3. Pitch calculation and video layer settings.
Changes:
V5/V4:
Just rebase.
V3/V2:
some updates according to comments.
Guoqing Li (2):
video: mmp: rb swap setting update for mmp display
video: mmp: optimize some register setting code
Jett.Zhou (1):
ARM: mmp: remove the legacy rbswap setting for ttc_dkb platform
Jing Xiang (2):
video: mmp: calculate pitch value when fb set win
video: mmp: add pitch info in mmp_win structure
arch/arm/mach-mmp/ttc_dkb.c | 4 +--
drivers/video/mmp/fb/mmpfb.c | 34 ++++++++++++-------
drivers/video/mmp/hw/mmp_ctrl.c | 71 ++++++++++++++++++++++-----------------
drivers/video/mmp/hw/mmp_ctrl.h | 5 +++
include/video/mmp_disp.h | 6 ++++
5 files changed, 75 insertions(+), 45 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH V5 1/5] video: mmp: rb swap setting update for mmp display
From: Zhou Zhu @ 2013-09-13 6:59 UTC (permalink / raw)
To: linux-fbdev
From: Guoqing Li <ligq@marvell.com>
We could set rb swap in two modules: DMA controler input part and
dsi interface output part.
DMA input part is based on pix_fmt to set rbswap, dsi output interface
part will set rbswap based on platform dsi_rbswap configuration.
This patch include below change and enhancement:
1) The input format which support rbswap is based on RGB format,
eg. RGB565 indicates the source data in memory is that Red is [15~11],
Green is [10~5], Blue is [4:0], Red is MSB, Blue is LSB, but for the
display dma input default setting(rbswap = 0), it only support Blue
is [15~11], Green is [10~5], Red is [4:0], Red is LSB, Blue is MSB,
so for this format(RGB565), display controller need to set rbswap
= 1 and it can support the MSB/LSB correctly.
BGR/YUV format will not set it in mmp display driver.
2) The dsi output part of rbswap is depend on dsi_rbswap which is
defined in specific platfrom. For output dsi interface, it has this
feature to do rbswap again if it needs specifc byte sequence of RGB
byte for DSI panel.
eg. If display content is set RGB565 in memory and DMA input part set
rbswap in driver to support Red as MSB , Blue LSB, but dsi panel only
support Red as LSB, Blue as MSB, then it can use this feature.
If there is no this requirement of panel, this dsi output part is not
needed.
Signed-off-by: Guoqing Li <ligq@marvell.com>
Signed-off-by: Jett.Zhou <jtzhou@marvell.com>
Signed-off-by: Zhou Zhu <zzhu3@marvell.com>
Reviewed-by: Daniel Drake <dsd@laptop.org>
---
drivers/video/mmp/hw/mmp_ctrl.c | 19 +++++++++++--------
drivers/video/mmp/hw/mmp_ctrl.h | 5 +++++
include/video/mmp_disp.h | 1 +
3 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/video/mmp/hw/mmp_ctrl.c b/drivers/video/mmp/hw/mmp_ctrl.c
index 75dca19..a40d95a 100644
--- a/drivers/video/mmp/hw/mmp_ctrl.c
+++ b/drivers/video/mmp/hw/mmp_ctrl.c
@@ -60,8 +60,7 @@ static irqreturn_t ctrl_handle_irq(int irq, void *dev_id)
static u32 fmt_to_reg(struct mmp_overlay *overlay, int pix_fmt)
{
- u32 link_config = path_to_path_plat(overlay->path)->link_config;
- u32 rbswap, uvswap = 0, yuvswap = 0,
+ u32 rbswap = 0, uvswap = 0, yuvswap = 0,
csc_en = 0, val = 0,
vid = overlay_is_vid(overlay);
@@ -71,27 +70,23 @@ static u32 fmt_to_reg(struct mmp_overlay *overlay, int pix_fmt)
case PIXFMT_RGB888PACK:
case PIXFMT_RGB888UNPACK:
case PIXFMT_RGBA888:
- rbswap = !(link_config & 0x1);
+ rbswap = 1;
break;
case PIXFMT_VYUY:
case PIXFMT_YVU422P:
case PIXFMT_YVU420P:
- rbswap = link_config & 0x1;
uvswap = 1;
break;
case PIXFMT_YUYV:
- rbswap = link_config & 0x1;
yuvswap = 1;
break;
default:
- rbswap = link_config & 0x1;
break;
}
switch (pix_fmt) {
case PIXFMT_RGB565:
case PIXFMT_BGR565:
- val = 0;
break;
case PIXFMT_RGB1555:
case PIXFMT_BGR1555:
@@ -248,7 +243,8 @@ static void path_set_mode(struct mmp_path *path, struct mmp_mode *mode)
{
struct lcd_regs *regs = path_regs(path);
u32 total_x, total_y, vsync_ctrl, tmp, sclk_src, sclk_div,
- link_config = path_to_path_plat(path)->link_config;
+ link_config = path_to_path_plat(path)->link_config,
+ dsi_rbswap = path_to_path_plat(path)->link_config;
/* FIXME: assert videomode supported */
memcpy(&path->mode, mode, sizeof(struct mmp_mode));
@@ -263,6 +259,12 @@ static void path_set_mode(struct mmp_path *path, struct mmp_mode *mode)
tmp |= CFG_DUMB_ENA(1);
writel_relaxed(tmp, ctrl_regs(path) + intf_ctrl(path->id));
+ /* interface rb_swap setting */
+ tmp = readl_relaxed(ctrl_regs(path) + intf_rbswap_ctrl(path->id)) &
+ (~(CFG_INTFRBSWAP_MASK));
+ tmp |= dsi_rbswap & CFG_INTFRBSWAP_MASK;
+ writel_relaxed(tmp, ctrl_regs(path) + intf_rbswap_ctrl(path->id));
+
writel_relaxed((mode->yres << 16) | mode->xres, ®s->screen_active);
writel_relaxed((mode->left_margin << 16) | mode->right_margin,
®s->screen_h_porch);
@@ -419,6 +421,7 @@ static int path_init(struct mmphw_path_plat *path_plat,
path_plat->path = path;
path_plat->path_config = config->path_config;
path_plat->link_config = config->link_config;
+ path_plat->dsi_rbswap = config->dsi_rbswap;
path_set_default(path);
kfree(path_info);
diff --git a/drivers/video/mmp/hw/mmp_ctrl.h b/drivers/video/mmp/hw/mmp_ctrl.h
index edd2002..53301cf 100644
--- a/drivers/video/mmp/hw/mmp_ctrl.h
+++ b/drivers/video/mmp/hw/mmp_ctrl.h
@@ -163,6 +163,8 @@ struct lcd_regs {
#define LCD_SCLK(path) ((PATH_PN = path->id) ? LCD_CFG_SCLK_DIV :\
((PATH_TV = path->id) ? LCD_TCLK_DIV : LCD_PN2_SCLK_DIV))
+#define intf_rbswap_ctrl(id) ((id) ? (((id) & 1) ? LCD_TVIF_CTRL : \
+ PN2_IOPAD_CONTROL) : LCD_TOP_CTRL)
/* dither configure */
#ifdef CONFIG_CPU_PXA988
@@ -615,6 +617,8 @@ struct lcd_regs {
#define LCD_SPU_DUMB_CTRL 0x01B8
#define CFG_DUMBMODE(mode) ((mode)<<28)
#define CFG_DUMBMODE_MASK 0xF0000000
+#define CFG_INTFRBSWAP(mode) ((mode)<<24)
+#define CFG_INTFRBSWAP_MASK 0x0F000000
#define CFG_LCDGPIO_O(data) ((data)<<20)
#define CFG_LCDGPIO_O_MASK 0x0FF00000
#define CFG_LCDGPIO_ENA(gpio) ((gpio)<<12)
@@ -1427,6 +1431,7 @@ struct mmphw_path_plat {
struct mmp_path *path;
u32 path_config;
u32 link_config;
+ u32 dsi_rbswap;
};
/* mmp ctrl describes mmp controller related info */
diff --git a/include/video/mmp_disp.h b/include/video/mmp_disp.h
index b9dd1fb..32094c0 100644
--- a/include/video/mmp_disp.h
+++ b/include/video/mmp_disp.h
@@ -334,6 +334,7 @@ struct mmp_mach_path_config {
int output_type;
u32 path_config;
u32 link_config;
+ u32 dsi_rbswap;
};
struct mmp_mach_plat_info {
--
1.7.9.5
^ permalink raw reply related
* [PATCH V5 2/5] ARM: mmp: remove the legacy rbswap setting for ttc_dkb platform
From: Zhou Zhu @ 2013-09-13 6:59 UTC (permalink / raw)
To: linux-fbdev
From: "Jett.Zhou" <jtzhou@marvell.com>
According to new rbswap scheme of mmp_display, it support appropriate
rbswap setting based on specific pix_fmt, then we can remove the legacy
rbswap setting for ttc_dkb platform.
Signed-off-by: Jett.Zhou <jtzhou@marvell.com>
Signed-off-by: Zhou Zhu <zzhu3@marvell.com>
Reviewed-by: Daniel Drake <dsd@laptop.org>
Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
---
arch/arm/mach-mmp/ttc_dkb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/mach-mmp/ttc_dkb.c b/arch/arm/mach-mmp/ttc_dkb.c
index 7022329..cfadd97 100644
--- a/arch/arm/mach-mmp/ttc_dkb.c
+++ b/arch/arm/mach-mmp/ttc_dkb.c
@@ -191,7 +191,6 @@ static struct pxa3xx_nand_platform_data dkb_nand_info = {
#define SCLK_SOURCE_SELECT(x) (x << 30) /* 0x0 ~ 0x3 */
/* link config */
#define CFG_DUMBMODE(mode) (mode << 28) /* 0x0 ~ 0x6*/
-#define CFG_GRA_SWAPRB(x) (x << 0) /* 1: rbswap enabled */
static struct mmp_mach_path_config dkb_disp_config[] = {
[0] = {
.name = "mmp-parallel",
@@ -199,8 +198,7 @@ static struct mmp_mach_path_config dkb_disp_config[] = {
.output_type = PATH_OUT_PARALLEL,
.path_config = CFG_IOPADMODE(0x1)
| SCLK_SOURCE_SELECT(0x1),
- .link_config = CFG_DUMBMODE(0x2)
- | CFG_GRA_SWAPRB(0x1),
+ .link_config = CFG_DUMBMODE(0x2),
},
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH V5 3/5] video: mmp: optimize some register setting code
From: Zhou Zhu @ 2013-09-13 6:59 UTC (permalink / raw)
To: linux-fbdev
From: Guoqing Li <ligq@marvell.com>
There are dumplicate code of the smooth setting based on different
path, optimized the routine and use readl_relaxed instead.
Signed-off-by: Jett.Zhou <jtzhou@marvell.com>
Signed-off-by: Jing Xiang <jxiang@marvell.com>
Signed-off-by: Guoqing Li <ligq@marvell.com>
Signed-off-by: Zhou Zhu <zzhu3@marvell.com>
Reviewed-by: Daniel Drake <dsd@laptop.org>
---
drivers/video/mmp/hw/mmp_ctrl.c | 22 +++++++---------------
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/video/mmp/hw/mmp_ctrl.c b/drivers/video/mmp/hw/mmp_ctrl.c
index a40d95a..c0eb8bc 100644
--- a/drivers/video/mmp/hw/mmp_ctrl.c
+++ b/drivers/video/mmp/hw/mmp_ctrl.c
@@ -53,7 +53,7 @@ static irqreturn_t ctrl_handle_irq(int irq, void *dev_id)
tmp = readl_relaxed(ctrl->reg_base + SPU_IRQ_ISR);
if (tmp & isr)
writel_relaxed(~isr, ctrl->reg_base + SPU_IRQ_ISR);
- } while ((isr = readl(ctrl->reg_base + SPU_IRQ_ISR)) & imask);
+ } while ((isr = readl_relaxed(ctrl->reg_base + SPU_IRQ_ISR)) & imask);
return IRQ_HANDLED;
}
@@ -372,20 +372,12 @@ static void path_set_default(struct mmp_path *path)
* bus arbiter for faster read if not tv path;
* 2.enable horizontal smooth filter;
*/
- if (PATH_PN = path->id) {
- mask = CFG_GRA_HSMOOTH_MASK | CFG_DMA_HSMOOTH_MASK
- | CFG_ARBFAST_ENA(1);
- tmp = readl_relaxed(ctrl_regs(path) + dma_ctrl(0, path->id));
- tmp |= mask;
- writel_relaxed(tmp, ctrl_regs(path) + dma_ctrl(0, path->id));
- } else if (PATH_TV = path->id) {
- mask = CFG_GRA_HSMOOTH_MASK | CFG_DMA_HSMOOTH_MASK
- | CFG_ARBFAST_ENA(1);
- tmp = readl_relaxed(ctrl_regs(path) + dma_ctrl(0, path->id));
- tmp &= ~mask;
- tmp |= CFG_GRA_HSMOOTH_MASK | CFG_DMA_HSMOOTH_MASK;
- writel_relaxed(tmp, ctrl_regs(path) + dma_ctrl(0, path->id));
- }
+ mask = CFG_GRA_HSMOOTH_MASK | CFG_DMA_HSMOOTH_MASK | CFG_ARBFAST_ENA(1);
+ tmp = readl_relaxed(ctrl_regs(path) + dma_ctrl(0, path->id));
+ tmp |= mask;
+ if (PATH_TV = path->id)
+ tmp &= ~CFG_ARBFAST_ENA(1);
+ writel_relaxed(tmp, ctrl_regs(path) + dma_ctrl(0, path->id));
}
static int path_init(struct mmphw_path_plat *path_plat,
--
1.7.9.5
^ permalink raw reply related
* [PATCH V5 4/5] video: mmp: calculate pitch value when fb set win
From: Zhou Zhu @ 2013-09-13 6:59 UTC (permalink / raw)
To: linux-fbdev
From: Jing Xiang <jxiang@marvell.com>
Add new func mmpfb_set_win to make code clean, it will do resolution
and fmt setting of win in mmpfb_set_win.
Signed-off-by: Jing Xiang <jxiang@marvell.com>
Signed-off-by: Jett.Zhou <jtzhou@marvell.com>
Signed-off-by: Zhou Zhu <zzhu3@marvell.com>
Reviewed-by: Daniel Drake <dsd@laptop.org>
---
drivers/video/mmp/fb/mmpfb.c | 28 ++++++++++++++++------------
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/video/mmp/fb/mmpfb.c b/drivers/video/mmp/fb/mmpfb.c
index 4ab95b8..19fd913 100644
--- a/drivers/video/mmp/fb/mmpfb.c
+++ b/drivers/video/mmp/fb/mmpfb.c
@@ -392,12 +392,23 @@ static int var_update(struct fb_info *info)
return 0;
}
+static void mmpfb_set_win(struct fb_info *info)
+{
+ struct mmpfb_info *fbi = info->par;
+ struct mmp_win win;
+
+ memset(&win, 0, sizeof(win));
+ win.xsrc = win.xdst = fbi->mode.xres;
+ win.ysrc = win.ydst = fbi->mode.yres;
+ win.pix_fmt = fbi->pix_fmt;
+ mmp_overlay_set_win(fbi->overlay, &win);
+}
+
static int mmpfb_set_par(struct fb_info *info)
{
struct mmpfb_info *fbi = info->par;
struct fb_var_screeninfo *var = &info->var;
struct mmp_addr addr;
- struct mmp_win win;
struct mmp_mode mode;
int ret;
@@ -409,11 +420,8 @@ static int mmpfb_set_par(struct fb_info *info)
fbmode_to_mmpmode(&mode, &fbi->mode, fbi->output_fmt);
mmp_path_set_mode(fbi->path, &mode);
- memset(&win, 0, sizeof(win));
- win.xsrc = win.xdst = fbi->mode.xres;
- win.ysrc = win.ydst = fbi->mode.yres;
- win.pix_fmt = fbi->pix_fmt;
- mmp_overlay_set_win(fbi->overlay, &win);
+ /* set window related info */
+ mmpfb_set_win(info);
/* set address always */
memset(&addr, 0, sizeof(addr));
@@ -427,16 +435,12 @@ static int mmpfb_set_par(struct fb_info *info)
static void mmpfb_power(struct mmpfb_info *fbi, int power)
{
struct mmp_addr addr;
- struct mmp_win win;
struct fb_var_screeninfo *var = &fbi->fb_info->var;
/* for power on, always set address/window again */
if (power) {
- memset(&win, 0, sizeof(win));
- win.xsrc = win.xdst = fbi->mode.xres;
- win.ysrc = win.ydst = fbi->mode.yres;
- win.pix_fmt = fbi->pix_fmt;
- mmp_overlay_set_win(fbi->overlay, &win);
+ /* set window related info */
+ mmpfb_set_win(fbi->fb_info);
/* set address always */
memset(&addr, 0, sizeof(addr));
--
1.7.9.5
^ permalink raw reply related
* [PATCH V5 5/5] video: mmp: add pitch info in mmp_win structure
From: Zhou Zhu @ 2013-09-13 6:59 UTC (permalink / raw)
To: linux-fbdev
From: Jing Xiang <jxiang@marvell.com>
Add pitch length info of graphics/video layer, pitch is used
to represent line length in byte, the usage depends on pix_fmt.
If the fmt is YUV, the pitch[0] will be Y length,pitch[1]
will be U length, pitch[2] will be V lenth.
If the fmt is RGB, the picth[0] will be line lenth, and
pitch[1]/pitch[2] will be 0 and not be used.
Signed-off-by: Jing Xiang <jxiang@marvell.com>
Signed-off-by: Jett.Zhou <jtzhou@marvell.com>
Signed-off-by: Zhou Zhu <zzhu3@marvell.com>
Reviewed-by: Daniel Drake <dsd@laptop.org>
---
drivers/video/mmp/fb/mmpfb.c | 6 ++++++
drivers/video/mmp/hw/mmp_ctrl.c | 30 +++++++++++++++++++++++-------
include/video/mmp_disp.h | 5 +++++
3 files changed, 34 insertions(+), 7 deletions(-)
diff --git a/drivers/video/mmp/fb/mmpfb.c b/drivers/video/mmp/fb/mmpfb.c
index 19fd913..7ab31eb 100644
--- a/drivers/video/mmp/fb/mmpfb.c
+++ b/drivers/video/mmp/fb/mmpfb.c
@@ -395,12 +395,18 @@ static int var_update(struct fb_info *info)
static void mmpfb_set_win(struct fb_info *info)
{
struct mmpfb_info *fbi = info->par;
+ struct fb_var_screeninfo *var = &info->var;
struct mmp_win win;
+ u32 stride;
memset(&win, 0, sizeof(win));
win.xsrc = win.xdst = fbi->mode.xres;
win.ysrc = win.ydst = fbi->mode.yres;
win.pix_fmt = fbi->pix_fmt;
+ stride = pixfmt_to_stride(win.pix_fmt);
+ win.pitch[0] = var->xres_virtual * stride;
+ win.pitch[1] = win.pitch[2] + (stride = 1) ? (var->xres_virtual >> 1) : 0;
mmp_overlay_set_win(fbi->overlay, &win);
}
diff --git a/drivers/video/mmp/hw/mmp_ctrl.c b/drivers/video/mmp/hw/mmp_ctrl.c
index c0eb8bc..ae724aa 100644
--- a/drivers/video/mmp/hw/mmp_ctrl.c
+++ b/drivers/video/mmp/hw/mmp_ctrl.c
@@ -142,17 +142,27 @@ static void dmafetch_set_fmt(struct mmp_overlay *overlay)
static void overlay_set_win(struct mmp_overlay *overlay, struct mmp_win *win)
{
struct lcd_regs *regs = path_regs(overlay->path);
- u32 pitch;
/* assert win supported */
memcpy(&overlay->win, win, sizeof(struct mmp_win));
mutex_lock(&overlay->access_ok);
- pitch = win->xsrc * pixfmt_to_stride(win->pix_fmt);
- writel_relaxed(pitch, ®s->g_pitch);
- writel_relaxed((win->ysrc << 16) | win->xsrc, ®s->g_size);
- writel_relaxed((win->ydst << 16) | win->xdst, ®s->g_size_z);
- writel_relaxed(0, ®s->g_start);
+
+ if (overlay_is_vid(overlay)) {
+ writel_relaxed(win->pitch[0], ®s->v_pitch_yc);
+ writel_relaxed(win->pitch[2] << 16 |
+ win->pitch[1], ®s->v_pitch_uv);
+
+ writel_relaxed((win->ysrc << 16) | win->xsrc, ®s->v_size);
+ writel_relaxed((win->ydst << 16) | win->xdst, ®s->v_size_z);
+ writel_relaxed(win->ypos << 16 | win->xpos, ®s->v_start);
+ } else {
+ writel_relaxed(win->pitch[0], ®s->g_pitch);
+
+ writel_relaxed((win->ysrc << 16) | win->xsrc, ®s->g_size);
+ writel_relaxed((win->ydst << 16) | win->xdst, ®s->g_size_z);
+ writel_relaxed(win->ypos << 16 | win->xpos, ®s->g_start);
+ }
dmafetch_set_fmt(overlay);
mutex_unlock(&overlay->access_ok);
@@ -234,7 +244,13 @@ static int overlay_set_addr(struct mmp_overlay *overlay, struct mmp_addr *addr)
/* FIXME: assert addr supported */
memcpy(&overlay->addr, addr, sizeof(struct mmp_addr));
- writel(addr->phys[0], ®s->g_0);
+
+ if (overlay_is_vid(overlay)) {
+ writel_relaxed(addr->phys[0], ®s->v_y0);
+ writel_relaxed(addr->phys[1], ®s->v_u0);
+ writel_relaxed(addr->phys[2], ®s->v_v0);
+ } else
+ writel_relaxed(addr->phys[0], ®s->g_0);
return overlay->addr.phys[0];
}
diff --git a/include/video/mmp_disp.h b/include/video/mmp_disp.h
index 32094c0..9fd9398 100644
--- a/include/video/mmp_disp.h
+++ b/include/video/mmp_disp.h
@@ -91,6 +91,11 @@ struct mmp_win {
u16 up_crop;
u16 bottom_crop;
int pix_fmt;
+ /*
+ * pitch[0]: graphics/video layer line length or y pitch
+ * pitch[1]/pitch[2]: video u/v pitch if non-zero
+ */
+ u32 pitch[3];
};
struct mmp_addr {
--
1.7.9.5
^ permalink raw reply related
* RE: [PATCH v3 0/5] ARM: vf610: Add DCU framebuffer driver for Vybrid VF610 platform
From: Wang Huan-B18965 @ 2013-09-13 7:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52270C71.7080805@ti.com>
TXkgY29tbWVudHMgaW5saW5lLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy
b206IFRvbWkgVmFsa2VpbmVuIFttYWlsdG86dG9taS52YWxrZWluZW5AdGkuY29tXQ0KPiBTZW50
OiBXZWRuZXNkYXksIFNlcHRlbWJlciAwNCwgMjAxMyA2OjMzIFBNDQo+IFRvOiBXYW5nIEh1YW4t
QjE4OTY1DQo+IENjOiBwbGFnbmlvakBqY3Jvc29mdC5jb207IGxpbnV4LWZiZGV2QHZnZXIua2Vy
bmVsLm9yZzsgbGludXgtYXJtLQ0KPiBrZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZzsgSmluIFpo
ZW5neGlvbmctUjY0MTg4OyBFc3RldmFtIEZhYmlvLVI0OTQ5NjsNCj4gc2hhd24uZ3VvQGxpbmFy
by5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCB2MyAwLzVdIEFSTTogdmY2MTA6IEFkZCBEQ1Ug
ZnJhbWVidWZmZXIgZHJpdmVyIGZvcg0KPiBWeWJyaWQgVkY2MTAgcGxhdGZvcm0NCj4gDQo+IEhp
LA0KPiANCj4gT24gMDMvMDkvMTMgMTE6MjEsIFdhbmcgSHVhbi1CMTg5NjUgd3JvdGU6DQo+ID4g
SGksIEplYW4tQ2hyaXN0b3BoZSwgVG9taSwNCj4gPg0KPiA+ICAgICAgIENvdWxkIHlvdSBwbGVh
c2UgaGVscCB0byByZXZpZXcgdGhlc2UgcGF0Y2hlcz8NCj4gPiAgICAgICBUaGFua3MhDQo+IA0K
PiBUaGVyZSBzZWVtZWQgdG8gYmUgc29tZSBzdHJvbmcgb3BpbmlvbnMgdGhhdCB0aGVyZSBzaG91
bGQgYmUgYSBkcm0NCj4gZHJpdmVyIGZvciB0aGlzIGhhcmR3YXJlLCBpbnN0ZWFkIG9mIGFuIGZi
IGRyaXZlci4gU28gYXMgdGhlcmUgc2VlbXMgdG8NCj4gYmUgZGlzYWdyZWVtZW50cyBhYm91dCB0
aGlzLCBJJ2xsIGxlYXZlIHRoaXMgc2VyaWVzIHRvIEplYW4tQ2hyaXN0b3BoZSwNCj4gd2hvJ3Mg
dGhlIHByaW1hcnkgbWFpbnRhaW5lci4NCltBbGlzb24gV2FuZ10gDQoNClRoYW5rcyBmb3IgVG9t
aSdzIGNvbW1lbnRzLiANCg0KSSBhZ3JlZSB0aGF0IHdlIGNhbiBpbXBsZW1lbnQgdGhlIERSTSBk
cml2ZXIgZm9yIHRoZSBEQ1UuIEFzIHRoZSBiYW5kd2lkdGggbGltaXRhdGlvbiwgSSBzdWdnZXN0
IHdlIHVzZSB0aGUgZmIgZHJpdmVyIGZpcnN0bHkuIE9uIHRoZSBvdGhlciBoYW5kLCB0aGUgZmIg
ZHJpdmVyIGNhbiBtZWV0IHRoZSBhcHBsaWNhdGlvbiByZXF1aXJlbWVudCBiYXNlZCBvbiB0aGlz
IFNvQy4gV2UnbGwgdHJ5IHRvIHByb3ZpZGUgdGhlIERSTSBkcml2ZXIgd2hlbiB0aGlzIElQIGlu
dGVncmF0ZWQgaW50byBvdGhlciBTb0MuIA0KDQpKZWFuLUNocmlzdG9waGUsIERvIHlvdSBoYXZl
IGFueSBjb21tZW50cy4gVGhhbmtzLiAgDQoNCg0KQmVzdCBSZWdhcmRzLA0KQWxpc29uIFdhbmcN
Cg=
^ permalink raw reply
* Re: [PATCH V5 0/5] video: mmp: misc updates for mmp display driver
From: Zhou Zhu @ 2013-09-13 7:41 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1379055589-26132-1-git-send-email-zzhu3@marvell.com>
Hi, Jean-Christophe, Tomi,
Would you please help to review/apply this patch set?
It has been there for more than 2 months from v3 in which version we
made last update...
On 09/13/2013 02:59 PM, Zhou Zhu wrote:
> Resend this patch set, the V1 to V4 of which is sent by Jett Zhou.
> This patch set contains some misc updates for mmp display controller:
> 1. Rbswap enhancement
> 2. Code refine.
> 3. Pitch calculation and video layer settings.
>
> Changes:
> V5/V4:
> Just rebase.
>
> V3/V2:
> some updates according to comments.
>
> Guoqing Li (2):
> video: mmp: rb swap setting update for mmp display
> video: mmp: optimize some register setting code
>
> Jett.Zhou (1):
> ARM: mmp: remove the legacy rbswap setting for ttc_dkb platform
>
> Jing Xiang (2):
> video: mmp: calculate pitch value when fb set win
> video: mmp: add pitch info in mmp_win structure
>
> arch/arm/mach-mmp/ttc_dkb.c | 4 +--
> drivers/video/mmp/fb/mmpfb.c | 34 ++++++++++++-------
> drivers/video/mmp/hw/mmp_ctrl.c | 71 ++++++++++++++++++++++-----------------
> drivers/video/mmp/hw/mmp_ctrl.h | 5 +++
> include/video/mmp_disp.h | 6 ++++
> 5 files changed, 75 insertions(+), 45 deletions(-)
>
--
Thanks, -Zhou
^ permalink raw reply
* [PATCH 0/7] omapdss: HDMI: Fix register definitions and reg dump functions
From: Archit Taneja @ 2013-09-13 10:41 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
These patches complete the OMAP4 HDMI register definitions for HDMI submodules
and make sure all the corresponding regdump functions dump all the registers.
Ricardo Neri (7):
OMAPDSS: HDMI: OMAP4: Complete register definitions for wrapper
OMAPDSS: HDMI: OMAP4: Complete dumping of wrapper registers
OMAPDSS: HDMI: OMAP4: Complete register definitions for DPLL
OMAPDSS: HDMI: OMAP4: Complete dumping of DPLL registers
OMAPDSS: HDMI: OMAP4: Rename the HDMI_CORE_CTRL1 register
OMAPDSS: HDMI: OMAP4: Complete register definitions for core
OMAPDSS: HDMI: OMAP4: Complete dumping of core registers
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 70 ++++++++++++++++++++++++++-----
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 65 ++++++++++++++++++++++++----
2 files changed, 118 insertions(+), 17 deletions(-)
--
1.8.1.2
^ permalink raw reply
* [PATCH 1/7] OMAPDSS: HDMI: OMAP4: Complete register definitions for wrapper
From: Archit Taneja @ 2013-09-13 10:41 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Ricardo Neri, Archit Taneja
In-Reply-To: <1379068178-17312-1-git-send-email-archit@ti.com>
From: Ricardo Neri <ricardo.neri@ti.com>
Add definitions for missing registers in the HDMI wrapper. Also, order
the registers by offset to improve readability.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index 6ef2f92..469d436 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -31,9 +31,11 @@
#define HDMI_WP_SYSCONFIG 0x10
#define HDMI_WP_IRQSTATUS_RAW 0x24
#define HDMI_WP_IRQSTATUS 0x28
-#define HDMI_WP_PWR_CTRL 0x40
#define HDMI_WP_IRQENABLE_SET 0x2C
#define HDMI_WP_IRQENABLE_CLR 0x30
+#define HDMI_WP_IRQWAKEEN 0x34
+#define HDMI_WP_PWR_CTRL 0x40
+#define HDMI_WP_DEBOUNCE 0x44
#define HDMI_WP_VIDEO_CFG 0x50
#define HDMI_WP_VIDEO_SIZE 0x60
#define HDMI_WP_VIDEO_TIMING_H 0x68
--
1.8.1.2
^ permalink raw reply related
* [PATCH 2/7] OMAPDSS: HDMI: OMAP4: Complete dumping of wrapper registers
From: Archit Taneja @ 2013-09-13 10:41 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Ricardo Neri, Archit Taneja
In-Reply-To: <1379068178-17312-1-git-send-email-archit@ti.com>
From: Ricardo Neri <ricardo.neri@ti.com>
Add missing registers when dumping the HDMI wrapper. Also, order the dump by
offset to improve readability.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index 3dfe009..ecadd7a 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -859,8 +859,11 @@ void ti_hdmi_4xxx_wp_dump(struct hdmi_ip_data *ip_data, struct seq_file *s)
DUMPREG(HDMI_WP_SYSCONFIG);
DUMPREG(HDMI_WP_IRQSTATUS_RAW);
DUMPREG(HDMI_WP_IRQSTATUS);
- DUMPREG(HDMI_WP_PWR_CTRL);
DUMPREG(HDMI_WP_IRQENABLE_SET);
+ DUMPREG(HDMI_WP_IRQENABLE_CLR);
+ DUMPREG(HDMI_WP_IRQWAKEEN);
+ DUMPREG(HDMI_WP_PWR_CTRL);
+ DUMPREG(HDMI_WP_DEBOUNCE);
DUMPREG(HDMI_WP_VIDEO_CFG);
DUMPREG(HDMI_WP_VIDEO_SIZE);
DUMPREG(HDMI_WP_VIDEO_TIMING_H);
--
1.8.1.2
^ permalink raw reply related
* [PATCH 3/7] OMAPDSS: HDMI: OMAP4: Complete register definitions for DPLL
From: Archit Taneja @ 2013-09-13 10:41 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Ricardo Neri, Archit Taneja
In-Reply-To: <1379068178-17312-1-git-send-email-archit@ti.com>
From: Ricardo Neri <ricardo.neri@ti.com>
Add missing register definitions for spread spectrum clocking.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index 469d436..d1a2315 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -168,6 +168,8 @@
#define PLLCTRL_CFG1 0xC
#define PLLCTRL_CFG2 0x10
#define PLLCTRL_CFG3 0x14
+#define PLLCTRL_SSC_CFG1 0x18
+#define PLLCTRL_SSC_CFG2 0x1C
#define PLLCTRL_CFG4 0x20
/* HDMI PHY */
--
1.8.1.2
^ permalink raw reply related
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