* Re: [PATCH] drivers: video: i740fb: add 'default' processing contents for 'switch'.
From: Tomi Valkeinen @ 2013-08-30 10:52 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <51ECF12D.8060903@asianux.com>
[-- Attachment #1: Type: text/plain, Size: 956 bytes --]
On 30/08/13 13:41, Chen Gang wrote:
> On 08/30/2013 06:19 PM, Tomi Valkeinen wrote:
>> Here's some old discussion about BUG:
>>
>> http://yarchive.net/comp/linux/BUG.html
>>
>
> Yeah, if it is not a real bug (can handle it), we should not use BUG(),
> but when we are sure it is a kernel bug, and the kernel will continue
> blindly, we need use BUG() to stop it.
>
> Just like the Linus Torvalds said in the link which you provide:
>
> "Rule of thumb: BUG() is only good for something that never happens and
> that we really have no other option for (ie state is so corrupt that
> continuing is deadly)".
I guess this is where we disagree. I don't see having a corrupt bpp
value in a fb driver's internal function as "so corrupt that continuing
is deadly".
Anyway, if you insist on the BUG(), I'll leave this patch to
Jean-Christophe. I'm only taking small-ish patches that have no open
issues or disagreements.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] video: da8xx-fb: numerous bugfixes
From: Tomi Valkeinen @ 2013-08-30 11:52 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1377294773-25678-1-git-send-email-detheridge@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1620 bytes --]
Hi,
On 24/08/13 00:52, Darren Etheridge wrote:
> In developing a driver for an HDMI encoder to be attached to the LCD controller
> on TI AM335x SoC I ran across a number of bugs in the da8xx-fb.c fbdev driver.
> Two of them appear to have been in the driver for a while (02 and 04), one of
> them is a deficiency where some LCD controller version 2 features have not been
> utilized (03) and the last one was introduced in the last patch series that I
> submitted for this driver (01).
>
> These patches do not change the behavior of the AM335x EVM's platforms LCD
> panel even though the current values set by the driver are wrong. I guess LCD
> panels (at least the one used on AM335x EVM) must be fairly immune to bad
> timings coming from the LCD controller. However the HDMI encoder simply will
> not work without these fixes, and quite possibly other LCD panels could behave
> the same way.
>
> These patches apply on top of the patch series called:
> "video/da8xx-fb fbdev driver enhance to support TI am335x SoC"
> that was submitted by me.
>
> Darren Etheridge (4):
> video: da8xx-fb fixing incorrect porch mappings
> video: da8xx-fb: fixing timing off by one errors
> video: da8xx-fb: support lcdc v2 timing register expansion
> video: da8xx-fb: fix the polarities of the hsync/vsync pulse
>
> drivers/video/da8xx-fb.c | 35 +++++++++++++++++++++++++----------
> 1 files changed, 25 insertions(+), 10 deletions(-)
>
These look good to me, queuing for 3.12.
There was a space missing between 'if' and '(' in one of the patches, I
fixed that.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: Bochs VBE & Virtualbox framebuffer driver
From: Tomi Valkeinen @ 2013-08-30 11:58 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <5211D634.3010204@castus.tv>
[-- Attachment #1: Type: text/plain, Size: 638 bytes --]
Hi,
On 19/08/13 11:24, Jonathan Campbell wrote:
> This is an experimental framebuffer driver for VirtualBox and Bochs VBE
> displays. It started off as a proof of concept and grew into the code it
> is now. When testing Linux in Bochs or VirtualBox this allows greater
> control over the display and bit depth, though no h/w acceleration.
>
> What do you think? Would this be something that could make it into the
> mainline kernel?
I don't see why not, although I know nothing about VirtualBox nor Bochs.
But with a very quick glance, it at least needs to be changed to match
the kernel coding conventions.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* RE: [PATCH 0/4] video: da8xx-fb: numerous bugfixes
From: Etheridge, Darren @ 2013-08-30 15:25 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1377294773-25678-1-git-send-email-detheridge@ti.com>
> From: Valkeinen, Tomi
> Sent: Friday, August 30, 2013 6:53 AM
> >
> > Darren Etheridge (4):
> > video: da8xx-fb fixing incorrect porch mappings
> > video: da8xx-fb: fixing timing off by one errors
> > video: da8xx-fb: support lcdc v2 timing register expansion
> > video: da8xx-fb: fix the polarities of the hsync/vsync pulse
> >
> > drivers/video/da8xx-fb.c | 35 +++++++++++++++++++++++++----------
> > 1 files changed, 25 insertions(+), 10 deletions(-)
> >
>
> These look good to me, queuing for 3.12.
>
> There was a space missing between 'if' and '(' in one of the patches, I fixed
> that.
>
> Tomi
>
Tomi,
Thank you.
Darren
^ permalink raw reply
* Re: [PATCH] omap2: panel-generic: Added panel parameters for ortus-com37h3m05dtc/99dtc and sharp-lq0
From: Belisko Marek @ 2013-09-01 12:32 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jean-Christophe PLAGNIOL-VILLARD, linux-omap@vger.kernel.org,
linux-fbdev, LKML, H. Nikolaus Schaller
In-Reply-To: <52205056.8080908@ti.com>
Hi Tomi,
On Fri, Aug 30, 2013 at 9:57 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 29/08/13 15:35, Marek Belisko wrote:
>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>> Signed-off-by: Marek Belisko <marek@goldelico.com>
>> ---
>> drivers/video/omap2/displays/panel-generic-dpi.c | 53 ++++++++++++++++++++++++
>> 1 file changed, 53 insertions(+)
>>
>> diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c b/drivers/video/omap2/displays/panel-generic-dpi.c
>> index bebebd4..d573291 100644
>> --- a/drivers/video/omap2/displays/panel-generic-dpi.c
>> +++ b/drivers/video/omap2/displays/panel-generic-dpi.c
>> @@ -107,6 +107,33 @@ static struct panel_config generic_dpi_panels[] = {
>> .name = "sharp_ls",
>> },
>
> The drivers in drivers/video/omap2/displays/ are on their way out, and
> will probably be removed for 3.12. Please look at the new one at
> drivers/video/omap2/displays-new/panel-dpi.c.
I've probably miss series (OMAPDSS: remove old panel model code)
and in time when sent patch it wasn't in linux-next yes. AFAIU generic
panel settings
was moved to board files which is not case for our patch as gta04
(other) board with panel isn't yes mainlined.
>
> Tomi
>
>
Regards,
marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
^ permalink raw reply
* [PATCH] video: xilinxfb: use devm_ioremap_resource() instead of devm_request_and_ioremap()
From: Jingoo Han @ 2013-09-02 1:33 UTC (permalink / raw)
To: linux-fbdev
Use devm_ioremap_resource() because devm_request_and_ioremap() is
obsoleted by devm_ioremap_resource().
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/xilinxfb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index 6629b29..ed90051 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -260,9 +260,9 @@ static int xilinxfb_assign(struct platform_device *pdev,
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
drvdata->regs_phys = res->start;
- drvdata->regs = devm_request_and_ioremap(&pdev->dev, res);
- if (!drvdata->regs) {
- rc = -EADDRNOTAVAIL;
+ drvdata->regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(drvdata->regs)) {
+ rc = PTR_ERR(drvdata->regs);
goto err_region;
}
}
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] drivers: video: i740fb: add 'default' processing contents for 'switch'.
From: Chen Gang @ 2013-09-02 1:41 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <51ECF12D.8060903@asianux.com>
On 08/30/2013 06:52 PM, Tomi Valkeinen wrote:
> On 30/08/13 13:41, Chen Gang wrote:
>> On 08/30/2013 06:19 PM, Tomi Valkeinen wrote:
>
>>> Here's some old discussion about BUG:
>>>
>>> http://yarchive.net/comp/linux/BUG.html
>>>
>>
>> Yeah, if it is not a real bug (can handle it), we should not use BUG(),
>> but when we are sure it is a kernel bug, and the kernel will continue
>> blindly, we need use BUG() to stop it.
>>
>> Just like the Linus Torvalds said in the link which you provide:
>>
>> "Rule of thumb: BUG() is only good for something that never happens and
>> that we really have no other option for (ie state is so corrupt that
>> continuing is deadly)".
>
> I guess this is where we disagree. I don't see having a corrupt bpp
> value in a fb driver's internal function as "so corrupt that continuing
> is deadly".
>
Hmm... at least we are agree with each other
"at least now, it should be never happen", is it correct ?
And we are disagree with each other:
"if it really happens, I think it is a critical bug, but you have different opinion", is it correct ?
> Anyway, if you insist on the BUG(), I'll leave this patch to
> Jean-Christophe. I'm only taking small-ish patches that have no open
> issues or disagreements.
>
OK, thank you for spending your time resources to provide your
suggestion and opinion.
And welcome another members' suggestion and completions.
> Tomi
>
>
Thanks.
--
Chen Gang
^ permalink raw reply
* Re: [PATCH] video: xilinxfb: use devm_ioremap_resource() instead of devm_request_and_ioremap()
From: Michal Simek @ 2013-09-02 6:01 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <005401cea77c$6925eec0$3b71cc40$%han@samsung.com>
On 09/02/2013 03:33 AM, Jingoo Han wrote:
> Use devm_ioremap_resource() because devm_request_and_ioremap() is
> obsoleted by devm_ioremap_resource().
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> ---
> drivers/video/xilinxfb.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
> index 6629b29..ed90051 100644
> --- a/drivers/video/xilinxfb.c
> +++ b/drivers/video/xilinxfb.c
> @@ -260,9 +260,9 @@ static int xilinxfb_assign(struct platform_device *pdev,
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> drvdata->regs_phys = res->start;
> - drvdata->regs = devm_request_and_ioremap(&pdev->dev, res);
> - if (!drvdata->regs) {
> - rc = -EADDRNOTAVAIL;
> + drvdata->regs = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(drvdata->regs)) {
> + rc = PTR_ERR(drvdata->regs);
> goto err_region;
> }
> }
>
Acked-by: Michal Simek <michal.simek@xilinx.com>
Thanks,
Michal
^ permalink raw reply
* Re: [RFC 00/22] OMAPDSS: DT support
From: Tony Lindgren @ 2013-09-02 6:15 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Laurent Pinchart, Nishanth Menon, Felipe Balbi, Santosh Shilimkar
In-Reply-To: <52206A48.8040401@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [130830 02:55]:
> On 13/08/13 10:54, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [130809 01:46]:
> >>
> >> So as is evident, I have things in my mind that should be improved. Maybe
> >> the most important question for short term future is:
> >>
> >> Can we add DSS DT bindings for OMAP4 as unstable bindings? It would give us
> >> some proper testing of the related code, and would also allow us to remove
> >> the related hacks (which don't even work quite right). However, I have no
> >> idea yet when the unstable DSS bindings would turn stable.
> >>
> >> If we shouldn't add the bindings as unstable, when should the bindings be
> >> added? Wait until CDF is in the mainline, and use that?
> >
> > I don't think we should add any temporary bindings as it's going to be
> > a pain to support those in the long run. I suggest you initially just
> > stick to established bindings for the basic hardware IO address and
> > interrupts etc, then those should still be valid with the generic panel
> > bindings later on.
>
> I don't understand what does it matter if the bindings are temporary, or
> basic established bindings. In both cases the DT data needs to be
> changed when the CDF is taken into use.
Yes but the old bindings still need to be supported because people
are doing devices using those. So any kind of temporary binding will be
a pain to support.
> Well, one difference is that the temporary bindings would give us
> working display, but having only basic bindings would not. So I don't
> see any reason to add only the basic bindings. Or how would it work?
You might be able to use just a minimal binding for now using the
basic reg, interrupt and entries for the various components. Those will
be still valid when the CDF bindings are available.
Regards,
Tony
^ permalink raw reply
* Re: [RFC 00/22] OMAPDSS: DT support
From: Tomi Valkeinen @ 2013-09-02 6:42 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Laurent Pinchart, Nishanth Menon, Felipe Balbi, Santosh Shilimkar
In-Reply-To: <20130902061541.GU7656@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 3389 bytes --]
On 02/09/13 09:15, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [130830 02:55]:
>> On 13/08/13 10:54, Tony Lindgren wrote:
>>> * Tomi Valkeinen <tomi.valkeinen@ti.com> [130809 01:46]:
>>>>
>>>> So as is evident, I have things in my mind that should be improved. Maybe
>>>> the most important question for short term future is:
>>>>
>>>> Can we add DSS DT bindings for OMAP4 as unstable bindings? It would give us
>>>> some proper testing of the related code, and would also allow us to remove
>>>> the related hacks (which don't even work quite right). However, I have no
>>>> idea yet when the unstable DSS bindings would turn stable.
>>>>
>>>> If we shouldn't add the bindings as unstable, when should the bindings be
>>>> added? Wait until CDF is in the mainline, and use that?
>>>
>>> I don't think we should add any temporary bindings as it's going to be
>>> a pain to support those in the long run. I suggest you initially just
>>> stick to established bindings for the basic hardware IO address and
>>> interrupts etc, then those should still be valid with the generic panel
>>> bindings later on.
>>
>> I don't understand what does it matter if the bindings are temporary, or
>> basic established bindings. In both cases the DT data needs to be
>> changed when the CDF is taken into use.
>
> Yes but the old bindings still need to be supported because people
> are doing devices using those. So any kind of temporary binding will be
> a pain to support.
If old bindings need to be supported, then we also need to support the
current state for Panda and SDP, i.e. there are no DSS related DT
bindings, but displays still work. Which means we'll have to keep the
current hacky DSS device construction mechanism for Panda and SDP.
Although maybe it's cleaner to somehow inject the DSS DT nodes for Panda
and SDP in case they are missing from the real DT data.
Doesn't supporting old bindings also mean that we can never get rid of
the hwmods? Or will there be code that injects the missing interrupt
etc. entries?
>> Well, one difference is that the temporary bindings would give us
>> working display, but having only basic bindings would not. So I don't
>> see any reason to add only the basic bindings. Or how would it work?
>
> You might be able to use just a minimal binding for now using the
> basic reg, interrupt and entries for the various components. Those will
> be still valid when the CDF bindings are available.
Well, the entries will be valid, but the displays won't work with just
the basic bindings. I could perhaps add a new hack that creates the
required panel devices and video pipeline connections dynamically in
code for Panda and SDP, a bit like what the code does now, except the
basic DSS entries would be in the DT. But that would just add another
set of DT data that I would need to support in the future, and there
would be three different cases to support for Panda and SDP:
- DT data with no DSS related nodes
- DT data with basic DSS related nodes
- DT data with full DSS
So... If old bindings have to be supported, I'd rather try to minimize
the pain, and not add anything but the final bindings. In retrospect, it
was a bit of a mistake to add the hacky DT display support for Panda and
SDP, as it won't be very nice to keep supporting those.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] drivers: video: i740fb: add 'default' processing contents for 'switch'.
From: Tomi Valkeinen @ 2013-09-02 6:45 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <51ECF12D.8060903@asianux.com>
[-- Attachment #1: Type: text/plain, Size: 411 bytes --]
On 02/09/13 04:41, Chen Gang wrote:
> Hmm... at least we are agree with each other
>
> "at least now, it should be never happen", is it correct ?
>
>
> And we are disagree with each other:
>
> "if it really happens, I think it is a critical bug, but you have different opinion", is it correct ?
Yes for both, if "critical" means that the kernel has to be halted
immediately.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] drivers: video: i740fb: add 'default' processing contents for 'switch'.
From: Chen Gang @ 2013-09-02 6:45 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <51ECF12D.8060903@asianux.com>
On 09/02/2013 02:45 PM, Tomi Valkeinen wrote:
> On 02/09/13 04:41, Chen Gang wrote:
>
>> Hmm... at least we are agree with each other
>>
>> "at least now, it should be never happen", is it correct ?
>>
>>
>> And we are disagree with each other:
>>
>> "if it really happens, I think it is a critical bug, but you have different opinion", is it correct ?
>
> Yes for both, if "critical" means that the kernel has to be halted
> immediately.
>
Thank you for your confirmation.
:-)
> Tomi
>
>
--
Chen Gang
^ permalink raw reply
* Re: [RFC 00/22] OMAPDSS: DT support
From: Tomi Valkeinen @ 2013-09-02 8:00 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Nishanth Menon, Felipe Balbi, Santosh Shilimkar, Tony Lindgren
In-Reply-To: <2305295.bk1TpuGLMv@avalon>
[-- Attachment #1: Type: text/plain, Size: 6522 bytes --]
On 22/08/13 00:07, Laurent Pinchart wrote:
Thanks for the comments!
>> The exception to the above are DSI and DBI. DSI and DBI are combined control
>> and video busses, but the use of the busses for control purposes is not
>> independent of the video stream. Also, the the busses are, in practice,
>> one-to-one links. And last, DSI and DBI display entities are often also
>> controllable via, say, i2c. For these reasons there is no real Linux bus
>> for DSI and DBI and thus the DSI and DBI devices are either platform
>> devices or i2c devices.
>
> That's something I'm less convinced about, but I don't have a too strong
> feeling. The best implementation should get to mainline, I won't nack this
> architecture just for theoretical reasons.
Ok. I posted a response to your DBI bus patch about the issues I see.
>> DSI Module ID
>> =============
>>
>> On OMAP4 we have two DSI modules. To configure the clock routing and pin
>> muxing, we need to know the hardware module ID for the DSI device, i.e. is
>> this Linux platform device DSI1 or DSI2. The same issue exists with other
>> SoCs with multiple outputs of the same kind.
>>
>> With non-DT case, we used the platform device's ID directly. With DT, that
>> doesn't work. I don't currently have a good solution for this, so as a
>> temporary solution the DSI driver contains a table, from which it can find
>> the HW module ID by using the device's base address.
>
> You could add two output ports to the DSS, one for each DSI, and link the DSI
> modules to the DSS output ports in DT. That would represent the hardware
> topology, and would allow the DSI driver to know its ID based on the DSS
> output port it's connected to. It's still a bit hackish in the sense that the
> DSI driver will use information provided by the DSS (the output port number),
> but not more than the current method.
Hmm, yep. That's kind of the same as having an explicit 'module-id'
property in the DSI node. I had implemented that solution at some point,
but considered it too ugly. But I agree that deducing the module-id from
the DSS output port is a bit cleaner, as it doesn't need any special
properties. And it's maybe also better than the address table I have
now, as the address table requires special code for each SoC.
I have to try the V4L2 ports to understand fully how to use them.
In the end, I hope to get rid of the module-id totally. It's really not
a DSI-thing at all. The DSI hardware does not use the module-id for
anything, it's more about how the DSI module is glued in the DSS/SoC.
>> I have some ideas how to deduce the DSS version by poking to certain DSS
>> registers, but it is not yet tested so I don't know if it will work.
>
> That might be a stupid question, but can't you just encode the version in the
> compatible string of the DSS DT node (the one currently compatible with
> "ti,omap[34]-dss") ?
That would require having separate DT files for each revision. For
example, we have Beagle boards with different OMAP reversions.
It's fine to have the version encoded in the compatible string for major
versions, but having all minor revisions encoded there could result in a
mess.
> Version information might also need to be split/duplicated in several of the
> DSS DT nodes. A quick grep through the driver source code shows that the
> version is used by the submodules to infer SoC glue information. For instance
> dsi_get_channel() uses the version to find the DSI module channel ID. That
> information could possibly be retrieved from the links between the DSS DT
> nodes.
Hmm, yes. Well. The DISPC has multiple output channels: LCD, LCD2, LCD3,
TV (depending on the SoC). These outputs go to encoders, and the routing
can be configured. If we consider only DSI encoders on OMAP4, the LCD2
output can be configured to go to DSI1 or DSI2 modules. LCD1 output can
be configured to go to DSI1 (but not to DSI2).
Because the routing has restrictions like mentioned above, it's somewhat
difficult to allocate the DISPC output channels during runtime in a
totally dynamic manner. Say, if we happened to allocate LCD2 for DSI1,
and later we'd want to use DSI2, there would be no DISPC output to use.
That's why we currently have them hardcoded in the driver, and it works
ok in all the use cases we have now. However, some board could need to
setup the channels in some other way for some particular use case.
So, I'm not totally comfortable with hardcoding the DISPC output - DSS
encoder connections in the DT data. While it'd work for most cases, it
doesn't work for all.
Then again, if the connections in the DT data would be considered more
like a default set of connections, and they could be changed later from
the kernel/userspace, then it'd be fine.
>> Some of the DSS modules are actually a combination of multiple smaller
>> modules. For example, the DSI module contains DSI protocol, DSI PHY and DSI
>> PLL modules, each in their own address space. These could perhaps be
>> presented as separate DT nodes and Linux devices, but I am not sure if that
>> is a good approach or not.
>
> What are the chances that one of those block will be upgraded and/or replaced
> independently of the others in the future (I know it's a tricky question) ? It
> might not be worth it going to a too fine-grained approach at the moment, but
> we need to make sure that the DT bindings will allow an easy path forward if
> needed.
For DSI, I believe the chances are quite small. But for HDMI, we already
have this case for OMAP4 and OMAP5, and we're currently working on
splitting the HDMI core, PHY and PLL properly. I think it makes sense to
do the same for DSI also at the same time, especially as the PLL for DSI
and HDMI is the same (afaik).
>> If we shouldn't add the bindings as unstable, when should the bindings be
>> added? Wait until CDF is in the mainline, and use that?
>
> What about using the CDF bindings, without waiting for CDF to be in mainline ?
> I believe the bindings should be upstreamed as unstable to start with anyway.
Yes, I think that makes sense. And that's what I've been aiming at. I'm
just missing the ports-stuff.
Then again, I see opinions that the old bindings should be supported
(e.g. the mails with Tony in this same thread). If so, using CDF
bindings without CDF being in the mainline is a bit risky, as the
bindings could well change.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] video: xilinxfb: use devm_ioremap_resource() instead of devm_request_and_ioremap()
From: Tomi Valkeinen @ 2013-09-02 8:52 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <005401cea77c$6925eec0$3b71cc40$%han@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]
Hi,
On 02/09/13 04:33, Jingoo Han wrote:
> Use devm_ioremap_resource() because devm_request_and_ioremap() is
> obsoleted by devm_ioremap_resource().
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> ---
> drivers/video/xilinxfb.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
> index 6629b29..ed90051 100644
> --- a/drivers/video/xilinxfb.c
> +++ b/drivers/video/xilinxfb.c
> @@ -260,9 +260,9 @@ static int xilinxfb_assign(struct platform_device *pdev,
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> drvdata->regs_phys = res->start;
> - drvdata->regs = devm_request_and_ioremap(&pdev->dev, res);
> - if (!drvdata->regs) {
> - rc = -EADDRNOTAVAIL;
> + drvdata->regs = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(drvdata->regs)) {
> + rc = PTR_ERR(drvdata->regs);
> goto err_region;
> }
> }
I have already applied a similar patch from Julia Lawall.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Hallo..........
From: Mutoni Williams @ 2013-09-02 15:33 UTC (permalink / raw)
Hello,How are you,I hope you're well,my name is Mutoni,I'm medium height and fair in complexion,i love,caring and I decided to contact you.I really want to have a good relationship with you.Next I have a special something I want to discuss with you,and tell you more about my self.Hope hear from you soon.I know age will not be a bearier to our relationship,I will give my best. Yours,Miss.Mutoni.
Hallo,Wie geht es dir,ich hoffe,du bist gut,mein Name ist Mutoni, ich mittlerer Höhe und Messe in Teint bin,ich liebe,fürsorgliche und ich beschlossen,you.I kontaktieren wirklich wollen,eine gute Beziehung mit Ihnen haben.Weiter habe ich eine besondere etwas möchte ich mit Ihnen zu besprechen haben,und erfahren Sie mehr über meine self.Hope von Ihnen zu hören soon.i wissen Alter wird kein bearier,unsere Beziehung zu sein, werde ich mein Bestes geben.Yours,Miss.Mutoni.
^ permalink raw reply
* RE: [PATCH v3 0/5] ARM: vf610: Add DCU framebuffer driver for Vybrid VF610 platform
From: Wang Huan-B18965 @ 2013-09-03 8:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <81BA6E5E0BC2344391CABCEE22D1B6D83F448E@039-SN1MPN1-002.039d.mgd.msft.net>
SGksIEplYW4tQ2hyaXN0b3BoZSwgVG9taSwNCg0KICAgICAgQ291bGQgeW91IHBsZWFzZSBoZWxw
IHRvIHJldmlldyB0aGVzZSBwYXRjaGVzPw0KICAgICAgVGhhbmtzIQ0KDQoNCkJlc3QgUmVnYXJk
cywNCkFsaXNvbiBXYW5nDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog
bGludXgtYXJtLWtlcm5lbCBbbWFpbHRvOmxpbnV4LWFybS1rZXJuZWwtDQo+IGJvdW5jZXNAbGlz
dHMuaW5mcmFkZWFkLm9yZ10gT24gQmVoYWxmIE9mIFdhbmcgSHVhbi1CMTg5NjUNCj4gU2VudDog
TW9uZGF5LCBBdWd1c3QgMjYsIDIwMTMgNTo1MiBQTQ0KPiBUbzogcGxhZ25pb2pAamNyb3NvZnQu
Y29tOyB0b21pLnZhbGtlaW5lbkB0aS5jb207IGxpbnV4LQ0KPiBmYmRldkB2Z2VyLmtlcm5lbC5v
cmc7IGxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZw0KPiBDYzogSmluIFpoZW5n
eGlvbmctUjY0MTg4OyBFc3RldmFtIEZhYmlvLVI0OTQ5Njsgc2hhd24uZ3VvQGxpbmFyby5vcmcN
Cj4gU3ViamVjdDogUkU6IFtQQVRDSCB2MyAwLzVdIEFSTTogdmY2MTA6IEFkZCBEQ1UgZnJhbWVi
dWZmZXIgZHJpdmVyIGZvcg0KPiBWeWJyaWQgVkY2MTAgcGxhdGZvcm0NCj4gDQo+IEhpLCBKZWFu
LUNocmlzdG9waGUsIFRvbWksDQo+IA0KPiAgICAgICAgRG8geW91IGhhdmUgYW55IGNvbW1lbnRz
IGZvciB0aGVzZSBwYXRjaGVzPw0KPiANCj4gICAgICAgIFRoYW5rcyENCj4gDQo+IA0KPiBCZXN0
IFJlZ2FyZHMsDQo+IEFsaXNvbiBXYW5nDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQo+ID4gRnJvbTogbGludXgtYXJtLWtlcm5lbCBbbWFpbHRvOmxpbnV4LWFybS1rZXJuZWwt
DQo+ID4gYm91bmNlc0BsaXN0cy5pbmZyYWRlYWQub3JnXSBPbiBCZWhhbGYgT2YgQWxpc29uIFdh
bmcNCj4gPiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDE1LCAyMDEzIDQ6MDIgUE0NCj4gPiBUbzog
cGxhZ25pb2pAamNyb3NvZnQuY29tOyB0b21pLnZhbGtlaW5lbkB0aS5jb207DQo+ID4gc2hhd24u
Z3VvQGxpbmFyby5vcmc7IEVzdGV2YW0gRmFiaW8tUjQ5NDk2Ow0KPiA+IGxpbnV4LWZiZGV2QHZn
ZXIua2VybmVsLm9yZzsgbGludXgtYXJtLSBrZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZw0KPiA+
IENjOiBKaW4gWmhlbmd4aW9uZy1SNjQxODgNCj4gPiBTdWJqZWN0OiBbUEFUQ0ggdjMgMC81XSBB
Uk06IHZmNjEwOiBBZGQgRENVIGZyYW1lYnVmZmVyIGRyaXZlciBmb3INCj4gPiBWeWJyaWQgVkY2
MTAgcGxhdGZvcm0NCj4gPg0KPiA+IFRoaXMgc2VyaWVzIGNvbnRhaW4gRENVIGZyYW1lYnVmZmVy
IGRyaXZlciBmb3IgRnJlZXNjYWxlIFZ5YnJpZCBWRjYxMA0KPiA+IHBsYXRmb3JtLg0KPiA+DQo+
ID4gVGhlIERpc3BsYXkgQ29udHJvbGxlciBVbml0IChEQ1UpIG1vZHVsZSBpcyBhIHN5c3RlbSBt
YXN0ZXIgdGhhdA0KPiA+IGZldGNoZXMgZ3JhcGhpY3Mgc3RvcmVkIGluIGludGVybmFsIG9yIGV4
dGVybmFsIG1lbW9yeSBhbmQgZGlzcGxheXMNCj4gPiB0aGVtIG9uIGEgVEZUIExDRCBwYW5lbC4g
QSB3aWRlIHJhbmdlIG9mIHBhbmVsIHNpemVzIGlzIHN1cHBvcnRlZCBhbmQNCj4gPiB0aGUgdGlt
aW5nIG9mIHRoZSBpbnRlcmZhY2Ugc2lnbmFscyBpcyBoaWdobHkgY29uZmlndXJhYmxlLg0KPiA+
IEdyYXBoaWNzIGFyZSByZWFkIGRpcmVjdGx5IGZyb20gbWVtb3J5IGFuZCB0aGVuIGJsZW5kZWQg
aW4gcmVhbC10aW1lLA0KPiA+IHdoaWNoIGFsbG93cyBmb3IgZHluYW1pYyBjb250ZW50IGNyZWF0
aW9uIHdpdGggbWluaW1hbCBDUFUNCj4gaW50ZXJ2ZW50aW9uLg0KPiA+DQo+ID4gVGhlIGZlYXR1
cmVzOg0KPiA+ICgxKSBGdWxsIFJHQjg4OCBvdXRwdXQgdG8gVEZUIExDRCBwYW5lbC4NCj4gPiAo
MikgRm9yIHRoZSBjdXJyZW50IExDRCBwYW5lbCwgV1FWR0EgIjQ4MHgyNzIiIGlzIHRlc3RlZC4N
Cj4gPiAoMykgQmxlbmRpbmcgb2YgZWFjaCBwaXhlbCB1c2luZyB1cCB0byA0IHNvdXJjZSBsYXll
cnMgZGVwZW5kZW50IG9uDQo+ID4gc2l6ZSBvZiBwYW5lbC4NCj4gPiAoNCkgRWFjaCBncmFwaGlj
IGxheWVyIGNhbiBiZSBwbGFjZWQgd2l0aCBvbmUgcGl4ZWwgcmVzb2x1dGlvbiBpbg0KPiA+IGVp
dGhlciBheGlzLg0KPiA+ICg1KSBFYWNoIGdyYXBoaWMgbGF5ZXIgc3VwcG9ydCBSR0I1NjUgYW5k
IFJHQjg4OCBkaXJlY3QgY29sb3JzDQo+IHdpdGhvdXQNCj4gPiBhbHBoYSBjaGFubmVsIGFuZCBC
R1JBODg4OCBkaXJlY3QgY29sb3JzIHdpdGggYW4gYWxwaGEgY2hhbm5lbC4NCj4gPiAoNikgRWFj
aCBncmFwaGljIGxheWVyIHN1cHBvcnQgYWxwaGEgYmxlbmRpbmcgd2l0aCA4LWJpdCByZXNvbHV0
aW9uLg0KPiA+DQo+ID4gQ2hhbmdlcyBpbiB2MzoNCj4gPiAtIENvcnJlY3QgRENVX01PREVfQkxF
TkRfSVRFUiBtYWNybyBkZWZpbml0aW9uLg0KPiA+IC0gUmVtb3ZlIGhhcmRjb2RlIHBhbmVsIGRl
c2NyaXB0aW9uIGluIHRoZSBkcml2ZXIuIFVzZSB0aGUgdmlkZW9tb2RlDQo+ID4gaGVscGVycyB0
byBnZXQgdGhlIHJlbGV2YW50IGRhdGEgZnJvbSBkZXZpY2V0cmVlLg0KPiA+IC0gQ29ycmVjdCB0
aGUgd3JvbmcgaW5kZW50YXRpb24uDQo+ID4gLSBVc2UgZGV2XyogZm9yIHByaW50aW5nIG1lc3Nh
Z2VzIGluIGRyaXZlcnMuDQo+ID4gLSBDaGFuZ2UgY2FsY19kaXZfcmF0aW8oKSB0byBmc2xfZGN1
X2NhbGNfZGl2KCksIGFuZCByZXdyaXRlIHRoaXMNCj4gPiBmdW5jdGlvbi4NCj4gPiAtIFVzZSBk
ZXZtX3JlcXVlc3RfaXJxKCkgaW5zdGVhZCBvZiByZXF1ZXN0X2lycSgpLg0KPiA+IC0gRHJvcCB1
c2VsZXNzIGNvZGUuDQo+ID4gLSBJbmNyZWFzZSB0aGUgbGF5ZXJzIG51bWJlciB0byB0aGUgbWF4
aW11bSA2Lg0KPiA+IC0gVXNlIGRtYV9hbGxvY193cml0ZWNvbWJpbmUoKSBpbnN0ZWFkIG9mIGRt
YV9hbGxvY19jb2hlcmVudCgpLg0KPiA+IC0gVXNlIHJ1bnRpbWUgUE0uDQo+ID4NCj4gPiBDaGFu
Z2VzIGluIHYyOg0KPiA+IC0gQWRkIGEgZG9jdW1lbnQgZm9yIERDVSBmcmFtZWJ1ZmZlciBkcml2
ZXIgdW5kZXINCj4gPiBEb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvZmIvLg0KPiA+
DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLQ0KPiA+IEFsaXNvbiBXYW5nICg1KToNCj4gPiAgICAgICBBUk06IGR0czog
dmY2MTA6IEFkZCBEQ1UgYW5kIFRDT04gbm9kZXMNCj4gPiAgICAgICBBUk06IGR0czogdmY2MTAt
dHdyOiBFbmFibGUgRENVIGFuZCBUQ09OIGRldmljZXMNCj4gPiAgICAgICBBUk06IGNsazogdmY2
MTA6IEFkZCBEQ1UgYW5kIFRDT04gY2xvY2sgc3VwcG9ydA0KPiA+ICAgICAgIGZiOiBBZGQgRENV
IGZyYW1lYnVmZmVyIGRyaXZlciBmb3IgVnlicmlkIFZGNjEwIHBsYXRmb3JtDQo+ID4gICAgICAg
RG9jdW1lbnRhdGlvbjogRFQ6IEFkZCBEQ1UgZnJhbWVidWZmZXIgZHJpdmVyDQo+ID4NCj4gPiAg
RG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL2ZiL2ZzbC1kY3UtZmIudHh0IHwgICA2
NyArKysrKw0KPiA+ICBhcmNoL2FybS9ib290L2R0cy92ZjYxMC10d3IuZHRzICAgICAgICAgICAg
ICAgICAgICAgfCAgIDMyICsrKw0KPiA+ICBhcmNoL2FybS9ib290L2R0cy92ZjYxMC5kdHNpICAg
ICAgICAgICAgICAgICAgICAgICAgfCAgIDE5ICstDQo+ID4gIGFyY2gvYXJtL21hY2gtaW14L2Ns
ay12ZjYxMC5jICAgICAgICAgICAgICAgICAgICAgICB8ICAgIDUgKw0KPiA+ICBkcml2ZXJzL3Zp
ZGVvL0tjb25maWcgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDEwICsNCj4gPiAg
ZHJpdmVycy92aWRlby9NYWtlZmlsZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg
MSArDQo+ID4gIGRyaXZlcnMvdmlkZW8vZnNsLWRjdS1mYi5jICAgICAgICAgICAgICAgICAgICAg
ICAgICB8IDEwOTUNCj4gPg0KPiArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKw0KPiA+ICsrKysrKysrKw0KPiA+ICBp
bmNsdWRlL2R0LWJpbmRpbmdzL2Nsb2NrL3ZmNjEwLWNsb2NrLmggICAgICAgICAgICAgfCAgICAz
ICstDQo+ID4gIDggZmlsZXMgY2hhbmdlZCwgMTIzMCBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9u
cygtKSAgY3JlYXRlIG1vZGUNCj4gPiAxMDA2NDQgRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2Jp
bmRpbmdzL2ZiL2ZzbC1kY3UtZmIudHh0DQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCBkcml2ZXJz
L3ZpZGVvL2ZzbC1kY3UtZmIuYw0KPiA+DQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gbGludXgtYXJtLWtlcm5lbCBtYWls
aW5nIGxpc3QNCj4gPiBsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcNCj4gPiBo
dHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJu
ZWwNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQo+IGxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBsaXN0DQo+IGxpbnV4LWFybS1rZXJuZWxAbGlz
dHMuaW5mcmFkZWFkLm9yZw0KPiBodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL2xpbnV4LWFybS1rZXJuZWwNCg0K
^ permalink raw reply
* Re: [RFC 00/22] OMAPDSS: DT support
From: Laurent Pinchart @ 2013-09-03 10:56 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Nishanth Menon, Felipe Balbi, Santosh Shilimkar, Tony Lindgren
In-Reply-To: <5224458F.9070401@ti.com>
[-- Attachment #1: Type: text/plain, Size: 7541 bytes --]
Hi Tomi,
On Monday 02 September 2013 11:00:15 Tomi Valkeinen wrote:
> On 22/08/13 00:07, Laurent Pinchart wrote:
>
> Thanks for the comments!
You're welcome.
> >> The exception to the above are DSI and DBI. DSI and DBI are combined
> >> control and video busses, but the use of the busses for control purposes
> >> is not independent of the video stream. Also, the the busses are, in
> >> practice, one-to-one links. And last, DSI and DBI display entities are
> >> often also controllable via, say, i2c. For these reasons there is no
> >> real Linux bus for DSI and DBI and thus the DSI and DBI devices are
> >> either platform devices or i2c devices.
> >
> > That's something I'm less convinced about, but I don't have a too strong
> > feeling. The best implementation should get to mainline, I won't nack this
> > architecture just for theoretical reasons.
>
> Ok. I posted a response to your DBI bus patch about the issues I see.
I'll reply in that mail thread then.
> >> DSI Module ID
> >> =============
> >>
> >> On OMAP4 we have two DSI modules. To configure the clock routing and pin
> >> muxing, we need to know the hardware module ID for the DSI device, i.e.
> >> is this Linux platform device DSI1 or DSI2. The same issue exists with
> >> other SoCs with multiple outputs of the same kind.
> >>
> >> With non-DT case, we used the platform device's ID directly. With DT,
> >> that doesn't work. I don't currently have a good solution for this, so as
> >> a temporary solution the DSI driver contains a table, from which it can
> >> find the HW module ID by using the device's base address.
> >
> > You could add two output ports to the DSS, one for each DSI, and link the
> > DSI modules to the DSS output ports in DT. That would represent the
> > hardware topology, and would allow the DSI driver to know its ID based on
> > the DSS output port it's connected to. It's still a bit hackish in the
> > sense that the DSI driver will use information provided by the DSS (the
> > output port number), but not more than the current method.
>
> Hmm, yep. That's kind of the same as having an explicit 'module-id'
> property in the DSI node. I had implemented that solution at some point,
> but considered it too ugly. But I agree that deducing the module-id from
> the DSS output port is a bit cleaner, as it doesn't need any special
> properties. And it's maybe also better than the address table I have
> now, as the address table requires special code for each SoC.
>
> I have to try the V4L2 ports to understand fully how to use them.
Feel free to ask questions :-)
> In the end, I hope to get rid of the module-id totally. It's really not
> a DSI-thing at all. The DSI hardware does not use the module-id for
> anything, it's more about how the DSI module is glued in the DSS/SoC.
>
> >> I have some ideas how to deduce the DSS version by poking to certain DSS
> >> registers, but it is not yet tested so I don't know if it will work.
> >
> > That might be a stupid question, but can't you just encode the version in
> > the compatible string of the DSS DT node (the one currently compatible
> > with "ti,omap[34]-dss") ?
>
> That would require having separate DT files for each revision. For
> example, we have Beagle boards with different OMAP reversions.
>
> It's fine to have the version encoded in the compatible string for major
> versions, but having all minor revisions encoded there could result in a
> mess.
Obviously if you can detect the version at runtime that would be best. Let's
see if that can be done and then decide on what solution to implement.
> > Version information might also need to be split/duplicated in several of
> > the DSS DT nodes. A quick grep through the driver source code shows that
> > the version is used by the submodules to infer SoC glue information. For
> > instance dsi_get_channel() uses the version to find the DSI module
> > channel ID. That information could possibly be retrieved from the links
> > between the DSS DT nodes.
>
> Hmm, yes. Well. The DISPC has multiple output channels: LCD, LCD2, LCD3,
> TV (depending on the SoC). These outputs go to encoders, and the routing
> can be configured. If we consider only DSI encoders on OMAP4, the LCD2
> output can be configured to go to DSI1 or DSI2 modules. LCD1 output can
> be configured to go to DSI1 (but not to DSI2).
>
> Because the routing has restrictions like mentioned above, it's somewhat
> difficult to allocate the DISPC output channels during runtime in a
> totally dynamic manner. Say, if we happened to allocate LCD2 for DSI1,
> and later we'd want to use DSI2, there would be no DISPC output to use.
>
> That's why we currently have them hardcoded in the driver, and it works
> ok in all the use cases we have now. However, some board could need to
> setup the channels in some other way for some particular use case.
>
> So, I'm not totally comfortable with hardcoding the DISPC output - DSS
> encoder connections in the DT data. While it'd work for most cases, it
> doesn't work for all.
Encoding them in the device tree, in the driver(s), or computing them at
runtime in the kernel are all suboptimal solutions. If the connections are
configurable we want to expose that to userspace and let userspace configure
the device. That's not possible yet due to API limitations, so we need to
handle the situation on the kernel side. I'm thus fine with hardcoding this in
the driver for now, DT should not encode more than possible connections, it
shouldn't cary the default configuration.
> Then again, if the connections in the DT data would be considered more
> like a default set of connections, and they could be changed later from
> the kernel/userspace, then it'd be fine.
>
> >> Some of the DSS modules are actually a combination of multiple smaller
> >> modules. For example, the DSI module contains DSI protocol, DSI PHY and
> >> DSI PLL modules, each in their own address space. These could perhaps be
> >> presented as separate DT nodes and Linux devices, but I am not sure if
> >> that is a good approach or not.
> >
> > What are the chances that one of those block will be upgraded and/or
> > replaced independently of the others in the future (I know it's a tricky
> > question) ? It might not be worth it going to a too fine-grained approach
> > at the moment, but we need to make sure that the DT bindings will allow
> > an easy path forward if needed.
>
> For DSI, I believe the chances are quite small. But for HDMI, we already
> have this case for OMAP4 and OMAP5, and we're currently working on
> splitting the HDMI core, PHY and PLL properly. I think it makes sense to
> do the same for DSI also at the same time, especially as the PLL for DSI
> and HDMI is the same (afaik).
Yes, then it's a good idea.
> >> If we shouldn't add the bindings as unstable, when should the bindings be
> >> added? Wait until CDF is in the mainline, and use that?
> >
> > What about using the CDF bindings, without waiting for CDF to be in
> > mainline ? I believe the bindings should be upstreamed as unstable to
> > start with anyway.
>
> Yes, I think that makes sense. And that's what I've been aiming at. I'm
> just missing the ports-stuff.
>
> Then again, I see opinions that the old bindings should be supported (e.g.
> the mails with Tony in this same thread). If so, using CDF bindings without
> CDF being in the mainline is a bit risky, as the bindings could well change.
But it's less risky than using custom bindings, isn't it ? :-)
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH v11 0/8] PHY framework
From: Kishon Vijay Abraham I @ 2013-09-03 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130827192059.GZ3005@radagast>
Hi Greg,
On Wednesday 28 August 2013 12:50 AM, Felipe Balbi wrote:
> Hi,
>
> On Mon, Aug 26, 2013 at 01:44:49PM +0530, Kishon Vijay Abraham I wrote:
>> On Wednesday 21 August 2013 11:16 AM, Kishon Vijay Abraham I wrote:
>>> Added a generic PHY framework that provides a set of APIs for the PHY drivers
>>> to create/destroy a PHY and APIs for the PHY users to obtain a reference to
>>> the PHY with or without using phandle.
>>>
>>> This framework will be of use only to devices that uses external PHY (PHY
>>> functionality is not embedded within the controller).
>>>
>>> The intention of creating this framework is to bring the phy drivers spread
>>> all over the Linux kernel to drivers/phy to increase code re-use and to
>>> increase code maintainability.
>>>
>>> Comments to make PHY as bus wasn't done because PHY devices can be part of
>>> other bus and making a same device attached to multiple bus leads to bad
>>> design.
>>>
>>> If the PHY driver has to send notification on connect/disconnect, the PHY
>>> driver should make use of the extcon framework. Using this susbsystem
>>> to use extcon framwork will have to be analysed.
>>>
>>> You can find this patch series @
>>> git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git testing
>>
>> Looks like there are not further comments on this series. Can you take this in
>> your misc tree?
>
> Do you want me to queue these for you ? There are quite a few users for
> this framework already and I know of at least 2 others which will show
> up for v3.13.
Can you queue this patch series? There are quite a few users already for this
framework.
Thanks
Kishon
^ permalink raw reply
* Re: [PATCH v11 0/8] PHY framework
From: Greg KH @ 2013-09-03 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5225FF63.6080608@ti.com>
On Tue, Sep 03, 2013 at 08:55:23PM +0530, Kishon Vijay Abraham I wrote:
> Hi Greg,
>
> On Wednesday 28 August 2013 12:50 AM, Felipe Balbi wrote:
> > Hi,
> >
> > On Mon, Aug 26, 2013 at 01:44:49PM +0530, Kishon Vijay Abraham I wrote:
> >> On Wednesday 21 August 2013 11:16 AM, Kishon Vijay Abraham I wrote:
> >>> Added a generic PHY framework that provides a set of APIs for the PHY drivers
> >>> to create/destroy a PHY and APIs for the PHY users to obtain a reference to
> >>> the PHY with or without using phandle.
> >>>
> >>> This framework will be of use only to devices that uses external PHY (PHY
> >>> functionality is not embedded within the controller).
> >>>
> >>> The intention of creating this framework is to bring the phy drivers spread
> >>> all over the Linux kernel to drivers/phy to increase code re-use and to
> >>> increase code maintainability.
> >>>
> >>> Comments to make PHY as bus wasn't done because PHY devices can be part of
> >>> other bus and making a same device attached to multiple bus leads to bad
> >>> design.
> >>>
> >>> If the PHY driver has to send notification on connect/disconnect, the PHY
> >>> driver should make use of the extcon framework. Using this susbsystem
> >>> to use extcon framwork will have to be analysed.
> >>>
> >>> You can find this patch series @
> >>> git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git testing
> >>
> >> Looks like there are not further comments on this series. Can you take this in
> >> your misc tree?
> >
> > Do you want me to queue these for you ? There are quite a few users for
> > this framework already and I know of at least 2 others which will show
> > up for v3.13.
>
> Can you queue this patch series? There are quite a few users already for this
> framework.
It will have to wait for 3.13 as the merge window for new features has
been closed for a week or so. Sorry, I'll queue this up after 3.12-rc1
is out.
greg k-h
^ permalink raw reply
* [PATCH] pwm-backlight: add support for device tree gpio control
From: Mike Dunn @ 2013-09-03 19:26 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
This patch adds support for controlling an arbitrary number of gpios to the
pwm-backlight driver. This was left as a TODO when initial device tree support
was added by Thierry a while back. This functionality replaces the callbacks
that are passed in the platform data for non-DT cases. Users can avail
themselves of this feature by adding a 'gpios' property to the 'backlight' node.
When the update_status() callback in backlight_ops runs, the gpios listed in the
property are asserted/deasserted if the specified brightness is non-zero/zero.
Tested on a pxa270-based Palm Treo 680.
Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
---
Thanks for looking!
.../bindings/video/backlight/pwm-backlight.txt | 4 +
drivers/video/backlight/pwm_bl.c | 128 ++++++++++++++++++---
2 files changed, 113 insertions(+), 19 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
index 1e4fc72..4583e68 100644
--- a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
+++ b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
@@ -14,6 +14,9 @@ Required properties:
Optional properties:
- pwm-names: a list of names for the PWM devices specified in the
"pwms" property (see PWM binding[0])
+ - gpios: An arbitrary number of gpios that must be asserted when the
+ backlight is on, and de-asserted when off. They will be asserted
+ in the order they appear, and de-asserted in reverse order.
[0]: Documentation/devicetree/bindings/pwm/pwm.txt
@@ -25,4 +28,5 @@ Example:
brightness-levels = <0 4 8 16 32 64 128 255>;
default-brightness-level = <6>;
+ gpios = <&gpio 77 0>, <&gpio 25 1>; /* gpio 25 is active low */
};
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 1fea627..1e2ab52 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -20,6 +20,12 @@
#include <linux/pwm.h>
#include <linux/pwm_backlight.h>
#include <linux/slab.h>
+#include <linux/of_gpio.h>
+
+struct pwm_bl_gpio {
+ unsigned int gpio;
+ enum of_gpio_flags flags;
+};
struct pwm_bl_data {
struct pwm_device *pwm;
@@ -27,6 +33,8 @@ struct pwm_bl_data {
unsigned int period;
unsigned int lth_brightness;
unsigned int *levels;
+ unsigned int num_gpios;
+ struct pwm_bl_gpio *gpios;
int (*notify)(struct device *,
int brightness);
void (*notify_after)(struct device *,
@@ -94,14 +102,77 @@ static const struct backlight_ops pwm_backlight_ops = {
};
#ifdef CONFIG_OF
+static int pwm_backlight_dt_notify(struct device *dev, int brightness)
+{
+ struct backlight_device *bl = dev_get_drvdata(dev);
+ struct pwm_bl_data *pb = bl_get_data(bl);
+ int i;
+
+ if (brightness) {
+ for (i = 0; i < pb->num_gpios; i++) {
+ if (pb->gpios[i].flags = OF_GPIO_ACTIVE_LOW)
+ gpio_set_value(pb->gpios[i].gpio, 0);
+ else
+ gpio_set_value(pb->gpios[i].gpio, 1);
+ }
+ return 0;
+ }
+
+ /* de-assert gpios in reverse order, in case this is important */
+ for (i = pb->num_gpios - 1; i >= 0; i--) {
+ if (pb->gpios[i].flags = OF_GPIO_ACTIVE_LOW)
+ gpio_set_value(pb->gpios[i].gpio, 1);
+ else
+ gpio_set_value(pb->gpios[i].gpio, 0);
+ }
+ return 0;
+}
+
+static void pwm_backlight_dt_exit(struct pwm_bl_data *pb)
+{
+ int i;
+
+ for (i = 0; i < pb->num_gpios; i++)
+ gpio_free(pb->gpios[i].gpio);
+}
+
+static int pwm_backlight_dt_init(struct device *dev, struct pwm_bl_data *pb)
+{
+ int i, j, ret;
+
+ /* request gpios and drive in the inactive state */
+ for (i = 0; i < pb->num_gpios; i++) {
+ char gpio_name[32];
+ unsigned long flags;
+ if (pb->gpios[i].flags = OF_GPIO_ACTIVE_LOW)
+ flags = GPIOF_OUT_INIT_LOW;
+ else
+ flags = GPIOF_OUT_INIT_HIGH;
+ snprintf(gpio_name, 32, "%s.%d", dev_name(dev), i);
+ ret = gpio_request_one(pb->gpios[i].gpio, flags, gpio_name);
+ if (ret) {
+ dev_err(dev, "gpio #%d request failed\n", i);
+ goto gpio_err;
+ }
+ }
+ return 0;
+
+ gpio_err:
+ for (j = 0; j < i; j++)
+ gpio_free(pb->gpios[j].gpio);
+ return ret;
+}
+
static int pwm_backlight_parse_dt(struct device *dev,
- struct platform_pwm_backlight_data *data)
+ struct platform_pwm_backlight_data *data,
+ struct pwm_bl_data *pb)
{
struct device_node *node = dev->of_node;
struct property *prop;
int length;
u32 value;
- int ret;
+ int ret, i, num_gpios;
+ size_t gpiosize;
if (!node)
return -ENODEV;
@@ -138,13 +209,29 @@ static int pwm_backlight_parse_dt(struct device *dev,
data->max_brightness--;
}
- /*
- * TODO: Most users of this driver use a number of GPIOs to control
- * backlight power. Support for specifying these needs to be
- * added.
- */
+ /* read gpios from DT property */
+ num_gpios = of_gpio_count(node);
+ if (num_gpios = -ENOENT)
+ return 0; /* no 'gpios' property present */
+ if (num_gpios < 0) {
+ dev_err(dev, "invalid DT node: gpios\n");
+ return -EINVAL;
+ }
+ gpiosize = sizeof(struct pwm_bl_gpio) * num_gpios;
+ pb->gpios = devm_kzalloc(dev, gpiosize, GFP_KERNEL);
+ if (!pb->gpios)
+ return -ENOMEM;
+ for (i = 0; i < num_gpios; i++) {
+ int gpio;
+ enum of_gpio_flags flags;
+ gpio = of_get_gpio_flags(node, i, &flags);
+ pb->gpios[i].gpio = (unsigned int)gpio;
+ pb->gpios[i].flags = flags;
+ }
+ pb->num_gpios = (unsigned int)num_gpios;
+ pb->notify = pwm_backlight_dt_notify;
- return 0;
+ return pwm_backlight_dt_init(dev, pb);
}
static struct of_device_id pwm_backlight_of_match[] = {
@@ -155,10 +242,12 @@ static struct of_device_id pwm_backlight_of_match[] = {
MODULE_DEVICE_TABLE(of, pwm_backlight_of_match);
#else
static int pwm_backlight_parse_dt(struct device *dev,
- struct platform_pwm_backlight_data *data)
+ struct platform_pwm_backlight_data *data,
+ struct pwm_bl_data *pb)
{
return -ENODEV;
}
+static void pwm_backlight_dt_exit(struct pwm_bl_data *pb) {}
#endif
static int pwm_backlight_probe(struct platform_device *pdev)
@@ -171,8 +260,14 @@ static int pwm_backlight_probe(struct platform_device *pdev)
unsigned int max;
int ret;
+ pb = devm_kzalloc(&pdev->dev, sizeof(*pb), GFP_KERNEL);
+ if (!pb) {
+ dev_err(&pdev->dev, "no memory for state\n");
+ return -ENOMEM;
+ }
+
if (!data) {
- ret = pwm_backlight_parse_dt(&pdev->dev, &defdata);
+ ret = pwm_backlight_parse_dt(&pdev->dev, &defdata, pb);
if (ret < 0) {
dev_err(&pdev->dev, "failed to find platform data\n");
return ret;
@@ -187,20 +282,14 @@ static int pwm_backlight_probe(struct platform_device *pdev)
return ret;
}
- pb = devm_kzalloc(&pdev->dev, sizeof(*pb), GFP_KERNEL);
- if (!pb) {
- dev_err(&pdev->dev, "no memory for state\n");
- ret = -ENOMEM;
- goto err_alloc;
- }
-
if (data->levels) {
max = data->levels[data->max_brightness];
pb->levels = data->levels;
} else
max = data->max_brightness;
- pb->notify = data->notify;
+ if (pb->notify = NULL) /* not using DT and its built-in notify() */
+ pb->notify = data->notify;
pb->notify_after = data->notify_after;
pb->check_fb = data->check_fb;
pb->exit = data->exit;
@@ -250,9 +339,9 @@ static int pwm_backlight_probe(struct platform_device *pdev)
}
bl->props.brightness = data->dft_brightness;
+ platform_set_drvdata(pdev, bl);
backlight_update_status(bl);
- platform_set_drvdata(pdev, bl);
return 0;
err_alloc:
@@ -271,6 +360,7 @@ static int pwm_backlight_remove(struct platform_device *pdev)
pwm_disable(pb->pwm);
if (pb->exit)
pb->exit(&pdev->dev);
+ pwm_backlight_dt_exit(pb);
return 0;
}
--
1.8.1.5
^ permalink raw reply related
* Re: [RFC 00/22] OMAPDSS: DT support
From: Stefan Roese @ 2013-09-04 7:29 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Laurent Pinchart, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Nishanth Menon, Felipe Balbi, Santosh Shilimkar,
Tony Lindgren
In-Reply-To: <5224458F.9070401@ti.com>
On 28.08.2013 13:40, Tero Kristo wrote:
> On 08/28/2013 01:14 PM, Tomi Valkeinen wrote:
>> On 28/08/13 12:48, Tero Kristo wrote:
>>> On 08/28/2013 12:22 PM, Tomi Valkeinen wrote:
>>>> Hi,
>>>>
>>>> I'm seeing odd clock behavior with Beagle, booting with DT. I'm using
>>>> v3.11-rc7 + DSS DT patches.
>>>
>>> I guess you are not using the clock DT patches? Just making sure I
>>> didn't break anything.
>>
>> No, plain rc7 with my DSS DT patches.
>>
>>>> So, for some reason, the first clk_set_rate goes wrong. Any ideas?
>>>
>>> Hmm, strange. I am not seeing similar behavior, but I am calling
>>> clk_set_rate in different location.... also I am using clock DT patches
>>> (don't try the current version though, as I am reworking them.)
>>>
>>> [ 0.000000] dpll4_ck: 432000000
>>> [ 0.000000] dpll4_m4_ck: 72000000
>>> [ 0.000000] dpll4_m4x2_ck: 144000000
>>> [ 0.000000] dss1_alwon_fck_3430es2: 144000000
>>> [ 0.000000] dpll4_ck: 432000000
>>> [ 0.000000] dpll4_m4_ck: 86400000
>>> [ 0.000000] dpll4_m4x2_ck: 172800000
>>> [ 0.000000] dss1_alwon_fck_3430es2: 172800000
>>>
>>> Do you see the error only when setting to some specific rate (86400000)
>>> or it doesn't matter?
>>
>> I also tried setting to 72000000, with the same result.
>>
>> Do you know if I can somehow easily get debug prints from the clock
>> framework, that could lighten up the issue?
>
> There isn't any good config option for that, I would suggest add prints
> to the clk_set_rate and then for the clocks you are interested in, print
> results for the recalc_rate / set_rate ops also.
Tomi, did you make any progress on this issue? If not I'll try to dig
into it later this week.
BTW: Whats the current plan for your OMAPDSS DT patchset? Is it queued
for v3.12 (this merge windows)? And do you have a git tree to pull the
latest version from?
Thanks,
Stefan
^ permalink raw reply
* Re: [RFC 00/22] OMAPDSS: DT support
From: Tomi Valkeinen @ 2013-09-04 7:41 UTC (permalink / raw)
To: Stefan Roese
Cc: Laurent Pinchart, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Nishanth Menon, Felipe Balbi, Santosh Shilimkar,
Tony Lindgren
In-Reply-To: <5226E13E.1030807@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2406 bytes --]
On 04/09/13 10:29, Stefan Roese wrote:
> On 28.08.2013 13:40, Tero Kristo wrote:
>> On 08/28/2013 01:14 PM, Tomi Valkeinen wrote:
>>> On 28/08/13 12:48, Tero Kristo wrote:
>>>> On 08/28/2013 12:22 PM, Tomi Valkeinen wrote:
>>>>> Hi,
>>>>>
>>>>> I'm seeing odd clock behavior with Beagle, booting with DT. I'm using
>>>>> v3.11-rc7 + DSS DT patches.
>>>>
>>>> I guess you are not using the clock DT patches? Just making sure I
>>>> didn't break anything.
>>>
>>> No, plain rc7 with my DSS DT patches.
>>>
>>>>> So, for some reason, the first clk_set_rate goes wrong. Any ideas?
>>>>
>>>> Hmm, strange. I am not seeing similar behavior, but I am calling
>>>> clk_set_rate in different location.... also I am using clock DT patches
>>>> (don't try the current version though, as I am reworking them.)
>>>>
>>>> [ 0.000000] dpll4_ck: 432000000
>>>> [ 0.000000] dpll4_m4_ck: 72000000
>>>> [ 0.000000] dpll4_m4x2_ck: 144000000
>>>> [ 0.000000] dss1_alwon_fck_3430es2: 144000000
>>>> [ 0.000000] dpll4_ck: 432000000
>>>> [ 0.000000] dpll4_m4_ck: 86400000
>>>> [ 0.000000] dpll4_m4x2_ck: 172800000
>>>> [ 0.000000] dss1_alwon_fck_3430es2: 172800000
>>>>
>>>> Do you see the error only when setting to some specific rate (86400000)
>>>> or it doesn't matter?
>>>
>>> I also tried setting to 72000000, with the same result.
>>>
>>> Do you know if I can somehow easily get debug prints from the clock
>>> framework, that could lighten up the issue?
>>
>> There isn't any good config option for that, I would suggest add prints
>> to the clk_set_rate and then for the clocks you are interested in, print
>> results for the recalc_rate / set_rate ops also.
>
> Tomi, did you make any progress on this issue? If not I'll try to dig
> into it later this week.
No, I haven't had time to debug this. And as this seems to show only
with DT, it's not a very high priority for me. DSS DT for OMAP4 is the
main priority, as the board files have already been removed for OMAP4
boards.
> BTW: Whats the current plan for your OMAPDSS DT patchset? Is it queued
> for v3.12 (this merge windows)? And do you have a git tree to pull the
> latest version from?
The git tree was mentioned in the intro mail.
No, DSS DT won't be in for 3.12. My current feeling is that it will
still take multiple kernel versions until it can be merged.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH v11 0/8] PHY framework
From: Kishon Vijay Abraham I @ 2013-09-04 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130903155030.GA21525@kroah.com>
On Tuesday 03 September 2013 09:20 PM, Greg KH wrote:
> On Tue, Sep 03, 2013 at 08:55:23PM +0530, Kishon Vijay Abraham I wrote:
>> Hi Greg,
>>
>> On Wednesday 28 August 2013 12:50 AM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Mon, Aug 26, 2013 at 01:44:49PM +0530, Kishon Vijay Abraham I wrote:
>>>> On Wednesday 21 August 2013 11:16 AM, Kishon Vijay Abraham I wrote:
>>>>> Added a generic PHY framework that provides a set of APIs for the PHY drivers
>>>>> to create/destroy a PHY and APIs for the PHY users to obtain a reference to
>>>>> the PHY with or without using phandle.
>>>>>
>>>>> This framework will be of use only to devices that uses external PHY (PHY
>>>>> functionality is not embedded within the controller).
>>>>>
>>>>> The intention of creating this framework is to bring the phy drivers spread
>>>>> all over the Linux kernel to drivers/phy to increase code re-use and to
>>>>> increase code maintainability.
>>>>>
>>>>> Comments to make PHY as bus wasn't done because PHY devices can be part of
>>>>> other bus and making a same device attached to multiple bus leads to bad
>>>>> design.
>>>>>
>>>>> If the PHY driver has to send notification on connect/disconnect, the PHY
>>>>> driver should make use of the extcon framework. Using this susbsystem
>>>>> to use extcon framwork will have to be analysed.
>>>>>
>>>>> You can find this patch series @
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git testing
>>>>
>>>> Looks like there are not further comments on this series. Can you take this in
>>>> your misc tree?
>>>
>>> Do you want me to queue these for you ? There are quite a few users for
>>> this framework already and I know of at least 2 others which will show
>>> up for v3.13.
>>
>> Can you queue this patch series? There are quite a few users already for this
>> framework.
>
> It will have to wait for 3.13 as the merge window for new features has
> been closed for a week or so. Sorry, I'll queue this up after 3.12-rc1
> is out.
Alright, thanks.
-Kishon
^ permalink raw reply
* [PATCH] add bochs dispi interface framebuffer driver
From: Gerd Hoffmann @ 2013-09-04 9:54 UTC (permalink / raw)
Cc: Gerd Hoffmann, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
open list, open list:FRAMEBUFFER LAYER
This patchs adds a frame buffer driver for (virtual/emulated) vga cards
implementing the bochs dispi interface. Supported hardware are the
bochs vga card with vbe extension and the qemu standard vga.
The driver uses a fixed depth of 32bpp. Otherwise it supports the full
(but small) feature set of the bochs dispi interface: Resolution
switching and display panning. It is tweaked to maximize fbcon speed,
so you'll get the comfort of the framebuffer console in kvm guests
without performance penalty.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
drivers/video/Kconfig | 18 ++
drivers/video/Makefile | 1 +
drivers/video/bochsfb.c | 460 ++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 479 insertions(+)
create mode 100644 drivers/video/bochsfb.c
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 4cf1e1d..3f0ead4 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -284,6 +284,24 @@ config FB_CIRRUS
Say N unless you have such a graphics board or plan to get one
before you next recompile the kernel.
+config FB_BOCHS
+ tristate "Bochs dispi interface support"
+ depends on FB && PCI
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ ---help---
+ This is the frame buffer driver for (virtual/emulated) vga
+ cards implementing the bochs dispi interface. Supported
+ hardware are the bochs vga card with vbe extension and the
+ qemu standard vga.
+
+ The driver handles the PCI variants only. It uses a fixed
+ depth of 32bpp, anything else doesn't make sense these days.
+
+ Say Y here if you plan to run the kernel in a virtual machine
+ emulated by bochs or qemu.
+
config FB_PM2
tristate "Permedia2 support"
depends on FB && ((AMIGA && BROKEN) || PCI)
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index e8bae8d..a946a36 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -103,6 +103,7 @@ obj-$(CONFIG_FB_GOLDFISH) += goldfishfb.o
obj-$(CONFIG_FB_68328) += 68328fb.o
obj-$(CONFIG_FB_GBE) += gbefb.o
obj-$(CONFIG_FB_CIRRUS) += cirrusfb.o
+obj-$(CONFIG_FB_BOCHS) += bochsfb.o
obj-$(CONFIG_FB_ASILIANT) += asiliantfb.o
obj-$(CONFIG_FB_PXA) += pxafb.o
obj-$(CONFIG_FB_PXA168) += pxa168fb.o
diff --git a/drivers/video/bochsfb.c b/drivers/video/bochsfb.c
new file mode 100644
index 0000000..b31472e
--- /dev/null
+++ b/drivers/video/bochsfb.c
@@ -0,0 +1,460 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive for
+ * more details.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/string.h>
+#include <linux/mm.h>
+#include <linux/vmalloc.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+#include <linux/fb.h>
+#include <linux/pm.h>
+#include <linux/init.h>
+#include <linux/pci.h>
+#include <linux/console.h>
+#include <asm/io.h>
+
+#define VBE_DISPI_IOPORT_INDEX 0x01CE
+#define VBE_DISPI_IOPORT_DATA 0x01CF
+
+#define VBE_DISPI_INDEX_ID 0x0
+#define VBE_DISPI_INDEX_XRES 0x1
+#define VBE_DISPI_INDEX_YRES 0x2
+#define VBE_DISPI_INDEX_BPP 0x3
+#define VBE_DISPI_INDEX_ENABLE 0x4
+#define VBE_DISPI_INDEX_BANK 0x5
+#define VBE_DISPI_INDEX_VIRT_WIDTH 0x6
+#define VBE_DISPI_INDEX_VIRT_HEIGHT 0x7
+#define VBE_DISPI_INDEX_X_OFFSET 0x8
+#define VBE_DISPI_INDEX_Y_OFFSET 0x9
+#define VBE_DISPI_INDEX_VIDEO_MEMORY_64K 0xa
+
+#define VBE_DISPI_ID0 0xB0C0
+#define VBE_DISPI_ID1 0xB0C1
+#define VBE_DISPI_ID2 0xB0C2
+#define VBE_DISPI_ID3 0xB0C3
+#define VBE_DISPI_ID4 0xB0C4
+#define VBE_DISPI_ID5 0xB0C5
+
+#define VBE_DISPI_DISABLED 0x00
+#define VBE_DISPI_ENABLED 0x01
+#define VBE_DISPI_GETCAPS 0x02
+#define VBE_DISPI_8BIT_DAC 0x20
+#define VBE_DISPI_LFB_ENABLED 0x40
+#define VBE_DISPI_NOCLEARMEM 0x80
+
+enum bochs_types {
+ BOCHS_QEMU_STDVGA,
+ BOCHS_UNKNOWN,
+};
+
+static const char *bochs_names[] = {
+ [ BOCHS_QEMU_STDVGA ] = "QEMU standard vga",
+ [ BOCHS_UNKNOWN ] = "unknown",
+};
+
+struct bochs_par {
+ void __iomem *mmio;
+ int ioports;
+};
+
+static struct fb_fix_screeninfo bochsfb_fix = {
+ .id = "bochsfb",
+ .type = FB_TYPE_PACKED_PIXELS,
+ .visual = FB_VISUAL_TRUECOLOR,
+ .accel = FB_ACCEL_NONE,
+ .xpanstep = 1,
+ .ypanstep = 1,
+};
+
+static struct fb_var_screeninfo bochsfb_var = {
+ .xres = 1024,
+ .yres = 768,
+ .bits_per_pixel = 32,
+#ifdef __BIG_ENDIAN
+ .transp = { .length = 8, .offset = 0 },
+ .red = { .length = 8, .offset = 8 },
+ .green = { .length = 8, .offset = 16 },
+ .blue = { .length = 8, .offset = 24 },
+#else
+ .transp = { .length = 8, .offset = 24 },
+ .red = { .length = 8, .offset = 16 },
+ .green = { .length = 8, .offset = 8 },
+ .blue = { .length = 8, .offset = 0 },
+#endif
+ .height = -1,
+ .width = -1,
+ .vmode = FB_VMODE_NONINTERLACED,
+ .pixclock = 10000,
+ .left_margin = 16,
+ .right_margin = 16,
+ .upper_margin = 16,
+ .lower_margin = 16,
+ .hsync_len = 8,
+ .vsync_len = 8,
+};
+
+static char *mode;
+module_param(mode, charp, 0);
+MODULE_PARM_DESC(mode, "Initial video mode, default is '1024x768'");
+
+static u16 bochs_read(struct fb_info *info, u16 reg)
+{
+ struct bochs_par *bochs = info->par;
+ u16 ret = 0;
+
+ if (bochs->mmio) {
+ int offset = 0x500 + (reg << 1);
+ ret = readw(bochs->mmio + offset);
+ } else {
+ outw(reg, VBE_DISPI_IOPORT_INDEX);
+ ret = inw(VBE_DISPI_IOPORT_DATA);
+ }
+ return ret;
+}
+
+static void bochs_write(struct fb_info *info, u16 reg, u16 val)
+{
+ struct bochs_par *bochs = info->par;
+
+ if (bochs->mmio) {
+ int offset = 0x500 + (reg << 1);
+ writew(val, bochs->mmio + offset);
+ } else {
+ outw(reg, VBE_DISPI_IOPORT_INDEX);
+ outw(val, VBE_DISPI_IOPORT_DATA);
+ }
+}
+
+static int bochsfb_check_var(struct fb_var_screeninfo *var,
+ struct fb_info *info)
+{
+ uint32_t x,y, xv,yv, pixels;
+
+ if (var->bits_per_pixel != 32 ||
+ var->xres > 65535 ||
+ var->xres_virtual > 65535 ||
+ (var->vmode & FB_VMODE_MASK) != FB_VMODE_NONINTERLACED)
+ return -EINVAL;
+
+ x = var->xres;
+ y = var->yres;
+ xv = var->xres_virtual;
+ yv = var->yres_virtual;
+ if (xv < x)
+ xv = x;
+ pixels = info->fix.smem_len * 8 / info->var.bits_per_pixel;
+ yv = pixels / xv;
+ if (y > yv)
+ return -EINVAL;
+
+ var->xres = x;
+ var->yres = y;
+ var->xres_virtual = xv;
+ var->yres_virtual = yv;
+ var->xoffset = 0;
+ var->yoffset = 0;
+
+ return 0;
+}
+
+static int bochsfb_set_par(struct fb_info *info)
+{
+ dev_dbg(info->dev, "set mode: real: %dx%d, virtual: %dx%d\n",
+ info->var.xres, info->var.yres,
+ info->var.xres_virtual, info->var.yres_virtual);
+
+ info->fix.line_length = info->var.xres * info->var.bits_per_pixel / 8;
+
+ bochs_write(info, VBE_DISPI_INDEX_BPP, info->var.bits_per_pixel);
+ bochs_write(info, VBE_DISPI_INDEX_XRES, info->var.xres);
+ bochs_write(info, VBE_DISPI_INDEX_YRES, info->var.yres);
+ bochs_write(info, VBE_DISPI_INDEX_BANK, 0);
+ bochs_write(info, VBE_DISPI_INDEX_VIRT_WIDTH, info->var.xres_virtual);
+ bochs_write(info, VBE_DISPI_INDEX_VIRT_HEIGHT, info->var.yres_virtual);
+ bochs_write(info, VBE_DISPI_INDEX_X_OFFSET, info->var.xoffset);
+ bochs_write(info, VBE_DISPI_INDEX_Y_OFFSET, info->var.yoffset);
+
+ bochs_write(info, VBE_DISPI_INDEX_ENABLE,
+ VBE_DISPI_ENABLED | VBE_DISPI_LFB_ENABLED);
+ return 0;
+}
+
+static int bochsfb_setcolreg(unsigned regno, unsigned red, unsigned green,
+ unsigned blue, unsigned transp,
+ struct fb_info *info)
+{
+ if (regno < 16 && info->var.bits_per_pixel = 32) {
+ red >>= 8;
+ green >>= 8;
+ blue >>= 8;
+ ((u32 *)(info->pseudo_palette))[regno] + (red << info->var.red.offset) |
+ (green << info->var.green.offset) |
+ (blue << info->var.blue.offset);
+ }
+ return 0;
+}
+
+static int bochsfb_pan_display(struct fb_var_screeninfo *var,
+ struct fb_info *info)
+{
+ bochs_write(info, VBE_DISPI_INDEX_X_OFFSET, var->xoffset);
+ bochs_write(info, VBE_DISPI_INDEX_Y_OFFSET, var->yoffset);
+ return 0;
+}
+
+static struct fb_ops bochsfb_ops = {
+ .owner = THIS_MODULE,
+ .fb_check_var = bochsfb_check_var,
+ .fb_set_par = bochsfb_set_par,
+ .fb_setcolreg = bochsfb_setcolreg,
+ .fb_pan_display = bochsfb_pan_display,
+ .fb_fillrect = cfb_fillrect,
+ .fb_copyarea = cfb_copyarea,
+ .fb_imageblit = cfb_imageblit,
+};
+
+static int
+bochsfb_pci_init(struct pci_dev *dp, const struct pci_device_id *ent)
+{
+ struct fb_info *p;
+ unsigned long addr, size, mem, ioaddr, iosize;
+ struct bochs_par *bochs;
+ u16 id;
+ int rc = -ENODEV;
+
+ p = framebuffer_alloc(sizeof(struct bochs_par), &dp->dev);
+ if (p = NULL) {
+ dev_err(&dp->dev, "Cannot allocate framebuffer structure\n");
+ return -ENOMEM;
+ }
+ bochs = p->par;
+
+ if (pci_enable_device(dp) < 0) {
+ dev_err(&dp->dev, "Cannot enable PCI device\n");
+ goto err_out;
+ }
+
+ if ((ent->driver_data = BOCHS_QEMU_STDVGA) &&
+ (dp->resource[2].flags & IORESOURCE_MEM)) {
+ /* mmio bar with vga and bochs registers present */
+ if (pci_request_region(dp, 2, "bochsfb") != 0) {
+ dev_err(&dp->dev, "Cannot request mmio region\n");
+ rc = -EBUSY;
+ goto err_out;
+ }
+ ioaddr = pci_resource_start(dp, 2);
+ iosize = pci_resource_len(dp, 2);
+ bochs->mmio = ioremap(ioaddr, iosize);
+ if (bochs->mmio = NULL) {
+ dev_err(&dp->dev, "Cannot map mmio region\n");
+ rc = -ENOMEM;
+ goto err_out;
+ }
+ } else {
+ ioaddr = VBE_DISPI_IOPORT_INDEX;
+ iosize = 2;
+ if (!request_region(ioaddr, iosize, "bochsfb")) {
+ dev_err(&dp->dev, "Cannot request ioports\n");
+ rc = -EBUSY;
+ goto err_out;
+ }
+ bochs->ioports = 1;
+ }
+
+ id = bochs_read(p, VBE_DISPI_INDEX_ID);
+ mem = bochs_read(p, VBE_DISPI_INDEX_VIDEO_MEMORY_64K) * 64 * 1024;
+ if ((id & 0xfff0) != VBE_DISPI_ID0) {
+ dev_err(&dp->dev, "ID mismatch\n");
+ goto err_out;
+ }
+
+ if ((dp->resource[0].flags & IORESOURCE_MEM) = 0)
+ goto err_out;
+ addr = pci_resource_start(dp, 0);
+ size = pci_resource_len(dp, 0);
+ if (addr = 0)
+ goto err_out;
+ if (size != mem) {
+ dev_err(&dp->dev, "Size mismatch: pci=%ld, bochs=%ld\n", size, mem);
+ size = min(size, mem);
+ }
+
+ p->apertures = alloc_apertures(1);
+ if (!p->apertures) {
+ rc = -ENOMEM;
+ goto err_out;
+ }
+ p->apertures->ranges[0].base = addr;
+ p->apertures->ranges[0].size = size;
+ remove_conflicting_framebuffers(p->apertures, "bochsfb", false);
+
+ if (pci_request_region(dp, 0, "bochsfb") != 0) {
+ dev_err(&dp->dev, "Cannot request framebuffer\n");
+ rc = -EBUSY;
+ goto err_out;
+ }
+
+ p->screen_base = ioremap(addr, size);
+ if (p->screen_base = NULL) {
+ dev_err(&dp->dev, "Cannot map framebuffer\n");
+ rc = -ENOMEM;
+ goto err_out;
+ }
+ memset(p->screen_base, 0, size);
+
+ dev_info(&dp->dev,"Found bochs VGA, ID 0x%x, type \"%s\".\n",
+ id, bochs_names[ent->driver_data]);
+ dev_info(&dp->dev,"Framebuffer size %ld kB @ 0x%lx, %s @ 0x%lx.\n",
+ size / 1024, addr,
+ bochs->ioports ? "ioports" : "mmio",
+ ioaddr);
+
+ pci_set_drvdata(dp, p);
+ p->fbops = &bochsfb_ops;
+ p->flags = FBINFO_FLAG_DEFAULT
+ | FBINFO_READS_FAST
+ | FBINFO_HWACCEL_XPAN
+ | FBINFO_HWACCEL_YPAN;
+ p->pseudo_palette = kmalloc(sizeof(u32) * 16, GFP_KERNEL);
+ p->fix = bochsfb_fix;
+ p->fix.smem_start = addr;
+ p->fix.smem_len = size;
+
+ if (screen_info.orig_video_isVGA = VIDEO_TYPE_VLFB ||
+ screen_info.orig_video_isVGA = VIDEO_TYPE_EFI) {
+ dev_info(&dp->dev,"Picking up default res %dx%d from %s.\n",
+ screen_info.lfb_width, screen_info.lfb_height,
+ screen_info.orig_video_isVGA = VIDEO_TYPE_VLFB ?
+ "vesa" : "efi");
+ screen_info.orig_video_isVGA = 0;
+ bochsfb_var.xres = screen_info.lfb_width;
+ bochsfb_var.yres = screen_info.lfb_height;
+ }
+
+ p->var = bochsfb_var;
+ bochsfb_check_var(&p->var, p);
+ if (mode) {
+ dev_info(&dp->dev,"Looking up configured res \"%s\" in modedb.\n",
+ mode);
+ fb_find_mode(&p->var, p, mode, NULL, 0, NULL, 32);
+ }
+
+ if (register_framebuffer(p) < 0) {
+ dev_err(&dp->dev,"Framebuffer failed to register\n");
+ goto err_out;
+ }
+
+ dev_info(&dp->dev,"fb%d: bochs VGA frame buffer initialized.\n",
+ p->node);
+
+ return 0;
+
+err_out:
+ if (bochs->mmio)
+ iounmap(bochs->mmio);
+ if (bochs->ioports)
+ release_region(VBE_DISPI_IOPORT_INDEX, 2);
+ if (p->screen_base)
+ iounmap(p->screen_base);
+ pci_release_regions(dp);
+ framebuffer_release(p);
+ return rc;
+}
+
+static void bochsfb_remove(struct pci_dev *dp)
+{
+ struct fb_info *p = pci_get_drvdata(dp);
+ struct bochs_par *bochs = p->par;
+
+ if (p->screen_base = NULL)
+ return;
+ unregister_framebuffer(p);
+ if (bochs->mmio)
+ iounmap(bochs->mmio);
+ if (bochs->ioports)
+ release_region(VBE_DISPI_IOPORT_INDEX, 2);
+ if (p->screen_base)
+ iounmap(p->screen_base);
+ pci_release_regions(dp);
+ kfree(p->pseudo_palette);
+ framebuffer_release(p);
+}
+
+static struct pci_device_id bochsfb_pci_tbl[] = {
+ {
+ .vendor = 0x1234,
+ .device = 0x1111,
+ .subvendor = 0x1af4,
+ .subdevice = 0x1100,
+ .driver_data = BOCHS_QEMU_STDVGA,
+ },
+ {
+ .vendor = 0x1234,
+ .device = 0x1111,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ .driver_data = BOCHS_UNKNOWN,
+ },
+ { /* end of list */ }
+};
+
+MODULE_DEVICE_TABLE(pci, bochsfb_pci_tbl);
+
+static struct pci_driver bochsfb_driver = {
+ .name = "bochsfb",
+ .id_table = bochsfb_pci_tbl,
+ .probe = bochsfb_pci_init,
+ .remove = bochsfb_remove,
+};
+
+#ifndef MODULE
+static int __init bochsfb_setup(char *options)
+{
+ char *this_opt;
+
+ if (!options || !*options)
+ return 0;
+
+ while ((this_opt = strsep(&options, ",")) != NULL) {
+ if (!*this_opt)
+ continue;
+ if (!strncmp(this_opt, "mode:", 5))
+ mode = this_opt + 5;
+ else
+ mode = this_opt;
+ }
+ return 0;
+}
+#endif
+
+int __init bochs_init(void)
+{
+#ifndef MODULE
+ char *option = NULL;
+
+ if (fb_get_options("bochsfb", &option))
+ return -ENODEV;
+ bochsfb_setup(option);
+#endif
+ return pci_register_driver(&bochsfb_driver);
+}
+
+module_init(bochs_init);
+
+static void __exit bochsfb_exit(void)
+{
+ pci_unregister_driver(&bochsfb_driver);
+}
+
+module_exit(bochsfb_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Gerd Hoffmann <kraxel@redhat.com>");
+MODULE_DESCRIPTION("bochs dispi interface framebuffer driver");
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v3 0/5] ARM: vf610: Add DCU framebuffer driver for Vybrid VF610 platform
From: Tomi Valkeinen @ 2013-09-04 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <81BA6E5E0BC2344391CABCEE22D1B6D8403CB3@039-SN1MPN1-002.039d.mgd.msft.net>
[-- Attachment #1: Type: text/plain, Size: 418 bytes --]
Hi,
On 03/09/13 11:21, Wang Huan-B18965 wrote:
> Hi, Jean-Christophe, Tomi,
>
> Could you please help to review these patches?
> Thanks!
There seemed to be some strong opinions that there should be a drm
driver for this hardware, instead of an fb driver. So as there seems to
be disagreements about this, I'll leave this series to Jean-Christophe,
who's the primary maintainer.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox