* Re: [PATCH 5/5] OMAPFB: connect ovl managers to all dssdevs
From: Archit Taneja @ 2012-12-10 9:55 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <50C59745.2080604@ti.com>
On Monday 10 December 2012 01:33 PM, Tomi Valkeinen wrote:
> On 2012-12-10 09:34, Archit Taneja wrote:
>> Hi,
>>
>> On Friday 07 December 2012 05:25 PM, Tomi Valkeinen wrote:
>>> Commit 5d89bcc341771d95e3a2996218e5949a6627f59e (OMAPDSS: remove initial
>>> display code from omapdss) moved setting up the initial overlay, overlay
>>> manager, output and display connections from omapdss to omapfb.
>>>
>>> However, currently omapfb only handles the connection related to the
>>> default display, which means that no overlay managers are connected to
>>> other displays.
>>>
>>> This patch changes omapfb to go through all dssdevs, and connect an
>>> overlay manager to them.
>>>
>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>> ---
>>> drivers/video/omap2/omapfb/omapfb-main.c | 38
>>> +++++++++++++++++++-----------
>>> 1 file changed, 24 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
>>> b/drivers/video/omap2/omapfb/omapfb-main.c
>>> index 1df973e..24739fc 100644
>>> --- a/drivers/video/omap2/omapfb/omapfb-main.c
>>> +++ b/drivers/video/omap2/omapfb/omapfb-main.c
>>> @@ -2353,27 +2353,37 @@ static int omapfb_init_display(struct
>>> omapfb2_device *fbdev,
>>> }
>>>
>>> static int omapfb_init_connections(struct omapfb2_device *fbdev,
>>> - struct omap_dss_device *dssdev)
>>> + struct omap_dss_device *def_dssdev)
>>> {
>>> int i, r;
>>> - struct omap_overlay_manager *mgr = NULL;
>>> + struct omap_overlay_manager *mgr;
>>>
>>> - for (i = 0; i < fbdev->num_managers; i++) {
>>> - mgr = fbdev->managers[i];
>>> -
>>> - if (dssdev->channel = mgr->id)
>>> - break;
>>> + if (!def_dssdev->output) {
>>> + dev_err(fbdev->dev, "no output for the default display\n");
>>> + return -EINVAL;
>>> }
>>>
>>> - if (i = fbdev->num_managers)
>>> - return -ENODEV;
>>> + for (i = 0; i < fbdev->num_displays; ++i) {
>>> + struct omap_dss_device *dssdev = fbdev->displays[i].dssdev;
>>> + struct omap_dss_output *out = dssdev->output;
>>>
>>> - if (mgr->output)
>>> - mgr->unset_output(mgr);
>>> + mgr = omap_dss_get_overlay_manager(dssdev->channel);
>>
>> This dssdev->channel reference is something we would want to get rid of
>> eventually, right?
>
> Yes.
>
>> At the point omapfb_init_connections() is called, we would have all the
>> omap_dss_devices registered, right? So at this point, omapfb will have
>> an overall view of how the panels need to be connected to DSS.
>>
>> I think we can try to find a manager here for dssdev rather than using
>> dssdev->channel directly. The dssdev's output could connect to a few
>> managers. We would want to chose managers for each dssdev output in such
>> a way that all outputs have a manager. I guess there would be multiple
>> combinations for this, but it would be okay to pick any one of them.
>>
>> I think we would need some recursive or backtracking sort of approach to
>> get a desired combination. We can figure about how to make it work
>> later, but do you agree if this is a right way to get rid of
>> dssdev->channel?
>
> Yes, I think that's a sensible approach. The thing I don't like about it
> is that it requires omapfb/omapdrm to create the mgr-output connections.
> They shouldn't really be interested in that. All they want is a display
> device that works, and a way to get the mgr used for the display.
>
> Well, I think we can hide the implementation inside omapdss, so that
> omapfb/omapdrm will just need to call one omapdss func when they are
> started, which will connect the mgrs to outputs.
>
> A downside with setting up the mgr-output links at one go, when
> omapfb/omapdrm starts, is that it creates a strict load order
> restriction between omapdss, panels and omapfb/omapdrm. The drivers will
> need to be loaded in that order, or things won't work.
Yes, that's true.
>
> Another option would be to pass information about mgr-output links from
> the board files (or DT data) to the omapdss driver, so that omapdss
> could setup them at probe time. With this option omapfb/omapdrm doesn't
> need to care about this, and it doesn't create load order restriction.
> But mgr-output links are something that I'd really like to handle inside
> the drivers, not something that needs to be passed via platform data.
This would definitely make things simpler, but if this parameter is put
in a panel's DT, it would become omap specific. We could add this info
to the DT corresponding to omapdss.
>
> Third option, which is the best, but also something I have no idea how
> to implement, would be to create the mgr-output links dynamically when
> needed. The problem here is, of course, that a mgr could be allocated to
> an output, only to be later found out that that particular mgr is needed
> for another output.
>
> But this is something we could study a bit: can we create such mgr
> allocation system, that no matter what outputs the board uses, it'll
> just work.
Yes, that would be quite useful. But I think we'll hit situations where
it is sort of impossible to prevent the above situation.
When an output needs a manager. We could study the current state of the
system by splitting managers into 2 sets:
A: managers which already have outputs connected to them
B: managers which don't have an output, but might get connected to one
in the future.
managers in A are lost, and we can't detach them, we would need to at
least disable/reenable the panel with a new manager connected to the output.
we need to find one from B such that maximum outputs(or some other
weightage factor) will still be supported after this new link is made.
The system will initially have all managers in B, but eventually
managers will move to A. We need to move one manager from B to A for
every mgr-output link.
I guess I just described the problem in a more mathematical way, without
providing any solution :), but it does look like an optimisation problem.
>
> So, for example, on omap4, LCD2 mgr can be used for DPI, DSI2, DSI1, and
> RFBI. LCD1 can be used for RFBI and DSI1. If we know that DSI1 and RFBI
> cannot be used at the same time, we're free to give LCD1 to either one.
But they can be used together, can't they? LCD1->DSI1 and LCD2->RFBI.
Are you creating this constraint by assuming what the board is like? Or
is this a constraint of OMAP DSS HW?
> And if we know that DPI and DSI2 cannot be used at the same time, we're
> also free to give LCD2 to either one. And if that's the case, there are
> no conflicts.
This is also possible at the same time: TV->DPI and LCD2->DSI2
>
> I don't know if we can find such allocation for all current omaps, and I
> know it's slightly risky as the next omap could have limitations even if
> current ones do not.
I don't understand the example so well, but I get your point of taking
advantage of such limitations.
>
>> Also, we would need to do this for omapdrm separately using it's own
>> encoder/connector entities.
>
> Yep. That's also a negative side: both omapfb/omapdrm will need to
> implement the same stuff, even if neither of them are really interested
> in that stuff.
Yes. I wonder if crtcs, encoders and connectors already have some sort
of helpers for this?
Archit
^ permalink raw reply
* Re: [PATCH 5/5] OMAPFB: connect ovl managers to all dssdevs
From: Tomi Valkeinen @ 2012-12-10 10:07 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <50C5B154.9080305@ti.com>
[-- Attachment #1: Type: text/plain, Size: 4743 bytes --]
On 2012-12-10 11:54, Archit Taneja wrote:
> On Monday 10 December 2012 01:33 PM, Tomi Valkeinen wrote:
>> Another option would be to pass information about mgr-output links from
>> the board files (or DT data) to the omapdss driver, so that omapdss
>> could setup them at probe time. With this option omapfb/omapdrm doesn't
>> need to care about this, and it doesn't create load order restriction.
>> But mgr-output links are something that I'd really like to handle inside
>> the drivers, not something that needs to be passed via platform data.
>
> This would definitely make things simpler, but if this parameter is put
> in a panel's DT, it would become omap specific. We could add this info
> to the DT corresponding to omapdss.
Yes, I meant it should be omapdss platform data. Nothing related to panels.
>> Third option, which is the best, but also something I have no idea how
>> to implement, would be to create the mgr-output links dynamically when
>> needed. The problem here is, of course, that a mgr could be allocated to
>> an output, only to be later found out that that particular mgr is needed
>> for another output.
>>
>> But this is something we could study a bit: can we create such mgr
>> allocation system, that no matter what outputs the board uses, it'll
>> just work.
>
> Yes, that would be quite useful. But I think we'll hit situations where
> it is sort of impossible to prevent the above situation.
>
> When an output needs a manager. We could study the current state of the
> system by splitting managers into 2 sets:
>
> A: managers which already have outputs connected to them
> B: managers which don't have an output, but might get connected to one
> in the future.
>
> managers in A are lost, and we can't detach them, we would need to at
> least disable/reenable the panel with a new manager connected to the
> output.
>
> we need to find one from B such that maximum outputs(or some other
> weightage factor) will still be supported after this new link is made.
>
> The system will initially have all managers in B, but eventually
> managers will move to A. We need to move one manager from B to A for
> every mgr-output link.
>
> I guess I just described the problem in a more mathematical way, without
> providing any solution :), but it does look like an optimisation problem.
Well, optimization problem sounds like something that can always be
solved. But in this case the driver may need to predict what outputs
will be used, which is of course impossible.
>> So, for example, on omap4, LCD2 mgr can be used for DPI, DSI2, DSI1, and
>> RFBI. LCD1 can be used for RFBI and DSI1. If we know that DSI1 and RFBI
>> cannot be used at the same time, we're free to give LCD1 to either one.
>
> But they can be used together, can't they? LCD1->DSI1 and LCD2->RFBI.
> Are you creating this constraint by assuming what the board is like? Or
> is this a constraint of OMAP DSS HW?
I didn't check if they can be used together or not, I was just guessing.
At least on OMAP3 DSI and RFBI shared the same pins, so they could not
be used at the same time.
Perhaps we should implement a mixed approach: the driver presumes
certain things, like "if DSI is used, RFBI is not used", based on the
knowledge of what kind of boards there currently are. This would allow
us to manage the mgr->output connections in the driver for, say, 95% of
the cases. Then we'd also have the platform data parameters for omapdss,
which could be used in the weird cases.
>> And if we know that DPI and DSI2 cannot be used at the same time, we're
>> also free to give LCD2 to either one. And if that's the case, there are
>> no conflicts.
>
> This is also possible at the same time: TV->DPI and LCD2->DSI2
True. I was just again guessing. On OMAP3 DPI and DSI shared the same pins.
Thinking about this, OMAP4 does have separate pins for DSI, doesn't it?
So my guesses don't hold.
>> I don't know if we can find such allocation for all current omaps, and I
>> know it's slightly risky as the next omap could have limitations even if
>> current ones do not.
>
> I don't understand the example so well, but I get your point of taking
> advantage of such limitations.
>
>>
>>> Also, we would need to do this for omapdrm separately using it's own
>>> encoder/connector entities.
>>
>> Yep. That's also a negative side: both omapfb/omapdrm will need to
>> implement the same stuff, even if neither of them are really interested
>> in that stuff.
>
> Yes. I wonder if crtcs, encoders and connectors already have some sort
> of helpers for this?
Probably nothing that helps us, as this is OMAP HW restriction.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH v4] fbdev: sh_mobile_lcdc: use dma_mmap_coherent
From: Hideki EIRAKU @ 2012-12-10 10:31 UTC (permalink / raw)
To: laurent.pinchart
Cc: FlorianSchandinat, linux-fbdev, linux-kernel, m.szyprowski, matsu,
dhobsong
In-Reply-To: <14014166.3JMiBq7jRA@avalon>
Hi Laurent,
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [PATCH v4] fbdev: sh_mobile_lcdc: use dma_mmap_coherent
Date: Thu, 16 Aug 2012 14:16:32 +0200
> Hi Eiraku-san,
>
> On Thursday 16 August 2012 19:13:20 Hideki EIRAKU wrote:
>> fb_mmap() implemented in fbmem.c uses smem_start as the physical
>> address of the frame buffer. In the sh_mobile_lcdc driver, the
>> smem_start is a dma_addr_t that is not a physical address when IOMMU is
>> enabled. dma_mmap_coherent() maps the address correctly.
>>
>> Signed-off-by: Hideki EIRAKU <hdk@igel.co.jp>
>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> I will push the patch to v3.7 through my tree.
I'd like to use this patch to test IOMMU implementation of Renesas
IPMMU. But I could not find it in v3.7-rc8. Could you please tell me if
this has already been merged somewhere or not?
--
Hideki EIRAKU <hdk@igel.co.jp>
^ permalink raw reply
* Re: [PATCH 5/5] OMAPFB: connect ovl managers to all dssdevs
From: Archit Taneja @ 2012-12-10 10:54 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <50C5B44E.3040304@ti.com>
On Monday 10 December 2012 03:37 PM, Tomi Valkeinen wrote:
> On 2012-12-10 11:54, Archit Taneja wrote:
>> On Monday 10 December 2012 01:33 PM, Tomi Valkeinen wrote:
>
>>> Another option would be to pass information about mgr-output links from
>>> the board files (or DT data) to the omapdss driver, so that omapdss
>>> could setup them at probe time. With this option omapfb/omapdrm doesn't
>>> need to care about this, and it doesn't create load order restriction.
>>> But mgr-output links are something that I'd really like to handle inside
>>> the drivers, not something that needs to be passed via platform data.
>>
>> This would definitely make things simpler, but if this parameter is put
>> in a panel's DT, it would become omap specific. We could add this info
>> to the DT corresponding to omapdss.
>
> Yes, I meant it should be omapdss platform data. Nothing related to panels.
I think this is the easiest way out. We can have one parameter per
output in DT. If we do come up with a way to implement the 3rd option
below, we can always ignore those DT fields(assuming our implementation
to give the same result). So in this way, we would just be deprecating a
DT field in the future, and calculating it ourselves.
>
>>> Third option, which is the best, but also something I have no idea how
>>> to implement, would be to create the mgr-output links dynamically when
>>> needed. The problem here is, of course, that a mgr could be allocated to
>>> an output, only to be later found out that that particular mgr is needed
>>> for another output.
>>>
>>> But this is something we could study a bit: can we create such mgr
>>> allocation system, that no matter what outputs the board uses, it'll
>>> just work.
>>
>> Yes, that would be quite useful. But I think we'll hit situations where
>> it is sort of impossible to prevent the above situation.
>>
>> When an output needs a manager. We could study the current state of the
>> system by splitting managers into 2 sets:
>>
>> A: managers which already have outputs connected to them
>> B: managers which don't have an output, but might get connected to one
>> in the future.
>>
>> managers in A are lost, and we can't detach them, we would need to at
>> least disable/reenable the panel with a new manager connected to the
>> output.
>>
>> we need to find one from B such that maximum outputs(or some other
>> weightage factor) will still be supported after this new link is made.
>>
>> The system will initially have all managers in B, but eventually
>> managers will move to A. We need to move one manager from B to A for
>> every mgr-output link.
>>
>> I guess I just described the problem in a more mathematical way, without
>> providing any solution :), but it does look like an optimisation problem.
>
> Well, optimization problem sounds like something that can always be
> solved. But in this case the driver may need to predict what outputs
> will be used, which is of course impossible.
>
>>> So, for example, on omap4, LCD2 mgr can be used for DPI, DSI2, DSI1, and
>>> RFBI. LCD1 can be used for RFBI and DSI1. If we know that DSI1 and RFBI
>>> cannot be used at the same time, we're free to give LCD1 to either one.
>>
>> But they can be used together, can't they? LCD1->DSI1 and LCD2->RFBI.
>> Are you creating this constraint by assuming what the board is like? Or
>> is this a constraint of OMAP DSS HW?
>
> I didn't check if they can be used together or not, I was just guessing.
> At least on OMAP3 DSI and RFBI shared the same pins, so they could not
> be used at the same time.
>
> Perhaps we should implement a mixed approach: the driver presumes
> certain things, like "if DSI is used, RFBI is not used", based on the
> knowledge of what kind of boards there currently are. This would allow
> us to manage the mgr->output connections in the driver for, say, 95% of
> the cases. Then we'd also have the platform data parameters for omapdss,
> which could be used in the weird cases.
Let's just have platform data parameters :)
>
>>> And if we know that DPI and DSI2 cannot be used at the same time, we're
>>> also free to give LCD2 to either one. And if that's the case, there are
>>> no conflicts.
>>
>> This is also possible at the same time: TV->DPI and LCD2->DSI2
>
> True. I was just again guessing. On OMAP3 DPI and DSI shared the same pins.
>
> Thinking about this, OMAP4 does have separate pins for DSI, doesn't it?
> So my guesses don't hold.
>
>>> I don't know if we can find such allocation for all current omaps, and I
>>> know it's slightly risky as the next omap could have limitations even if
>>> current ones do not.
>>
>> I don't understand the example so well, but I get your point of taking
>> advantage of such limitations.
>>
>>>
>>>> Also, we would need to do this for omapdrm separately using it's own
>>>> encoder/connector entities.
>>>
>>> Yep. That's also a negative side: both omapfb/omapdrm will need to
>>> implement the same stuff, even if neither of them are really interested
>>> in that stuff.
>>
>> Yes. I wonder if crtcs, encoders and connectors already have some sort
>> of helpers for this?
>
> Probably nothing that helps us, as this is OMAP HW restriction.
If we do use DT/platform data, would we need to parse it in omapdrm to
establish drm entities? Or do we rely on omapdss to parse the DT data
and give the links to omapdrm?
Archit
^ permalink raw reply
* Re: [PATCH 5/5] OMAPFB: connect ovl managers to all dssdevs
From: Tomi Valkeinen @ 2012-12-10 11:03 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <50C5BF32.1080006@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2485 bytes --]
On 2012-12-10 12:53, Archit Taneja wrote:
> On Monday 10 December 2012 03:37 PM, Tomi Valkeinen wrote:
>> On 2012-12-10 11:54, Archit Taneja wrote:
>>> On Monday 10 December 2012 01:33 PM, Tomi Valkeinen wrote:
>>
>>>> Another option would be to pass information about mgr-output links from
>>>> the board files (or DT data) to the omapdss driver, so that omapdss
>>>> could setup them at probe time. With this option omapfb/omapdrm doesn't
>>>> need to care about this, and it doesn't create load order restriction.
>>>> But mgr-output links are something that I'd really like to handle
>>>> inside
>>>> the drivers, not something that needs to be passed via platform data.
>>>
>>> This would definitely make things simpler, but if this parameter is put
>>> in a panel's DT, it would become omap specific. We could add this info
>>> to the DT corresponding to omapdss.
>>
>> Yes, I meant it should be omapdss platform data. Nothing related to
>> panels.
>
> I think this is the easiest way out. We can have one parameter per
> output in DT. If we do come up with a way to implement the 3rd option
> below, we can always ignore those DT fields(assuming our implementation
> to give the same result). So in this way, we would just be deprecating a
> DT field in the future, and calculating it ourselves.
I would rather go the other way around: calculate it ourselves
(presuming it can be done for the current boards), and add the DT field
later if we come up with boards that won't work with the dynamic approach.
The reasons I'm not too happy with having the parameter in the DT data
is that:
- DT should be about describing the hardware connections between
components, but in this case it's dynamically configurable connection.
- We need to have the DT parameter for all cases, even if in 95% of
cases it's not really needed.
- We may never need the parameter, if we never get boards that require
funny setup.
> If we do use DT/platform data, would we need to parse it in omapdrm to
> establish drm entities? Or do we rely on omapdss to parse the DT data
> and give the links to omapdrm?
I think we should parse it in omapdss and setup the connections at
omapdss's probe. Then when omapfb/omapdrm starts, they can get
information about the connections from omapdss, and setup their entities
as they want.
So omapdss would setup the mgr->output->panel links, and they would be
ready for omapfb/omapdrm to use.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* [PATCH 0/3] atmel_lcdfb: fix 16-bpp regression
From: Johan Hovold @ 2012-12-10 12:28 UTC (permalink / raw)
To: linux-arm-kernel
These patches fix a regression in 16-bpp support for older SOCs which use
IBGR:555 rather than BGR:565 pixel layout. Use SOC-type to determine if the
controller uses the intensity-bit and restore the old layout in that case.
The third patch is simply a clean up.
Thanks,
Johan
Johan Hovold (3):
atmel_lcdfb: fix 16-bpp modes on older SOCs
ARM: at91/neocore926: fix LCD-wiring mode
atmel_lcdfb: remove unsupported 15-bpp mode
arch/arm/mach-at91/board-neocore926.c | 2 +-
drivers/video/atmel_lcdfb.c | 23 +++++++++++++++--------
include/video/atmel_lcdc.h | 2 +-
3 files changed, 17 insertions(+), 10 deletions(-)
--
1.8.0
^ permalink raw reply
* [PATCH 1/3] atmel_lcdfb: fix 16-bpp modes on older SOCs
From: Johan Hovold @ 2012-12-10 12:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355142530-10366-1-git-send-email-jhovold@gmail.com>
Fix regression introduced by commit 787f9fd23283 ("atmel_lcdfb: support
16bit BGR:565 mode, remove unsupported 15bit modes") which broke 16-bpp
modes for older SOCs which use IBGR:555 (msb is intensity) rather
than BGR:565.
Use SOC-type to determine the pixel layout.
Tested on custom at91sam9263-board.
Cc: <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
---
drivers/video/atmel_lcdfb.c | 22 +++++++++++++++-------
include/video/atmel_lcdc.h | 1 +
2 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index 1505539..1f68fa6 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -422,17 +422,22 @@ static int atmel_lcdfb_check_var(struct fb_var_screeninfo *var,
= var->bits_per_pixel;
break;
case 16:
+ /* Older SOCs use IBGR:555 rather than BGR:565. */
+ if (sinfo->have_intensity_bit)
+ var->green.length = 5;
+ else
+ var->green.length = 6;
+
if (sinfo->lcd_wiring_mode = ATMEL_LCDC_WIRING_RGB) {
- /* RGB:565 mode */
- var->red.offset = 11;
+ /* RGB:5X5 mode */
+ var->red.offset = var->green.length + 5;
var->blue.offset = 0;
} else {
- /* BGR:565 mode */
+ /* BGR:5X5 mode */
var->red.offset = 0;
- var->blue.offset = 11;
+ var->blue.offset = var->green.length + 5;
}
var->green.offset = 5;
- var->green.length = 6;
var->red.length = var->blue.length = 5;
break;
case 32:
@@ -679,8 +684,7 @@ static int atmel_lcdfb_setcolreg(unsigned int regno, unsigned int red,
case FB_VISUAL_PSEUDOCOLOR:
if (regno < 256) {
- if (cpu_is_at91sam9261() || cpu_is_at91sam9263()
- || cpu_is_at91sam9rl()) {
+ if (sinfo->have_intensity_bit) {
/* old style I+BGR:555 */
val = ((red >> 11) & 0x001f);
val |= ((green >> 6) & 0x03e0);
@@ -870,6 +874,10 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
}
sinfo->info = info;
sinfo->pdev = pdev;
+ if (cpu_is_at91sam9261() || cpu_is_at91sam9263() ||
+ cpu_is_at91sam9rl()) {
+ sinfo->have_intensity_bit = true;
+ }
strcpy(info->fix.id, sinfo->pdev->name);
info->flags = ATMEL_LCDFB_FBINFO_DEFAULT;
diff --git a/include/video/atmel_lcdc.h b/include/video/atmel_lcdc.h
index 28447f1..5f0e234 100644
--- a/include/video/atmel_lcdc.h
+++ b/include/video/atmel_lcdc.h
@@ -62,6 +62,7 @@ struct atmel_lcdfb_info {
void (*atmel_lcdfb_power_control)(int on);
struct fb_monspecs *default_monspecs;
u32 pseudo_palette[16];
+ bool have_intensity_bit;
};
#define ATMEL_LCDC_DMABADDR1 0x00
--
1.8.0
^ permalink raw reply related
* [PATCH 2/3] ARM: at91/neocore926: fix LCD-wiring mode
From: Johan Hovold @ 2012-12-10 12:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355142530-10366-1-git-send-email-jhovold@gmail.com>
Fix regression introduced by commit 787f9fd23283 ("atmel_lcdfb: support
16bit BGR:565 mode, remove unsupported 15bit modes") which broke 16-bpp
modes for older SOCs which use IBGR:555 (msb is intensity) rather than
BGR:565.
The above commit also removed the RGB:555-wiring hack without fixing the
neocore926 board which used it. Fix by specifying RGB-wiring and let the
driver handle the final SOC-dependant layout.
Remove the no longer used ATMEL_LCDC_WIRING_RGB555 define.
Compile-only tested.
Cc: <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
---
arch/arm/mach-at91/board-neocore926.c | 2 +-
include/video/atmel_lcdc.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/mach-at91/board-neocore926.c b/arch/arm/mach-at91/board-neocore926.c
index 997d359..daeb7c6 100644
--- a/arch/arm/mach-at91/board-neocore926.c
+++ b/arch/arm/mach-at91/board-neocore926.c
@@ -265,7 +265,7 @@ static struct atmel_lcdfb_info __initdata neocore926_lcdc_data = {
.default_monspecs = &at91fb_default_monspecs,
.atmel_lcdfb_power_control = at91_lcdc_power_control,
.guard_time = 1,
- .lcd_wiring_mode = ATMEL_LCDC_WIRING_RGB555,
+ .lcd_wiring_mode = ATMEL_LCDC_WIRING_RGB,
};
#else
diff --git a/include/video/atmel_lcdc.h b/include/video/atmel_lcdc.h
index 5f0e234..8deb226 100644
--- a/include/video/atmel_lcdc.h
+++ b/include/video/atmel_lcdc.h
@@ -30,7 +30,6 @@
*/
#define ATMEL_LCDC_WIRING_BGR 0
#define ATMEL_LCDC_WIRING_RGB 1
-#define ATMEL_LCDC_WIRING_RGB555 2
/* LCD Controller info data structure, stored in device platform_data */
--
1.8.0
^ permalink raw reply related
* [PATCH 3/3] atmel_lcdfb: remove unsupported 15-bpp mode
From: Johan Hovold @ 2012-12-10 12:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355142530-10366-1-git-send-email-jhovold@gmail.com>
Since commit 787f9fd23283 ("atmel_lcdfb: support 16bit BGR:565 mode,
remove unsupported 15bit modes") atmel_lcdfb_check_var does not accept
15-bpp mode so remove it from atmel_lcdfb_set_par as well.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
---
drivers/video/atmel_lcdfb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index 1f68fa6..3cdbd53 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -567,7 +567,6 @@ static int atmel_lcdfb_set_par(struct fb_info *info)
case 2: value |= ATMEL_LCDC_PIXELSIZE_2; break;
case 4: value |= ATMEL_LCDC_PIXELSIZE_4; break;
case 8: value |= ATMEL_LCDC_PIXELSIZE_8; break;
- case 15: /* fall through */
case 16: value |= ATMEL_LCDC_PIXELSIZE_16; break;
case 24: value |= ATMEL_LCDC_PIXELSIZE_24; break;
case 32: value |= ATMEL_LCDC_PIXELSIZE_32; break;
--
1.8.0
^ permalink raw reply related
* Re: [PATCH 1/3] atmel_lcdfb: fix 16-bpp modes on older SOCs
From: Peter Korsgaard @ 2012-12-10 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355142530-10366-2-git-send-email-jhovold@gmail.com>
>>>>> "Johan" = Johan Hovold <jhovold@gmail.com> writes:
Johan> Fix regression introduced by commit 787f9fd23283 ("atmel_lcdfb: support
Johan> 16bit BGR:565 mode, remove unsupported 15bit modes") which broke 16-bpp
Johan> modes for older SOCs which use IBGR:555 (msb is intensity) rather
Johan> than BGR:565.
Johan> Use SOC-type to determine the pixel layout.
Johan> Tested on custom at91sam9263-board.
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 2/3] ARM: at91/neocore926: fix LCD-wiring mode
From: Peter Korsgaard @ 2012-12-10 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355142530-10366-3-git-send-email-jhovold@gmail.com>
>>>>> "Johan" = Johan Hovold <jhovold@gmail.com> writes:
Johan> Fix regression introduced by commit 787f9fd23283 ("atmel_lcdfb: support
Johan> 16bit BGR:565 mode, remove unsupported 15bit modes") which broke 16-bpp
Johan> modes for older SOCs which use IBGR:555 (msb is intensity) rather than
Johan> BGR:565.
Johan> The above commit also removed the RGB:555-wiring hack without fixing the
Johan> neocore926 board which used it. Fix by specifying RGB-wiring and let the
Johan> driver handle the final SOC-dependant layout.
Johan> Remove the no longer used ATMEL_LCDC_WIRING_RGB555 define.
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 3/3] atmel_lcdfb: remove unsupported 15-bpp mode
From: Peter Korsgaard @ 2012-12-10 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355142530-10366-4-git-send-email-jhovold@gmail.com>
>>>>> "Johan" = Johan Hovold <jhovold@gmail.com> writes:
Johan> Since commit 787f9fd23283 ("atmel_lcdfb: support 16bit BGR:565 mode,
Johan> remove unsupported 15bit modes") atmel_lcdfb_check_var does not accept
Johan> 15-bpp mode so remove it from atmel_lcdfb_set_par as well.
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH v4] fbdev: sh_mobile_lcdc: use dma_mmap_coherent
From: Laurent Pinchart @ 2012-12-10 22:54 UTC (permalink / raw)
To: Hideki EIRAKU
Cc: FlorianSchandinat, linux-fbdev, linux-kernel, m.szyprowski, matsu,
dhobsong
In-Reply-To: <20121210.193125.442743545.hdk@igel.co.jp>
Hi Eiraku-san,
On Monday 10 December 2012 19:31:25 Hideki EIRAKU wrote:
> On Thu, 16 Aug 2012 14:16:32 +0200 Laurent Pinchart wrote:
> > On Thursday 16 August 2012 19:13:20 Hideki EIRAKU wrote:
> >> fb_mmap() implemented in fbmem.c uses smem_start as the physical
> >> address of the frame buffer. In the sh_mobile_lcdc driver, the
> >> smem_start is a dma_addr_t that is not a physical address when IOMMU is
> >> enabled. dma_mmap_coherent() maps the address correctly.
> >>
> >> Signed-off-by: Hideki EIRAKU <hdk@igel.co.jp>
> >
> > Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> >
> > I will push the patch to v3.7 through my tree.
>
> I'd like to use this patch to test IOMMU implementation of Renesas
> IPMMU. But I could not find it in v3.7-rc8. Could you please tell me if
> this has already been merged somewhere or not?
I'm afraid the patch got delayed to v3.8, sorry about that. I've sent a pull
request for v3.8, the patch is currently in linux-next
(bf10a53765b4435a5349a92a5a51753902ed86f1) and will be merged during the next
merge window (which should open in the very near future).
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 10/19] MAINTAINERS: fix .../plat-mxc/include/mach/imxfb.h
From: Cesar Eduardo Barros @ 2012-12-11 21:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355262601-4263-1-git-send-email-cesarb@cesarb.net>
This file was moved to include/linux/platform_data/video-imxfb.h by
commit 82906b1 (ARM: imx: move platform_data definitions).
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Cesar Eduardo Barros <cesarb@cesarb.net>
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3bf84d4..9bc4861d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3138,7 +3138,7 @@ M: Sascha Hauer <kernel@pengutronix.de>
L: linux-fbdev@vger.kernel.org
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
-F: arch/arm/plat-mxc/include/mach/imxfb.h
+F: include/linux/platform_data/video-imxfb.h
F: drivers/video/imxfb.c
FREESCALE SOC FS_ENET DRIVER
--
1.7.11.7
^ permalink raw reply related
* [PATCH 1/1] video: exynos: Use devm_* APIs in s6e8ax0.c
From: Sachin Kamat @ 2012-12-12 5:23 UTC (permalink / raw)
To: linux-fbdev
devm_* APIs are device managed and make error handling
and code cleanup simpler.
Cc: Donghwa Lee <dh09.lee@samsung.com>
Cc: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
Compile tested against linux-next.
---
drivers/video/exynos/s6e8ax0.c | 14 ++++----------
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/video/exynos/s6e8ax0.c b/drivers/video/exynos/s6e8ax0.c
index 05d080b..ca26024 100644
--- a/drivers/video/exynos/s6e8ax0.c
+++ b/drivers/video/exynos/s6e8ax0.c
@@ -776,7 +776,7 @@ static int s6e8ax0_probe(struct mipi_dsim_lcd_device *dsim_dev)
int ret;
u8 mtp_id[3] = {0, };
- lcd = kzalloc(sizeof(struct s6e8ax0), GFP_KERNEL);
+ lcd = devm_kzalloc(&dsim_dev->dev, sizeof(struct s6e8ax0), GFP_KERNEL);
if (!lcd) {
dev_err(&dsim_dev->dev, "failed to allocate s6e8ax0 structure.\n");
return -ENOMEM;
@@ -788,18 +788,17 @@ static int s6e8ax0_probe(struct mipi_dsim_lcd_device *dsim_dev)
mutex_init(&lcd->lock);
- ret = regulator_bulk_get(lcd->dev, ARRAY_SIZE(supplies), supplies);
+ ret = devm_regulator_bulk_get(lcd->dev, ARRAY_SIZE(supplies), supplies);
if (ret) {
dev_err(lcd->dev, "Failed to get regulators: %d\n", ret);
- goto err_lcd_register;
+ return ret;
}
lcd->ld = lcd_device_register("s6e8ax0", lcd->dev, lcd,
&s6e8ax0_lcd_ops);
if (IS_ERR(lcd->ld)) {
dev_err(lcd->dev, "failed to register lcd ops.\n");
- ret = PTR_ERR(lcd->ld);
- goto err_lcd_register;
+ return PTR_ERR(lcd->ld);
}
lcd->bd = backlight_device_register("s6e8ax0-bl", lcd->dev, lcd,
@@ -838,11 +837,6 @@ static int s6e8ax0_probe(struct mipi_dsim_lcd_device *dsim_dev)
err_backlight_register:
lcd_device_unregister(lcd->ld);
-
-err_lcd_register:
- regulator_bulk_free(ARRAY_SIZE(supplies), supplies);
- kfree(lcd);
-
return ret;
}
--
1.7.4.1
^ permalink raw reply related
* RE: [PATCH] da8xx: Allow use by am33xx based devices
From: Manjunathappa, Prakash @ 2012-12-12 7:20 UTC (permalink / raw)
To: Hiremath, Vaibhav
Cc: Valkeinen, Tomi, davinci-linux-open-source@linux.davincidsp.com,
Porter, Matt, linux-fbdev@vger.kernel.org,
FlorianSchandinat@gmx.de, Koen Kooi, Pantelis Antoniou,
linux-kernel@vger.kernel.org, Dill, Russ,
linux-omap@vger.kernel.org
In-Reply-To: <50C5A50E.4070602@ti.com>
Hi Vaibhav,
On Mon, Dec 10, 2012 at 14:32:06, Hiremath, Vaibhav wrote:
>
>
> On 12/6/2012 1:38 PM, Manjunathappa, Prakash wrote:
> > Hi Tomi,
> >
> > On Wed, Oct 31, 2012 at 10:52:59, Manjunathappa, Prakash wrote:
> >> Hi,
> >>
> >> On Wed, Oct 31, 2012 at 21:26:08, Pantelis Antoniou wrote:
> >>> This driver can be used for AM33xx devices, like the popular beaglebone.
> >>>
> >>> Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
> >>> ---
> >>> drivers/video/Kconfig | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> >>> index 9791d10..e7868d8 100644
> >>> --- a/drivers/video/Kconfig
> >>> +++ b/drivers/video/Kconfig
> >>> @@ -2202,7 +2202,7 @@ config FB_SH7760
> >>>
> >>> config FB_DA8XX
> >>> tristate "DA8xx/OMAP-L1xx Framebuffer support"
> >>> - depends on FB && ARCH_DAVINCI_DA8XX
> >>> + depends on FB && (ARCH_DAVINCI_DA8XX || SOC_AM33XX)
> >>
> >> Agreed this is present on da8xx and am33xx, but moving forward for
> >> supporting DT, we should be avoiding these dependencies. So instead
> >> change this to remove machine dependencies.
> >>
> >
> > I could be wrong here, having dependency on platform seems to be right.
> > Otherwise may lead to build errors for other platforms.
>
> No, it should not result in to build error unless driver uses some
> platform specific api's.
>
Agreed, should not result in build error. But is it ok to show this option
on the platforms which do not have this IP?
Thanks,
Prakash
^ permalink raw reply
* RE: [PATCH] da8xx: Allow use by am33xx based devices
From: Hiremath, Vaibhav @ 2012-12-12 8:00 UTC (permalink / raw)
To: Manjunathappa, Prakash
Cc: Valkeinen, Tomi, davinci-linux-open-source@linux.davincidsp.com,
Porter, Matt, linux-fbdev@vger.kernel.org,
FlorianSchandinat@gmx.de, Koen Kooi, Pantelis Antoniou,
linux-kernel@vger.kernel.org, Dill, Russ,
linux-omap@vger.kernel.org
In-Reply-To: <A73F36158E33644199EB82C5EC81C7BC3EA17E45@DBDE01.ent.ti.com>
On Wed, Dec 12, 2012 at 12:50:28, Manjunathappa, Prakash wrote:
> Hi Vaibhav,
>
> On Mon, Dec 10, 2012 at 14:32:06, Hiremath, Vaibhav wrote:
> >
> >
> > On 12/6/2012 1:38 PM, Manjunathappa, Prakash wrote:
> > > Hi Tomi,
> > >
> > > On Wed, Oct 31, 2012 at 10:52:59, Manjunathappa, Prakash wrote:
> > >> Hi,
> > >>
> > >> On Wed, Oct 31, 2012 at 21:26:08, Pantelis Antoniou wrote:
> > >>> This driver can be used for AM33xx devices, like the popular beaglebone.
> > >>>
> > >>> Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
> > >>> ---
> > >>> drivers/video/Kconfig | 2 +-
> > >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> > >>>
> > >>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > >>> index 9791d10..e7868d8 100644
> > >>> --- a/drivers/video/Kconfig
> > >>> +++ b/drivers/video/Kconfig
> > >>> @@ -2202,7 +2202,7 @@ config FB_SH7760
> > >>>
> > >>> config FB_DA8XX
> > >>> tristate "DA8xx/OMAP-L1xx Framebuffer support"
> > >>> - depends on FB && ARCH_DAVINCI_DA8XX
> > >>> + depends on FB && (ARCH_DAVINCI_DA8XX || SOC_AM33XX)
> > >>
> > >> Agreed this is present on da8xx and am33xx, but moving forward for
> > >> supporting DT, we should be avoiding these dependencies. So instead
> > >> change this to remove machine dependencies.
> > >>
> > >
> > > I could be wrong here, having dependency on platform seems to be right.
> > > Otherwise may lead to build errors for other platforms.
> >
> > No, it should not result in to build error unless driver uses some
> > platform specific api's.
> >
>
> Agreed, should not result in build error. But is it ok to show this option
> on the platforms which do not have this IP?
>
You can choose to put machine dependency here, as this patch is already
doing it. The side-effect of this would be, list may grow and you may have
to edit this file everytime.
Thanks,
Vaibhav
^ permalink raw reply
* [PATCH 1/2] OMAPDSS: DISPC: get dss clock rate from dss driver
From: Tomi Valkeinen @ 2012-12-12 12:27 UTC (permalink / raw)
To: Archit Taneja, linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
Dispc currently gets dispc's fck with clk_get() and uses clk_get_rate()
to get the rate for scaling calculations. This causes a problem with
common clock framework, as omapdss uses the dispc functions inside a
spinlock, and common clock framework uses a mutex in clk_get_rate().
Looking at the DSS clock tree, the above use of the dispc fck is not
quite correct. The DSS_FCLK from PRCM goes to DSS core block, which has
a mux to select the clock for DISPC from various options, so the current
use of dispc fck bypasses that. Fortunately we never change the dispc
clock mux for now.
To fix the issue with clk_get_rate(), this patch caches the dss clock
rate in dss.c when it is set. Dispc will then ask for the clock rate
from dss. While this is not very elegant, it does fix the issue, and
it's not totally wrong when considering that the dispc fck actually
comes via dss.
In the future we should probably look into common clock framework and
see if that could be used to represent the DSS clock tree properly.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dispc.c | 4 ++--
drivers/video/omap2/dss/dss.c | 12 ++++++++++++
drivers/video/omap2/dss/dss.h | 1 +
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index fedbd2c..08137a8 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2970,7 +2970,7 @@ unsigned long dispc_fclk_rate(void)
switch (dss_get_dispc_clk_source()) {
case OMAP_DSS_CLK_SRC_FCK:
- r = clk_get_rate(dispc.dss_clk);
+ r = dss_get_dispc_clk_rate();
break;
case OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC:
dsidev = dsi_get_dsidev_from_id(0);
@@ -3002,7 +3002,7 @@ unsigned long dispc_mgr_lclk_rate(enum omap_channel channel)
switch (dss_get_lcd_clk_source(channel)) {
case OMAP_DSS_CLK_SRC_FCK:
- r = clk_get_rate(dispc.dss_clk);
+ r = dss_get_dispc_clk_rate();
break;
case OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC:
dsidev = dsi_get_dsidev_from_id(0);
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 833f162..054c2a2 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -77,6 +77,7 @@ static struct {
struct clk *dpll4_m4_ck;
struct clk *dss_clk;
+ unsigned long dss_clk_rate;
unsigned long cache_req_pck;
unsigned long cache_prate;
@@ -489,6 +490,10 @@ int dss_set_clock_div(struct dss_clock_info *cinfo)
return -EINVAL;
}
+ dss.dss_clk_rate = clk_get_rate(dss.dss_clk);
+
+ WARN_ONCE(dss.dss_clk_rate != cinfo->fck, "clk rate mismatch");
+
DSSDBG("fck = %ld (%d)\n", cinfo->fck, cinfo->fck_div);
return 0;
@@ -502,6 +507,11 @@ unsigned long dss_get_dpll4_rate(void)
return 0;
}
+unsigned long dss_get_dispc_clk_rate(void)
+{
+ return dss.dss_clk_rate;
+}
+
static int dss_setup_default_clock(void)
{
unsigned long max_dss_fck, prate;
@@ -953,6 +963,8 @@ static int __init omap_dsshw_probe(struct platform_device *pdev)
if (r)
goto err_runtime_get;
+ dss.dss_clk_rate = clk_get_rate(dss.dss_clk);
+
/* Select DPLL */
REG_FLD_MOD(DSS_CONTROL, 0, 0, 0);
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index ebe9e08..610c8e5 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -237,6 +237,7 @@ void dss_overlay_kobj_uninit(struct omap_overlay *ovl);
int dss_init_platform_driver(void) __init;
void dss_uninit_platform_driver(void);
+unsigned long dss_get_dispc_clk_rate(void);
int dss_dpi_select_source(enum omap_channel channel);
void dss_select_hdmi_venc_clk_source(enum dss_hdmi_venc_clk_source_select);
enum dss_hdmi_venc_clk_source_select dss_get_hdmi_venc_clk_source(void);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/2] OMAPDSS: DISPC: remove dispc fck uses
From: Tomi Valkeinen @ 2012-12-12 12:27 UTC (permalink / raw)
To: Archit Taneja, linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
In-Reply-To: <1355315229-25238-1-git-send-email-tomi.valkeinen@ti.com>
The previous patch changes dispc to get the dispc fck rate from dss core
driver. This was the only use of the dispc fck in dispc, and thus we can
now remove the clock handling.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dispc.c | 14 --------------
1 file changed, 14 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 08137a8..05ff2b9 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -96,7 +96,6 @@ static struct {
int ctx_loss_cnt;
int irq;
- struct clk *dss_clk;
u32 fifo_size[DISPC_MAX_NR_FIFOS];
/* maps which plane is using a fifo. fifo-id -> plane-id */
@@ -3619,7 +3618,6 @@ static int __init omap_dispchw_probe(struct platform_device *pdev)
u32 rev;
int r = 0;
struct resource *dispc_mem;
- struct clk *clk;
dispc.pdev = pdev;
@@ -3646,15 +3644,6 @@ static int __init omap_dispchw_probe(struct platform_device *pdev)
return -ENODEV;
}
- clk = clk_get(&pdev->dev, "fck");
- if (IS_ERR(clk)) {
- DSSERR("can't get fck\n");
- r = PTR_ERR(clk);
- return r;
- }
-
- dispc.dss_clk = clk;
-
pm_runtime_enable(&pdev->dev);
r = dispc_runtime_get();
@@ -3675,7 +3664,6 @@ static int __init omap_dispchw_probe(struct platform_device *pdev)
err_runtime_get:
pm_runtime_disable(&pdev->dev);
- clk_put(dispc.dss_clk);
return r;
}
@@ -3683,8 +3671,6 @@ static int __exit omap_dispchw_remove(struct platform_device *pdev)
{
pm_runtime_disable(&pdev->dev);
- clk_put(dispc.dss_clk);
-
return 0;
}
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v4] video: Versatile Express DVI output driver
From: Pawel Moll @ 2012-12-12 18:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1353343147-15654-1-git-send-email-pawel.moll@arm.com>
Hi Arnd,
On Mon, 2012-11-19 at 16:39 +0000, Pawel Moll wrote:
> Versatile Express' DVI video output can be connected to one the three
> sources - motherboard's CLCD controller or a video signal generated
> by one of the daughterboards.
>
> This driver configures the muxer FPGA so the output displays content
> of one of the framebuffers in the system (0 by default, can be changed
> by user writing to the "fb" sysfs attribute of the muxfpga device).
>
> It will also set up the display formatter mode and keep it up
> to date with mode changes requested by the user (eg. with fbset
> tool).
>
> Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Could I just politely remind about this one?
Paweł
^ permalink raw reply
* Re: [PATCH 2/5] OMAPFB: simplify locking
From: Tomi Valkeinen @ 2012-12-13 11:17 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev, Ville Syrjälä
In-Reply-To: <1354881309-17625-2-git-send-email-tomi.valkeinen@ti.com>
[-- Attachment #1: Type: text/plain, Size: 983 bytes --]
On 2012-12-07 13:55, Tomi Valkeinen wrote:
> Kernel lock verification code has lately detected possible circular
> locking in omapfb. The exact problem is unclear, but omapfb's current
> locking seems to be overly complex.
>
> This patch simplifies the locking in the following ways:
>
> - Remove explicit omapfb mem region locking. I couldn't figure out the
> need for this, as long as we take care to take omapfb lock.
>
> - Get omapfb lock always, even if the operation is possibly only related
> to one fb_info. Better safe than sorry, and normally there's only one
> user for the fb so this shouldn't matter.
>
> - Make sure fb_info lock is taken first, then omapfb lock.
>
> With this patch the warnings about possible circular locking does not
> happen anymore.
I'm dropping this patch, for some reason it causes huge latencies with
two processes using separate fbs. I guess there's need for the more
precise locking, after all.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* [PATCH] video: exynos_mipi_dsi: Add missing mutex_unlock
From: Jonghwan Choi @ 2012-12-14 8:33 UTC (permalink / raw)
To: linux-fbdev
Add a mutex_unlock on the error path.
Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com>
---
drivers/video/exynos/exynos_mipi_dsi_common.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/video/exynos/exynos_mipi_dsi_common.c
b/drivers/video/exynos/exynos_mipi_dsi_common.c
index 3cd29a4..bd7f4f2 100644
--- a/drivers/video/exynos/exynos_mipi_dsi_common.c
+++ b/drivers/video/exynos/exynos_mipi_dsi_common.c
@@ -377,6 +377,7 @@ int exynos_mipi_dsi_rd_data(struct mipi_dsim_device
*dsim, unsigned int data_id,
"data id %x is not supported current DSI spec.\n",
data_id);
+ mutex_unlock(&dsim->lock);
return -EINVAL;
}
--
1.7.4.1
^ permalink raw reply related
* [GIT PULL] fbdev changes for 3.8
From: Tomi Valkeinen @ 2012-12-14 10:22 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-omap, linux-fbdev, linux-kernel, Florian Tobias Schandinat
[-- Attachment #1: Type: text/plain, Size: 20843 bytes --]
Hi Linus,
Florian, the fbdev maintainer, has been very busy lately, so I offered to send
the pull request for fbdev for this merge window.
There are a few conflicts, but they look clear to me.
arch/arm/plat-omap/common.c is to be removed.
Tomi
The following changes since commit 9489e9dcae718d5fde988e4a684a0f55b5f94d17:
Linux 3.7-rc7 (2012-11-25 17:59:19 -0800)
are available in the git repository at:
git://gitorious.org/linux-omap-dss2/linux.git tags/fbdev-for-3.8
for you to fetch changes up to e7f5c9a16ea2648a3e85af8e34191026bf3dcb62:
Merge tag 'omapdss-for-3.8' of git://gitorious.org/linux-omap-dss2/linux into for-linus (2012-12-13 14:30:56 +0200)
----------------------------------------------------------------
fbdev changes for 3.8:
OMAPDSS changes, including:
- use dynanic debug prints
- OMAP platform dependency removals
- Creation of compat-layer, helping us to improve omapdrm
- Misc cleanups, aiming to make omadss more in line with the upcoming common
display framework
Exynos DP changes for the 3.8 merge window:
- Device Tree support for Samsung Exynos DP
- SW Link training is cleaned up.
- HPD interrupt is supported.
Samsung Framebuffer changes for the 3.8 merge window:
- The bit definitions of header file are updated.
- Some minor typos are fixed.
- Some minor bugs of s3c_fb_check_var() are fixed.
FB related changes for SH Mobile, Freescale DIU
Add support for the Solomon SSD1307 OLED Controller
----------------------------------------------------------------
Aaro Koskinen (1):
OMAPDSS: panel-n8x0: register the DSS driver after SPI probe
Ajay Kumar (5):
video: exynos_dp: Add device tree support to DP driver
video: exynos_dp: device tree documentation
video: exynos_dp: Reset and initialize DP before requesting irq
video: exynos_dp: Fix incorrect setting for INT_CTL
video: exynos_dp: remove redundant parameters
Archit Taneja (10):
OMAPDSS: Remove acb and acbi fields from omap_dss_device
OMAPDSS: DISPC: Fix calc_scaling_44xx() bugs for writeback pipeline
OMAPDSS: DISPC: Don't allow predecimation for writeback
OMAPDSS: DISPC: Use output width and height to calculate row/pix inc for writeback
OMAPDSS: APPLY: Don't treat an overlay's channel out as shadow bits
OMAPDSS: APPLY: Remove unnecessary variable in dss_apply_irq_handler
OMAPDSS: APPLY: Remove unnecessary call to mg_clear_shadow_dirty
OMAPDSS: Add overlay manager width and height limits as a dispc feature
OMAPDSS: Add a dispc_features struct for OMAP5
OMAPDSS: Use only "omapdss_dss" platform device to get context lost count
Axel Lin (1):
OMAPDSS: Add terminating entry for picodlp_i2c_id table
Chandrabhanu Mahapatra (5):
OMAPDSS: Move definition of DEBUG flag to Makefile
OMAPDSS: Create new debug config options
OMAPDSS: Cleanup DSSDBG with dynamic pr_debug function
OMAPDSS: Replace multi part debug prints with pr_debug
OMAPDSS: Remove dss_debug variable
Chuansheng Liu (2):
OMAPDSS: DISPC: Fix the usage of wait_for_completion_timeout
OMAPDSS: APPLY: Fix the usage of wait_for_completion_timeout
Hideki EIRAKU (1):
fbdev: sh_mobile_lcdc: use dma_mmap_coherent
Jingoo Han (14):
video: s3c-fb: clean the bit definition for WINCON register
video: s3c-fb: move the address definitions for VIDTCON registers
video: s3c-fb: move the address definition for VIDOSD register
video: s3c-fb: move the bit definitions for VIDINTCON0 register
video: s3c-fb: move the bit definitions for WINxMAP and WPALCON register
video: s3c-fb: move the bit definitions for DITHMODE register
video: s3c-fb: add the bit definitions for VIDCON0_VIDOUT_WB
video: s3c-fb: fix typo in comment
video: s3c-fb: fix help message for FB_S3C_DEBUG_REGWRITE
video: s3c-fb: use FIMD_V8_VIDTCON0 for EXYNOS5 FIMD
video: s3c-fb: use dev_get_drvdata() instead of platform_get_drvdata()
video: s3c-fb: add "drop through" comment
video: s3c-fb: return an error when bpp is invalid
video: s3c-fb: fix red offset and length for ARGB232 format
Laurent Pinchart (19):
fbdev: sh_mobile_lcdc: Get display dimensions from the channel structure
fbdev: sh_mobile_lcdc: Rename mode argument to modes
fbdev: sh_mobile_lcdc: Remove priv argument from channel and overlay init
ARM: mach-shmobile: ag5evm: Add LCDC tx_dev field to platform data
fbdev: sh_mipi_dsi: Add channel field to platform data
ARM: mach-shmobile: Initiliaze the new sh_mipi_dsi_info channel field
fbdev: sh_mipi_dsi: Use the sh_mipi_dsi_info channel field
fbdev: sh_mipi_dsi: Use the LCDC entity default mode
fbdev: sh_mipi_dsi: Remove last reference to LCDC platform data
ARM: mach-shmobile: Remove the unused sh_mipi_dsi_info lcd_chan field
fbdev: sh_mipi_dsi: Remove the unused sh_mipi_dsi_info lcd_chan field
fbdev: sh_mobile_lcdc: Store the backlight brightness internally
ARM: mach-shmobile: mackerel: Removed unused get_brightness callback
sh: ap325rxa: Remove unused get_brightness LCDC callback
sh: ecovec24: Remove unused get_brightness LCDC callback
fbdev: sh_mobile_lcdc: Remove unused get_brightness pdata callback
ARM: mach-shmobile: ag5evm: Use the backlight API for brightness control
sh: kfr2r09: Use the backlight API for brightness control
fbdev: sh_mobile_lcdc: Make sh_mobile_lcdc_sys_bus_ops static
Manjunathappa (1):
video: da8xx-fb: clk_get on connection id fck
Manjunathappa, Prakash (2):
da8xx-fb: adopt fb_videomode data for panel information
da8xx-fb: cleanup LCDC configurations
Matthias Brugger (1):
OMAPFB: Delete if statement evaluating a constant.
Maxime Ripard (1):
drivers/video: add support for the Solomon SSD1307 OLED Controller
Pantelis Antoniou (1):
da8xx: Fix revision check on the da8xx driver
Peter Ujfalusi (1):
OMAPDSS: Correct check for the callback pointer in dss_dsi_disable_pads()
Ricardo Neri (8):
OMAPDSS: HDMI: Rename resource variable at probe.
OMAPDSS: HDMI: Convert to devm_request_and_ioremap
OMAPDSS: HDMI: Make panel return dssdev register errors
OMAPDSS: HDMI: Handle panel init error at probe
OMAPDSS: HDMI: Uninit display on device add error
OMAPDSS: HDMI: Add op to get audio DMA port address offset
OMAPDSS: HDMI: Create platform device for audio support
OMAPDSS: HDMI: Remove __exit macro from hdmi_uninit_display
Sachin Kamat (1):
drivers/video/console/softcursor.c: remove redundant NULL check before kfree()
Sean Paul (8):
video: exynos_dp: Check DPCD return codes
video: exynos_dp: Clean up SW link training
video: exynos_dp: Get pll lock before pattern set
video: exynos_dp: Improve EDID error handling
video: exynos_dp: Fix bug when checking dp->irq
video: exynos_dp: Remove sink control to D0
video: exynos_dp: Move hotplug into a workqueue
video: exynos_dp: Enable hotplug interrupts
Timur Tabi (9):
MAINTAINERS: Make Timur Tabi the maintainer for the Freescale DIU driver
drivers/video: fsl-diu-fb: simplify platforms that have only one port
drivers/video: fsl-diu-fb: add support for set_gamma ioctls
drivers/video: fsl-diu-fb: streamline enabling of interrupts
drivers/video: fsl-diu-fb: improve message displays
drivers/video: fsl-diu-fb: remove unused 'cursor_reset' variable
drivers/video: fsl-diu-fb: clean up reset of primary display
drivers/video: fsl-diu-fb: don't touch registers for unused features
drivers/video: fsl-diu-fb: store EDID data in the global object
Tomi Valkeinen (113):
Merge tag 'v3.7-rc1'
OMAPDSS: add missing sizes.h includes
OMAPDSS: fix compilation warnings
OMAPDSS: remove Kconfig dependencies
Merge branch '3.8/dss-version'
Merge branch '3.8/vrfb-conversion'
OMAPDSS: DSI: fix dsi_get_dsidev_from_id()
OMAPDSS: fix registering the vsync isr in apply
OMAPDSS: DISPC: constify function parameters
OMAPDSS: combine LCD related config into one func
OMAPDSS: remove declarations for non-existing funcs
OMAPDSS: DISPC: remove struct omap_overlay use
OMAPDSS: DISPC: cleanup lcd and digit enable
OMAPDSS: DISPC: add dispc_mgr_get_sync_lost_irq()
OMAPDSS: DISPC: cleanup lcd/digit enable/disable
OMAPDSS: remove omap_dss_device's suspend/resume
OMAPDSS: get the dss version from core pdev
OMAPDSS: remove dispc_irq_handler declaration
OMAPDSS: DISPC: fix dispc_mgr_lclk_rate for DIGIT output
OMAPDSS: export dss_get_def_display_name()
OMAPDSS: remove initial display code from omapdss
OMAPDSS: DISPC: use dss_feat_get_num_ovls()
OMAPDSS: DISPC: rename dispc_mgr_enable/disable to _sync
OMAPDSS: DISPC: make _enable_mgr_out public as "dispc_mgr_enable"
OMAPDSS: add dispc_ovl_enabled()
OMAPDSS: DISPC: Add IRQ enable/status helpers
OMAPDSS: HDMI: split power_on/off to two parts
OMAPDSS: HDMI: use core power on/off with edid & detect
OMAPDSS: HDMI: add 1920x1200 video mode
OMAPDSS: HDMI: make hdmi pclk check more permissive
OMAPFB: remove use of extended edid block
OMAPFB: improve mode selection from EDID
OMAPDSS: fix DSI2 PLL clk names
OMAPDSS: DISPC: fix loop in error handler
OMAPDSS: DISPC: remove dssdev depependency from error handler
OMAPDSS: split hdmi muxing function
Merge branch '3.8/misc-2'
OMAPDSS: fix DPI & DSI init order
OMAPDSS: DSI: skip odd dividers when pck >= 100MHz
OMAPDSS: DSI: workaround for HSDiv problem
OMAPDSS: add dss_calc_clock_rates() back
OMAPDSS: setup default dss fck
OMAPDSS: hide dss_select_dispc_clk_source()
OMAPDSS: DPI: use dpi.dsidev to see whether to use dsi pll
OMAPDSS: DPI: verify if DSI PLL is operational
OMAPDSS: DPI: always use DSI PLL if available
Merge branch '3.8/dsi-pll-work'
OMAPDSS: DISPC: fix DS variable name
OMAPDSS: DISPC: fix sparse warning
OMAPDSS: HACK: look for regulators with omap4 names
OMAP: FB: use DMA_BIT_MASK() for fb's coherent_dma_mask
OMAPFB: use dma_alloc_attrs to allocate memory
OMAP: RX51: remove use of vram
OMAP: common.c: remove init call to vram
OMAP: remove vram allocator
Revert "OMAPDSS: HDMI: Create platform device for audio support"
Merge tag 'v3.7-rc4'
Merge branch '3.8/vram-conversion' of git://gitorious.org/linux-omap-dss2/linux
OMAPFB: fix compilation error
Merge tag 'omapdss-for-3.7-rc' of git://gitorious.org/linux-omap-dss2/linux
Merge branch 'lcdc-next' of git://linuxtv.org/pinchartl/fbdev into for-linus
Merge branch 'fbdev-next' of github.com:timur-tabi/linux-2.6 into for-linus
OMAPDSS: remove declarations for non-existing functions
OMAPDSS: DPI: fix crash with dpi_verify_dsi_pll()
OMAPDSS: don't WARN if there's no DSI device
OMAPDSS: DISPC: add no_framedone_tv feat
OMAPDSS: DISPC: use get_framedone_irq in disable_digit_out
OMAPDSS: DISPC: Remove blocking code from dispc_wb_enable()
OMAPDSS: cleanup WB enable/is_enabled functions
OMAPDSS: DISPC: use WARN_ON() in dispc_mgr_go
OMAPDSS: DISPC: pclk & lclk rates for writeback
OMAPDSS: DISPC: pass pclk to calc_core_clk()
OMAPDSS: DISPC: pass pclk & lclk to check_horiz_timing_omap3
OMAPDSS: DISPC: pass pclk & lclk to calc_scaling
OMAPDSS: DISPC: pass pclk & lclk to dispc_ovl_calc_scaling
OMAPDSS: create display-sysfs.c
OMAPDSS: add dss_get_core_pdev()
Merge branch 'samsung-fb-next' of git://github.com/jingoo/linux into for-linus
Merge branch 'exynos-dp-next' of git://github.com/jingoo/linux into for-linus
[media] omap_vout: use omapdss's version instead of cpu_is_*
[media] omap_vout: remove extra include
OMAPFB: remove exported udpate window
OMAPFB: move dssdev->sync call out from omapfb_realloc_fbmem
OMAPFB: simplify locking
OMAPFB: remove warning when trying to alloc at certain paddress
OMAPDSS: manage output-dssdev connection in output drivers
OMAPFB: connect ovl managers to all dssdevs
OMAPDSS: add omapdss_compat_init()
OMAPDSS: move ovl & ovl-mgr init to apply.c
OMAPDSS: move ovl-mgr function setup to apply.c
OMAPDSS: move ovl function setup to apply.c
OMAPDSS: add manager ops
OMAPDSS: manage framedone irq with mgr ops
OMAPDSS: move blocking mgr enable/disable to compat layer
OMAPDSS: move omap_dispc_wait_for_irq_interruptible_timeout to dispc-compat.c
OMAPDSS: move irq handling to dispc-compat
OMAPDSS: DISPC: add dispc_ovl_check()
OMAPDSS: DPI: use dispc's check_timings
OMAPDSS: move display sysfs init to compat layer
OMAPDSS: separate compat files in the Makefile
OMAPDSS: export dss_mgr_ops functions
OMAPDSS: export dss_feat functions
OMAPDSS: export dispc functions
OMAPDSS: use omapdss_compat_init() in other drivers
Merge omapdss compat layer work
OMAPDSS: DISPC: get dss clock rate from dss driver
OMAPDSS: DISPC: remove dispc fck uses
OMAPFB: use devm_kzalloc to allocate omapfb2_device
OMAPFB: fix error handling in omapfb_find_best_mode()
OMAPFB: remove silly loop in fb2display()
Revert "OMAPFB: simplify locking"
OMAPDSS: fix TV-out issue with DSI PLL
Merge tag 'omapdss-for-3.8' of git://gitorious.org/linux-omap-dss2/linux into for-linus
Wei Yongjun (1):
OMAPDSS: HDMI: fix missing unlock on error in hdmi_dump_regs()
Documentation/arm/OMAP/DSS | 10 +-
.../devicetree/bindings/video/exynos_dp.txt | 80 ++
.../devicetree/bindings/video/ssd1307fb.txt | 24 +
MAINTAINERS | 6 +
arch/arm/mach-davinci/da830.c | 2 +-
arch/arm/mach-davinci/da850.c | 2 +-
arch/arm/mach-davinci/devices-da8xx.c | 22 +-
arch/arm/mach-davinci/pm_domain.c | 1 +
arch/arm/mach-omap2/board-rx51-video.c | 14 -
arch/arm/mach-omap2/board-rx51.c | 3 -
arch/arm/mach-omap2/display.c | 53 +-
arch/arm/mach-omap2/sdrc.c | 16 -
arch/arm/mach-shmobile/board-ag5evm.c | 198 ++--
arch/arm/mach-shmobile/board-ap4evb.c | 4 +-
arch/arm/mach-shmobile/board-mackerel.c | 6 -
arch/arm/plat-omap/common.c | 2 -
arch/arm/plat-omap/fb.c | 66 +-
arch/arm/plat-omap/include/plat/sdrc.h | 7 -
arch/arm/plat-omap/include/plat/vram.h | 43 -
arch/sh/boards/mach-ap325rxa/setup.c | 6 -
arch/sh/boards/mach-ecovec24/setup.c | 6 -
arch/sh/boards/mach-kfr2r09/lcd_wqvga.c | 16 +-
arch/sh/boards/mach-kfr2r09/setup.c | 7 +-
arch/sh/include/mach-kfr2r09/mach/kfr2r09.h | 6 +-
drivers/media/platform/omap/omap_vout.c | 23 +-
drivers/media/platform/omap/omap_vout_vrfb.c | 2 +-
drivers/media/platform/omap/omap_voutdef.h | 2 +-
drivers/media/platform/omap/omap_voutlib.c | 38 +-
drivers/media/platform/omap/omap_voutlib.h | 3 +
drivers/staging/omapdrm/omap_drv.c | 11 +
drivers/video/Kconfig | 17 +-
drivers/video/Makefile | 1 +
drivers/video/console/softcursor.c | 3 +-
drivers/video/da8xx-fb.c | 170 ++-
drivers/video/exynos/exynos_dp_core.c | 697 ++++++++-----
drivers/video/exynos/exynos_dp_core.h | 21 +-
drivers/video/exynos/exynos_dp_reg.c | 77 +-
drivers/video/exynos/exynos_dp_reg.h | 3 +-
drivers/video/fsl-diu-fb.c | 201 ++--
drivers/video/omap2/Kconfig | 3 -
drivers/video/omap2/Makefile | 1 -
drivers/video/omap2/displays/panel-acx565akm.c | 23 -
drivers/video/omap2/displays/panel-generic-dpi.c | 36 -
.../omap2/displays/panel-lgphilips-lb035q02.c | 34 -
drivers/video/omap2/displays/panel-n8x0.c | 89 +-
.../omap2/displays/panel-nec-nl8048hl11-01b.c | 24 -
drivers/video/omap2/displays/panel-picodlp.c | 45 +-
.../video/omap2/displays/panel-sharp-ls037v7dw01.c | 17 -
drivers/video/omap2/displays/panel-taal.c | 72 --
drivers/video/omap2/displays/panel-tfp410.c | 33 -
.../video/omap2/displays/panel-tpo-td043mtea1.c | 20 -
drivers/video/omap2/dss/Kconfig | 35 +-
drivers/video/omap2/dss/Makefile | 7 +-
drivers/video/omap2/dss/apply.c | 331 ++++--
drivers/video/omap2/dss/core.c | 72 +-
drivers/video/omap2/dss/dispc-compat.c | 667 ++++++++++++
drivers/video/omap2/dss/dispc-compat.h | 30 +
drivers/video/omap2/dss/dispc.c | 1102 ++++++--------------
drivers/video/omap2/dss/display-sysfs.c | 321 ++++++
drivers/video/omap2/dss/display.c | 386 +------
drivers/video/omap2/dss/dpi.c | 126 ++-
drivers/video/omap2/dss/dsi.c | 247 +++--
drivers/video/omap2/dss/dss.c | 138 ++-
drivers/video/omap2/dss/dss.h | 124 +--
drivers/video/omap2/dss/dss_features.c | 79 +-
drivers/video/omap2/dss/dss_features.h | 12 +-
drivers/video/omap2/dss/hdmi.c | 158 ++-
drivers/video/omap2/dss/hdmi_panel.c | 82 +-
drivers/video/omap2/dss/manager.c | 39 -
drivers/video/omap2/dss/output.c | 90 +-
drivers/video/omap2/dss/overlay.c | 17 -
drivers/video/omap2/dss/rfbi.c | 23 +-
drivers/video/omap2/dss/sdi.c | 11 +-
drivers/video/omap2/dss/ti_hdmi.h | 3 +
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 11 +-
drivers/video/omap2/dss/venc.c | 11 +-
drivers/video/omap2/dss/venc_panel.c | 19 -
drivers/video/omap2/omapfb/Kconfig | 1 -
drivers/video/omap2/omapfb/omapfb-ioctl.c | 48 +-
drivers/video/omap2/omapfb/omapfb-main.c | 212 ++--
drivers/video/omap2/omapfb/omapfb-sysfs.c | 6 +-
drivers/video/omap2/omapfb/omapfb.h | 20 +-
drivers/video/omap2/vram.c | 514 ---------
drivers/video/omap2/vrfb.c | 142 ++-
drivers/video/s3c-fb.c | 24 +-
drivers/video/sh_mipi_dsi.c | 69 +-
drivers/video/sh_mobile_lcdcfb.c | 74 +-
drivers/video/sh_mobile_lcdcfb.h | 1 +
drivers/video/ssd1307fb.c | 396 +++++++
include/linux/fsl-diu-fb.h | 9 +
include/video/da8xx-fb.h | 25 +-
include/video/omapdss.h | 105 +-
.../plat/vrfb.h => include/video/omapvrfb.h | 2 +
include/video/samsung_fimd.h | 168 +--
include/video/sh_mipi_dsi.h | 4 +-
include/video/sh_mobile_lcdc.h | 1 -
96 files changed, 4355 insertions(+), 3873 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/exynos_dp.txt
create mode 100644 Documentation/devicetree/bindings/video/ssd1307fb.txt
delete mode 100644 arch/arm/plat-omap/include/plat/vram.h
create mode 100644 drivers/video/omap2/dss/dispc-compat.c
create mode 100644 drivers/video/omap2/dss/dispc-compat.h
create mode 100644 drivers/video/omap2/dss/display-sysfs.c
delete mode 100644 drivers/video/omap2/vram.c
create mode 100644 drivers/video/ssd1307fb.c
rename arch/arm/plat-omap/include/plat/vrfb.h => include/video/omapvrfb.h (95%)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* [RFC 0/6] Common Display Framework-T
From: Tomi Valkeinen @ 2012-12-14 14:27 UTC (permalink / raw)
To: Laurent Pinchart, linux-fbdev, dri-devel; +Cc: Tomi Valkeinen
Hi,
I have been testing Common Display Framework on OMAP, and making changes that
I've discussed in the posts I've sent in reply to the CDF series from Laurent.
While my CDF code is rather hacky and not at all ready, I wanted to post the
code for comments and also as a reference code to my posts.
So here is CDF-T (Tomi-edition =).
Changes compared to Laurent's CDF
---------------------------------
- DBI bus is removed. I don't have any DBI devices, and as I said in my posts,
I didn't see need for a real bus for DBI (or DSI). I thus also removed the
DBI panels.
- Split the display_entity into two parts: video_source, which is used to
connect the display chips and panels, and display_entity, which represent
either the panel or the whole pipeline (I'm not sure which is better).
- Added ops for DVI and DSI
- Added driver for TFP410, a DPI to DVI converter chip
- Added driver for generic DVI monitor
- Added driver for Taal, a DSI command mode panel
- Removed DISPLAY_ENTITY_STREAM_SINGLE_SHOT, and instead there's update() op.
It's perhaps possible to use the single-shot method, but I went for a
separate op to get a "update done"-callback implemented easily.
Notes about the code
--------------------
As I said, the code is rather untidy, but I think it's more or less
understandable. I've skipped adding any helper funcs, for example to call the
ops, so it's easier for me to change the API.
I also (ab)used some of the omapdss panel headers to ease my hacking for
omapdss+cdf. These should be quite clear.
The code, including hacks to omapdss to make it use CDF, can be found from:
git://gitorious.org/linux-omap-dss2/linux.git work/dss-dev-model-cdf
The DSI part is very unfinished. I am able to use it to start up the Taal
panel, and send frames to the panel, but it's really missing lots of stuff.
About display_entity & video_source
-----------------------------------
I've discussed this split in previous posts, but I'll describe it here again.
As I see it, the connections between the display blocks, and the use of the
panel (and thus the whole pipeline) are very different things, and I think they
should be separated. So in my version I have struct video_source, used to
connect the blocks, and display_entity, representing the panel or the whole
pipeline. display_entity is probably not a good name for it anymore, but I
didn't come up with a good one yet.
As an example, let's look at chip-tfp410.c and panel-dvi.c.
tfp410 uses two video_sources, one for input and one for output. The input
comes from some other display block, in my case from OMAP display subsystem.
OMAP DSS has registered a DPI video_source, and the tfp410 driver will get this
source using video_source_find().
tfp410 registers its output as a video source, using video_source_register.
panel-dvi will in turn use video_source_find() to get it.
Both drivers use video_source to configure the input bus, i.e. tfp410
configures the DPI bus between OMAP DSS and TFP410 using, for example,
set_data_lines op to configure the number of datalines on the DPI bus.
With the video_sources in place, the whole video pipeline can be used. However,
we still need to expose an API so that somebody can actually use the pipeline.
This is done with display_entity. display_entity contains higher level ops,
which are not bus specific. The display_entity is registered by the panel at
the end of the chain.
In my model the display_entity ops go to the panel driver, which then calls ops
in the input video source to do the work. Laurent has objected to this model,
and would rather have the display_entity ops go to the DSS side (if I
understood right), which would then propagate forward towards the panel. I have
still kept my model, as I don't see the downsides with my model, nor do I see
any use for propagating the ops from DSS to the panel. But I'm happy to hear
examples how it is beneficial and could be used.
About the bus model
-------------------
Lauren't version uses a linux bus for DBI. The idea here is that DBI is the
control bus fro the panel/chip, and should thus be represented by a real bus.
While I agreed to this approach when we discussed about it, I now am slightly
against it.
My reason is that DBI (or DSI or any other similar bus) is not really control
bus, it is a video bus. It _can_ be used for control, but video is the main
purpose. This has the partical issues:
- There's never use for DBI only for control. DBI is always used for either
video only, or control+video.
- If DBI is used only for video, there's no DBI bus. How to configure DBI in
this case?
- If DBI is used for control and video, we have two separate APIs for the bus.
In theory it's possible to handle this, but in practice it may be impossible,
especially for more complex busses like DSI.
So in my version I added DSI as a plain video_source, without a real linux bus.
I think this model is a lot simpler, and works better.
Tomi
Tomi Valkeinen (6):
video: add display-core
video: add generic dpi panel
video: add tfp410
video: add generic dvi monitor
video: add taal panel
video: add makefile & kconfig
drivers/video/Kconfig | 1 +
drivers/video/Makefile | 1 +
drivers/video/display/Kconfig | 26 +++
drivers/video/display/Makefile | 5 +
drivers/video/display/chip-tfp410.c | 164 +++++++++++++++
drivers/video/display/display-core.c | 207 ++++++++++++++++++
drivers/video/display/panel-dpi.c | 155 ++++++++++++++
drivers/video/display/panel-dvi.c | 164 +++++++++++++++
drivers/video/display/panel-taal.c | 383 ++++++++++++++++++++++++++++++++++
include/video/display.h | 166 +++++++++++++++
include/video/omap-panel-nokia-dsi.h | 4 +-
include/video/omap-panel-tfp410.h | 4 +
include/video/panel-dpi.h | 25 +++
include/video/panel-dvi.h | 18 ++
14 files changed, 1321 insertions(+), 2 deletions(-)
create mode 100644 drivers/video/display/Kconfig
create mode 100644 drivers/video/display/Makefile
create mode 100644 drivers/video/display/chip-tfp410.c
create mode 100644 drivers/video/display/display-core.c
create mode 100644 drivers/video/display/panel-dpi.c
create mode 100644 drivers/video/display/panel-dvi.c
create mode 100644 drivers/video/display/panel-taal.c
create mode 100644 include/video/display.h
create mode 100644 include/video/panel-dpi.h
create mode 100644 include/video/panel-dvi.h
--
1.7.10.4
^ permalink raw reply
* [RFC 1/6] video: add display-core
From: Tomi Valkeinen @ 2012-12-14 14:27 UTC (permalink / raw)
To: Laurent Pinchart, linux-fbdev, dri-devel; +Cc: Tomi Valkeinen
In-Reply-To: <1355495252-26364-1-git-send-email-tomi.valkeinen@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/display/display-core.c | 207 ++++++++++++++++++++++++++++++++++
include/video/display.h | 166 +++++++++++++++++++++++++++
2 files changed, 373 insertions(+)
create mode 100644 drivers/video/display/display-core.c
create mode 100644 include/video/display.h
diff --git a/drivers/video/display/display-core.c b/drivers/video/display/display-core.c
new file mode 100644
index 0000000..5f8be30
--- /dev/null
+++ b/drivers/video/display/display-core.c
@@ -0,0 +1,207 @@
+/*
+ * Display Core
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/export.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/videomode.h>
+
+#include <video/display.h>
+
+/* -----------------------------------------------------------------------------
+ * Display Entity
+ */
+
+static LIST_HEAD(display_entity_list);
+static DEFINE_MUTEX(display_entity_mutex);
+
+struct display_entity *display_entity_get_first(void)
+{
+ if (list_empty(&display_entity_list))
+ return NULL;
+
+ return list_first_entry(&display_entity_list, struct display_entity,
+ list);
+}
+EXPORT_SYMBOL(display_entity_get_first);
+
+int display_entity_set_state(struct display_entity *entity,
+ enum display_entity_state state)
+{
+ int ret;
+
+ if (entity->state = state)
+ return 0;
+
+ if (!entity->ops || !entity->ops->set_state)
+ return 0;
+
+ ret = entity->ops->set_state(entity, state);
+ if (ret < 0)
+ return ret;
+
+ entity->state = state;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(display_entity_set_state);
+
+int display_entity_get_modes(struct display_entity *entity,
+ const struct videomode **modes)
+{
+ if (!entity->ops || !entity->ops->get_modes)
+ return 0;
+
+ return entity->ops->get_modes(entity, modes);
+}
+EXPORT_SYMBOL_GPL(display_entity_get_modes);
+
+int display_entity_get_size(struct display_entity *entity,
+ unsigned int *width, unsigned int *height)
+{
+ if (!entity->ops || !entity->ops->get_size)
+ return -EOPNOTSUPP;
+
+ return entity->ops->get_size(entity, width, height);
+}
+EXPORT_SYMBOL_GPL(display_entity_get_size);
+
+static void display_entity_release(struct kref *ref)
+{
+ struct display_entity *entity + container_of(ref, struct display_entity, ref);
+
+ if (entity->release)
+ entity->release(entity);
+}
+
+struct display_entity *display_entity_get(struct display_entity *entity)
+{
+ if (entity = NULL)
+ return NULL;
+
+ kref_get(&entity->ref);
+ return entity;
+}
+EXPORT_SYMBOL_GPL(display_entity_get);
+
+void display_entity_put(struct display_entity *entity)
+{
+ kref_put(&entity->ref, display_entity_release);
+}
+EXPORT_SYMBOL_GPL(display_entity_put);
+
+int __must_check __display_entity_register(struct display_entity *entity,
+ struct module *owner)
+{
+ kref_init(&entity->ref);
+ entity->owner = owner;
+ entity->state = DISPLAY_ENTITY_STATE_OFF;
+
+ mutex_lock(&display_entity_mutex);
+ list_add(&entity->list, &display_entity_list);
+
+ mutex_unlock(&display_entity_mutex);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(__display_entity_register);
+
+void display_entity_unregister(struct display_entity *entity)
+{
+ mutex_lock(&display_entity_mutex);
+
+ list_del(&entity->list);
+ mutex_unlock(&display_entity_mutex);
+
+ display_entity_put(entity);
+}
+EXPORT_SYMBOL_GPL(display_entity_unregister);
+
+/* -----------------------------------------------------------------------------
+ * Video Source
+ */
+
+static LIST_HEAD(video_source_list);
+static DEFINE_MUTEX(video_source_mutex);
+
+int __must_check __video_source_register(struct video_source *src,
+ struct module *owner)
+{
+ kref_init(&src->ref);
+ src->owner = owner;
+
+ mutex_lock(&video_source_mutex);
+ list_add(&src->list, &video_source_list);
+
+ mutex_unlock(&video_source_mutex);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(__video_source_register);
+
+void video_source_unregister(struct video_source *src)
+{
+ mutex_lock(&video_source_mutex);
+
+ list_del(&src->list);
+ mutex_unlock(&video_source_mutex);
+
+ video_source_put(src);
+}
+EXPORT_SYMBOL_GPL(video_source_unregister);
+
+
+static void video_source_release(struct kref *ref)
+{
+ struct video_source *src + container_of(ref, struct video_source, ref);
+
+ if (src->release)
+ src->release(src);
+}
+
+struct video_source *video_source_get(struct video_source *src)
+{
+ if (src = NULL)
+ return NULL;
+
+ kref_get(&src->ref);
+ return src;
+}
+EXPORT_SYMBOL_GPL(video_source_get);
+
+void video_source_put(struct video_source *src)
+{
+ kref_put(&src->ref, video_source_release);
+}
+EXPORT_SYMBOL_GPL(video_source_put);
+
+struct video_source *video_source_find(const char *name)
+{
+ struct video_source *src;
+
+ list_for_each_entry(src, &video_source_list, list) {
+ if (strcmp(src->name, name) = 0) {
+ kref_get(&src->ref);
+ return src;
+ }
+ }
+
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(video_source_find);
+
+MODULE_AUTHOR("Laurent Pinchart <laurent.pinchart@ideasonboard.com>");
+MODULE_DESCRIPTION("Display Core");
+MODULE_LICENSE("GPL");
diff --git a/include/video/display.h b/include/video/display.h
new file mode 100644
index 0000000..b639fd0
--- /dev/null
+++ b/include/video/display.h
@@ -0,0 +1,166 @@
+/*
+ * Display Core
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __DISPLAY_H__
+#define __DISPLAY_H__
+
+#include <linux/kref.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <video/omapdss.h>
+
+struct display_entity;
+struct video_source;
+struct videomode;
+
+/* -----------------------------------------------------------------------------
+ * Display Entity
+ */
+
+/* Hack to get the first registered display entity */
+struct display_entity *display_entity_get_first(void);
+
+enum display_entity_state {
+ DISPLAY_ENTITY_STATE_OFF,
+ DISPLAY_ENTITY_STATE_STANDBY,
+ DISPLAY_ENTITY_STATE_ON,
+};
+
+struct display_entity_control_ops {
+ int (*set_state)(struct display_entity *ent,
+ enum display_entity_state state);
+ int (*update)(struct display_entity *ent,
+ void (*callback)(int, void *), void *data);
+ int (*get_modes)(struct display_entity *ent,
+ const struct videomode **modes);
+ int (*get_size)(struct display_entity *ent,
+ unsigned int *width, unsigned int *height);
+};
+
+struct display_entity {
+ struct list_head list;
+ struct device *dev;
+ struct module *owner;
+ struct kref ref;
+
+ const struct display_entity_control_ops *ops;
+
+ void(*release)(struct display_entity *ent);
+
+ enum display_entity_state state;
+};
+
+int display_entity_set_state(struct display_entity *entity,
+ enum display_entity_state state);
+int display_entity_get_modes(struct display_entity *entity,
+ const struct videomode **modes);
+int display_entity_get_size(struct display_entity *entity,
+ unsigned int *width, unsigned int *height);
+
+struct display_entity *display_entity_get(struct display_entity *entity);
+void display_entity_put(struct display_entity *entity);
+
+int __must_check __display_entity_register(struct display_entity *entity,
+ struct module *owner);
+void display_entity_unregister(struct display_entity *entity);
+
+#define display_entity_register(display_entity) \
+ __display_entity_register(display_entity, THIS_MODULE)
+
+
+/* -----------------------------------------------------------------------------
+ * Video Source
+ */
+
+enum video_source_stream_state {
+ DISPLAY_ENTITY_STREAM_STOPPED,
+ DISPLAY_ENTITY_STREAM_CONTINUOUS,
+};
+
+struct common_video_source_ops {
+ int (*set_stream)(struct video_source *src,
+ enum video_source_stream_state state);
+};
+
+struct dpi_video_source_ops {
+ int (*set_videomode)(struct video_source *src,
+ const struct videomode *vm);
+ int (*set_data_lines)(struct video_source *src, int lines);
+};
+
+struct dsi_video_source_ops {
+ /* enable/disable dsi bus */
+ int (*enable)(struct video_source *src);
+ void (*disable)(struct video_source *src);
+
+ /* bus configuration */
+ int (*configure_pins)(struct video_source *src,
+ const struct omap_dsi_pin_config *pins);
+ int (*set_clocks)(struct video_source *src,
+ unsigned long ddr_clk,
+ unsigned long lp_clk);
+
+ void (*set_operation_mode)(struct video_source *src,
+ enum omap_dss_dsi_mode mode);
+ void (*set_pixel_format)(struct video_source *src,
+ enum omap_dss_dsi_pixel_format fmt);
+ void (*set_size)(struct video_source *src, u16 w, u16 h);
+
+ void (*enable_hs)(struct video_source *src, bool enable);
+
+ /* data transfer */
+ int (*dcs_write)(struct video_source *src, int channel,
+ u8 *data, size_t len);
+ int (*dcs_read)(struct video_source *src, int channel, u8 dcs_cmd,
+ u8 *data, size_t len);
+ int (*update)(struct video_source *src, int channel,
+ void (*callback)(int, void *), void *data);
+};
+
+struct dvi_video_source_ops {
+ int (*set_videomode)(struct video_source *src,
+ const struct videomode *vm);
+};
+
+struct video_source {
+ struct list_head list;
+ struct device *dev;
+ struct module *owner;
+ struct kref ref;
+
+ const char *name;
+
+ const struct common_video_source_ops *common_ops;
+
+ union {
+ const struct dpi_video_source_ops *dpi;
+ const struct dsi_video_source_ops *dsi;
+ const struct dvi_video_source_ops *dvi;
+ } ops;
+
+ void(*release)(struct video_source *src);
+};
+
+
+#define video_source_register(video_source) \
+ __video_source_register(video_source, THIS_MODULE)
+
+int __must_check __video_source_register(struct video_source *entity,
+ struct module *owner);
+void video_source_unregister(struct video_source *entity);
+
+struct video_source *video_source_get(struct video_source *src);
+void video_source_put(struct video_source *src);
+
+struct video_source *video_source_find(const char *name);
+
+#endif /* __DISPLAY_H__ */
--
1.7.10.4
^ 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