* Re: [RFC v2 2/5] video: panel: Add DPI panel support
From: Tomi Valkeinen @ 2012-11-27 13:02 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-fbdev, dri-devel, linux-media, Archit Taneja,
Benjamin Gaignard, Bryan Wu, Inki Dae, Jesse Barker,
Kyungmin Park, Marcus Lorentzon, Maxime Ripard, Philipp Zabel,
Ragesh Radhakrishnan, Rob Clark, Sascha Hauer, Sebastien Guiriec,
Sumit Semwal, Thomas Petazzoni, Tom Gall, Vikas Sajjan
In-Reply-To: <1353620736-6517-3-git-send-email-laurent.pinchart@ideasonboard.com>
[-- Attachment #1: Type: text/plain, Size: 2123 bytes --]
Hi,
On 2012-11-22 23:45, Laurent Pinchart wrote:
> +static void panel_dpi_release(struct display_entity *entity)
> +{
> + struct panel_dpi *panel = to_panel_dpi(entity);
> +
> + kfree(panel);
> +}
> +
> +static int panel_dpi_remove(struct platform_device *pdev)
> +{
> + struct panel_dpi *panel = platform_get_drvdata(pdev);
> +
> + platform_set_drvdata(pdev, NULL);
> + display_entity_unregister(&panel->entity);
> +
> + return 0;
> +}
> +
> +static int __devinit panel_dpi_probe(struct platform_device *pdev)
> +{
> + const struct panel_dpi_platform_data *pdata = pdev->dev.platform_data;
> + struct panel_dpi *panel;
> + int ret;
> +
> + if (pdata == NULL)
> + return -ENODEV;
> +
> + panel = kzalloc(sizeof(*panel), GFP_KERNEL);
> + if (panel == NULL)
> + return -ENOMEM;
> +
> + panel->pdata = pdata;
> + panel->entity.dev = &pdev->dev;
> + panel->entity.release = panel_dpi_release;
> + panel->entity.ops.ctrl = &panel_dpi_control_ops;
> +
> + ret = display_entity_register(&panel->entity);
> + if (ret < 0) {
> + kfree(panel);
> + return ret;
> + }
> +
> + platform_set_drvdata(pdev, panel);
> +
> + return 0;
> +}
> +
> +static const struct dev_pm_ops panel_dpi_dev_pm_ops = {
> +};
> +
> +static struct platform_driver panel_dpi_driver = {
> + .probe = panel_dpi_probe,
> + .remove = panel_dpi_remove,
> + .driver = {
> + .name = "panel_dpi",
> + .owner = THIS_MODULE,
> + .pm = &panel_dpi_dev_pm_ops,
> + },
> +};
I'm not sure of how the free/release works. The release func is called
when the ref count drops to zero. But... The object in question, the
panel_dpi struct which contains the display entity, is not only about
data, it's also about code located in this module.
So I don't see anything preventing from unloading this module, while
some other component is holding a ref for the display entity. While its
holding the ref, it's valid to call ops in the display entity, but the
code for the ops in this module is already unloaded.
I don't really know how the kref can be used properly in this use case...
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [RFC v2 1/5] video: Add generic display entity core
From: Tomi Valkeinen @ 2012-11-27 13:07 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-fbdev, dri-devel, linux-media, Archit Taneja,
Benjamin Gaignard, Bryan Wu, Inki Dae, Jesse Barker,
Kyungmin Park, Marcus Lorentzon, Maxime Ripard, Philipp Zabel,
Ragesh Radhakrishnan, Rob Clark, Sascha Hauer, Sebastien Guiriec,
Sumit Semwal, Thomas Petazzoni, Tom Gall, Vikas Sajjan
In-Reply-To: <1353620736-6517-2-git-send-email-laurent.pinchart@ideasonboard.com>
[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]
Hi,
On 2012-11-22 23:45, Laurent Pinchart wrote:
> +/**
> + * display_entity_get_modes - Get video modes supported by the display entity
> + * @entity The display entity
> + * @modes: Pointer to an array of modes
> + *
> + * Fill the modes argument with a pointer to an array of video modes. The array
> + * is owned by the display entity.
> + *
> + * Return the number of supported modes on success (including 0 if no mode is
> + * supported) or a negative error code otherwise.
> + */
> +int display_entity_get_modes(struct display_entity *entity,
> + const struct videomode **modes)
> +{
> + if (!entity->ops.ctrl || !entity->ops.ctrl->get_modes)
> + return 0;
> +
> + return entity->ops.ctrl->get_modes(entity, modes);
> +}
> +EXPORT_SYMBOL_GPL(display_entity_get_modes);
> +
> +/**
> + * display_entity_get_size - Get display entity physical size
> + * @entity: The display entity
> + * @width: Physical width in millimeters
> + * @height: Physical height in millimeters
> + *
> + * When applicable, for instance for display panels, retrieve the display
> + * physical size in millimeters.
> + *
> + * Return 0 on success or a negative error code otherwise.
> + */
> +int display_entity_get_size(struct display_entity *entity,
> + unsigned int *width, unsigned int *height)
> +{
> + if (!entity->ops.ctrl || !entity->ops.ctrl->get_size)
> + return -EOPNOTSUPP;
> +
> + return entity->ops.ctrl->get_size(entity, width, height);
> +}
> +EXPORT_SYMBOL_GPL(display_entity_get_size);
How do you envision these to be used with, say, DVI monitors with EDID
data? Should each panel driver, that manages a device with EDID, read
and parse the EDID itself? I guess that shouldn't be too difficult with
a common EDID lib, but that will only expose some of the information
found from EDID. Should the upper levels also have a way to get the raw
EDID data, in addition to funcs like above?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCHv9 1/3] Runtime Interpreted Power Sequences
From: Laurent Pinchart @ 2012-11-27 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121121114018.GA31576@avionic-0098.adnet.avionic-design.de>
[-- Attachment #1: Type: text/plain, Size: 10167 bytes --]
Hi Thierry,
Sorry for the late reply.
On Wednesday 21 November 2012 12:40:18 Thierry Reding wrote:
> On Wed, Nov 21, 2012 at 01:06:03PM +0200, Tomi Valkeinen wrote:
> > On 2012-11-21 06:23, Alex Courbot wrote:
> > > On Wednesday 21 November 2012 05:54:29 Grant Likely wrote:
> > >>> With the advent of the device tree and of ARM kernels that are not
> > >>> board-tied, we cannot rely on these board-specific hooks anymore but
> > >>
> > >> This isn't strictly true. It is still perfectly fine to have board
> > >> specific code when necessary. However, there is strong encouragement to
> > >> enable that code in device drivers as much as possible and new board
> > >> files need to have very strong justification.
> > >
> > > But doesn't introducing board-specific code into the kernel just defeats
> > > the purpose of the DT? If we extend this logic, we are heading straight
> > > back to board-definition files. To a lesser extent than before I agree,
> > > but the problem is fundamentally the same.
> >
> > I don't think so. I'll reiterate my opinion on this subject, as a
> > summary and for those who haven't read the discussions of the earlier
> > versions of the series. And perhaps I'll even manage to say something
> > new =).
> >
> >
> > First about the board specific code. I think we may need some board
> > specific code, even if this series was merged. Let's call them board
> > drivers. These board drivers would only exist for boards with some weird
> > setups that cannot be expressed or managed with DT and normal drivers.
> >
> > I think these cases would be quite rare, as I can't even come up with a
> > very good example. I guess most likely these cases would involve some
> > small trivial chips for muxing or such, for which it doesn't really make
> > sense to have a real driver.
> >
> > Say, perhaps a board with two LCDs connected to one video output, and
> > only one LCD can be enabled at a time, and you need to set some mux chip
> > to route the signals to the correct LCD. In this case I'd see we should
> > have hotplug support in the display framework, and the board driver
> > would act on user input (sysfs file, perhaps), plugging in/out the LCD
> > device depending on the user input.
> >
> >
> > As for expressing device internal details in the DT data, as done in
> > this series, I don't like it very much. I think the DT data or the board
> > file should just describe which device is the one in question, and how
> > it's connected to other components on the board. The driver for the
> > device should handle everything else.
> >
> > As Alex pointed out, there may be lots of devices that work the same way
> > when enabled, but require slightly different power-on/off sequences. We
> > could have these sequences in the driver itself, either as plain code,
> > or in a table of some sort, possibly using the power sequence framework
> > presented in this series. The correct code or sequence would be ran
> > depending on the particular model of the device.
> >
> > I think this approach is correct in the sense that this is what drivers
> > are supposed to do: handle all the device internal matters. But this
> > raises the problem of bloating the kernel with possibly lots of
> > different power sequences, of which only a few would be used by a board,
> > and all the rest would just be waste of memory.
> >
> > Regarding this problem I have the following questions, to which I don't
> > have clear answers:
> >
> > - How much of this device specific data is too much? If a driver
> > supports 10 different models, and the sequences for each model take 100
> > bytes, this 1000 bytes doesn't sound too much. But where's the limit?
> > And even if one driver only has 1kB of this data, what if we have lots
> > of similar drivers?
> >
> > - How many bytes does a power sequence presented in this series take, if
> > the sequence contains, say, 5 steps, with gpio, delay, pwm, delay and
> > regulator?
> >
> > - How likely is it that we'll get lots of different models? A hundred
> > different models for a backlight PWM with different power-on/off
> > sequences already sounds a really big number. If we're only going to
> > have each driver supporting, say, no more than 10 models, perhaps the
> > problem is not even an issue in practice.
> >
> > - Are there ways to limit this bloat in the driver? One obvious way
> > would be to discard the unused sequences after driver probe, but that
> > only works for platform devices. Although, I guess these sequences would
> > mostly be used by platform drivers? If so, then the problem could be
> > solved by discarding the data after probe. Another would be to load the
> > sequences from a file as firmware, but that feels quite an awful
> > solution. Anybody have other ideas?
> >
> > One clear positive side with in-driver approach is that it's totally
> > inside the kernel, and can be easily reworked in the future, or even
> > changed to a DT-based approach as presented in this series if that seems
> > like a better solution. The DT based approach, on the other hand, will
> > be more or less written to stone after it's merged.
> >
> >
> > So, I like the framework of expressing the sequences presented in this
> > series (except there's a problem with error cases, as I pointed out in
> > another post), as it can be used inside the drivers. But I'm not so
> > enthusiastic about presenting the sequences in DT.
> >
> > My suggestion would be to go forward with an in-driver solution, and
> > look at the DT based solution later if we are seeing an increasing bloat
> > in the drivers.
>
> Assuming we go with your approach, what's the plan? We're actually
> facing this problem right now for Tegra. Basically we have a DRM driver
> that can drive the panel, but we're still missing a way to hook up the
> backlight and panel enabling code. So we effectively can't support any
> of the LVDS devices out there without this series.
>
> As I understand it, what you propose is similar to what ASoC does. For a
> specific board, you'd have to write a driver, presumably for the new
> panel/display framework, that provides code to power the panel on and
> off. That means we'll have to have a driver for each panel out there
> basically, or we'd need to write generic drivers that can be configured
> to some degree (via platform data or DT). This is similar to how ASoC
> works, where we have a driver that provides support for a specific codec
> connected to the Tegra SoC. For the display framework things could be
> done in a similar way I suppose, so that Tegra could have one display
> driver to handle all aspects of powering on and off the various panels
> for the various boards out there.
The common display framework (CDF) includes a driver for dumb parallel panels
called panel-dpi. It doesn't handle complex power on/off sequences yet as I
haven't run into any need for them, but that's definitely something we could
add, possibly using Alexandre's code to express the sequences. Similarly to
Tomi, my preferences go for including the sequences in drivers.
> Obviously, a lot of the code will be similar for other SoCs, but maybe
> that's just the way things are if we choose that approach. There's also
> the potential for factoring out large chunks of common code later on
> once we start to see common patterns.
I don't mind duplicating some code in different drivers as a first step.
Factoring out common code in a second step is easier (at least for me) than
trying to figure out what the common code would look like before the first
driver is even written.
> One thing that's not very clear is how the backlight subsystem should be
> wired up with the display framework. I have a patch on top of the Tegra
> DRM driver which adds some ad-hoc display support using this power
> sequences series and the pwm-backlight.
I've touched the backlight API a bit, from both the provider and consumer
points of view, and my feeling is that the API will need to be reworked to
neatly integrate with the CDF. The backlight API currently depends on fbdev,
that's something we should aim to remove. Proposals are welcome :-) Should we
create a separate mail thread for this ?
> From reading the proposal for the panel/display framework, it sounds
> like a lot more is planned than just enabling or disabling panels,
That's correct. CDF implements several other panel control operations (to
retrieve the list of modes supported by the panel for instance), and more
operations will be needed in the future. I've decided to only implement in the
RFC operations that I need for the platforms I work on, and let other
developers propose additional operations depending on their use cases.
> but it also seems like a lot of code needs to be written to support things
> like DSI, DBI or other control busses.
I don't think we need that much code there. The most common control busses for
display hardware are DSI, DBI, I2C, SPI and plain GPIOs. The last three
control busses are well supported in the Linux kernel, I've implemented DBI
support as part of the CDF RFC, and DSI support is missing. If you look at the
DBI bus implementation the amount of code isn't overly large.
> At least for Tegra, and I think the same holds for a wide variety of other
> SoCs, dumb panels would be enough for a start. In the interest of getting a
> working solution for those setups, maybe we can start small and add just
> enough framework to register dumb panel drivers to along with code to wire
> up a backlight to light up the display. Then we could possibly still make it
> to have a proper solution to support the various LVDS panels for Tegra with
> 3.9.
>
> I'm adding Laurent on Cc since he's probably busy working on a new
> proposal for the panel/display framework. Maybe he can share his thought
> on this.
>
> All of the above said, I'm willing to help out with the coding if that's
> what is required to reach a solution that everybody can be happy with.
That's much appreciated. If that means a couple additional hours of sleep per
week for me I'll be extremely thankful :-)
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCHv9 1/3] Runtime Interpreted Power Sequences
From: Laurent Pinchart @ 2012-11-27 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50ACC341.3090204@ti.com>
[-- Attachment #1: Type: text/plain, Size: 4497 bytes --]
Hi Tomi,
On Wednesday 21 November 2012 14:04:17 Tomi Valkeinen wrote:
> On 2012-11-21 13:40, Thierry Reding wrote:
[snip]
> > One thing that's not very clear is how the backlight subsystem should be
> > wired up with the display framework. I have a patch on top of the Tegra
> > DRM driver which adds some ad-hoc display support using this power
> > sequences series and the pwm-backlight.
>
> I think that's a separate issue: how to associate the lcd device and
> backlight device together. I don't have a clear answer to this.
>
> There are many ways the backlight may be handled. In some cases the
> panel and the backlight are truly independent, and you can use the other
> without using the other (not very practical, though =).
From a control point of view that's always the case for DPI panels (as those
panels have no control bus, the backlight control bus is by definition
separate) and is the case for the two DBI panels I've seen (but I won't claim
that's a significative number of panels).
> But then with some LCDs the backlight may be controlled by sending commands
> to the panel, and in this case the two may be quite linked. Changing the
> backlight requires the panel driver to be up and running, and sometimes the
> sending the backlight commands may need to be (say, DSI display, with
> backlight commands going over the DSI bus).
When you write "sending commands to the panel", do you mean on the same
control bus that the panel use ? Or would that also include for instance an
I2C backlight controller integrated inside a DSI panel module ? In the later
case there might still be dependencies between the panel controller and the
backlight controller (let's say for instance that the panel controller has a
DSI-controller GPIO wired to the backlight controller reset signal), but in
practice I don't know if that's ever the case.
> So my feeling is that the panel driver should know about the related
> backlight device. In the first case the panel driver would just call
> enable/disable in the backlight device when the panel is turned on.
That makes sense. Unless I'm mistaken a backlight is always associated with a
panel (it would be called a light if there was no panel in front of it). We
can thus expose backlight operations in the panel CDF (in-kernel) API. The
panel driver would need a way to retrieve a pointer to the associated
backlight device.
> In the second case of the DSI panel... I'm not sure. I've implemented it
> so that the panel driver creates the backlight device, and implements
> the backlight callbacks. It then sends the DSI commands from those
> callbacks.
If we decide to make the panel expose backlight operations we could get rid of
the backlight device in this case.
> > From reading the proposal for the panel/display framework, it sounds
> > like a lot more is planned than just enabling or disabling panels, but
> > it also seems like a lot of code needs to be written to support things
> > like DSI, DBI or other control busses.
> >
> > At least for Tegra, and I think the same holds for a wide variety of
> > other SoCs, dumb panels would be enough for a start. In the interest of
> > getting a working solution for those setups, maybe we can start small
> > and add just enough framework to register dumb panel drivers to along
> > with code to wire up a backlight to light up the display. Then we could
> > possibly still make it to have a proper solution to support the various
> > LVDS panels for Tegra with 3.9.
>
> Yes, we (Laurent and me) both agree that we should start simple.
>
> However, the common panel framework is not strictly needed for this. I'm
> not sure of the current architecture for Tegra, but for OMAP we already
> have panel drivers (omap specific ones, though). The panel drivers may
> support multiple models, (for example,
> drivers/video/omap2/displays/panel-generic-dpi.c).
>
> I don't see any problem with adding small Tegra specific panel drivers
> for the time being, with the intention of converting to common panel
> framework when that's available.
I'm fine with that, but using the CDF would be even better :-)
> Of course, the DT side is an issue. If you now create DT bindings for a
> temporary model, and need to change it again later, you'll have some
> headaches trying managing that without breaking the old bindings... This
> is why I haven't pushed DT bindings for OMAP, as I know I have to change
> them in the near future.
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCHv9 1/3] Runtime Interpreted Power Sequences
From: Laurent Pinchart @ 2012-11-27 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121121130039.GA12191@avionic-0098.adnet.avionic-design.de>
[-- Attachment #1: Type: text/plain, Size: 8540 bytes --]
Hi Thierry,
On Wednesday 21 November 2012 14:00:39 Thierry Reding wrote:
> On Wed, Nov 21, 2012 at 02:04:17PM +0200, Tomi Valkeinen wrote:
> > On 2012-11-21 13:40, Thierry Reding wrote:
> > > On Wed, Nov 21, 2012 at 01:06:03PM +0200, Tomi Valkeinen wrote:
> > (sorry for bouncing back and forth with my private and my @ti addresses.
> > I can't find an option in thunderbird to only use one sender address,
> > and I always forget to change it when responding...)
> >
> > >> My suggestion would be to go forward with an in-driver solution, and
> > >> look at the DT based solution later if we are seeing an increasing
> > >> bloat in the drivers.
> > >
> > > Assuming we go with your approach, what's the plan? We're actually
> > > facing this problem right now for Tegra. Basically we have a DRM driver
> > > that can drive the panel, but we're still missing a way to hook up the
> > > backlight and panel enabling code. So we effectively can't support any
> > > of the LVDS devices out there without this series.
> >
> > Could you describe the hardware setup you have related to the LCD and
> > backlight? Is it a public board with public schematics?
>
> I don't think any of the schematics are public. The Tamonten Evaluation
> Carrier is available publicly from our website and the schematics are
> available on demand as well. If required I can probably arrange to send
> you a copy.
>
> > I've understood that you don't have anything special in your board, just
> > an LCD and a backlight, and the power sequences are related to powering
> > up the LCD and the backlight, without anything board specific. If so,
> > there's no need for board specific code, but just improving the panel
> > and backlight drivers to support the models you use.
>
> Correct. Basically we have two GPIOs that each enable the panel or the
> backlight respectively and one PWM to control the brightness. Are the
> panel drivers that you refer to those in drivers/video? I'm not sure if
> adding more ad-hoc drivers there just to move them to a generic
> framework in the next cycle is a good idea. I'd rather spend some time
> on helping to get the framework right and have drivers for that instead.
Thanks :-) It should be pretty easy to add support for an enable GPIO to the
DPI panel driver that I've posted as part of the CDF RFC v2.
> From what I understand by looking at the OMAP display drivers, they also
> provide the timings for the displays. Steffen's videomode helpers can be
> used to represent these easily in DT, but I suppose if all of those per-
> panel specifics are represented in the drivers then that won't be needed
> anymore either.
For DPI panels it might still make sense to provide the timings through DT or
platform data, as the driver might grow huge otherwise. Panel drivers that
support a couple (dozens) of different models could hardcode the timings.
> > > As I understand it, what you propose is similar to what ASoC does. For a
> > > specific board, you'd have to write a driver, presumably for the new
> > > panel/display framework, that provides code to power the panel on and
> > > off. That means we'll have to have a driver for each panel out there
> > > basically, or we'd need to write generic drivers that can be configured
> > > to some degree (via platform data or DT). This is similar to how ASoC
> > > works, where we have a driver that provides support for a specific codec
> > > connected to the Tegra SoC. For the display framework things could be
> > > done in a similar way I suppose, so that Tegra could have one display
> > > driver to handle all aspects of powering on and off the various panels
> > > for the various boards out there.
> >
> > I think we should only need the board drivers for very special cases. If
> > there's just a panel and a backlight, without any special dynamic muxing
> > or other trickery needed, I don't see a need for a board driver. I
> > presume this is the case for most of the boards.
>
> For Tegra ASoC, the way to provide for this is to allow a specific board
> to introduce a separate compatible value to enable per-board quirks or
> special handling if it cannot be supported by the generic driver and
> configuration mechanisms.
>
> > > Obviously, a lot of the code will be similar for other SoCs, but maybe
> > > that's just the way things are if we choose that approach. There's also
> > > the potential for factoring out large chunks of common code later on
> > > once we start to see common patterns.
> > >
> > > One thing that's not very clear is how the backlight subsystem should be
> > > wired up with the display framework. I have a patch on top of the Tegra
> > > DRM driver which adds some ad-hoc display support using this power
> > > sequences series and the pwm-backlight.
> >
> > I think that's a separate issue: how to associate the lcd device and
> > backlight device together. I don't have a clear answer to this.
> >
> > There are many ways the backlight may be handled. In some cases the
> > panel and the backlight are truly independent, and you can use the other
> > without using the other (not very practical, though =).
>
> At least for DT I think we can easily wire that up. I've actually posted
> a patch recently that does so. I think in most cases it makes sense to
> control them together, such as on DPMS changes, where you really want to
> turn both the backlight and the LCD off, independent of how they are
> tied together.
>
> > But then with some LCDs the backlight may be controlled by sending
> > commands to the panel, and in this case the two may be quite linked.
> > Changing the backlight requires the panel driver to be up and running,
> > and sometimes the sending the backlight commands may need to be (say,
> > DSI display, with backlight commands going over the DSI bus).
> >
> > So my feeling is that the panel driver should know about the related
> > backlight device. In the first case the panel driver would just call
> > enable/disable in the backlight device when the panel is turned on.
>
> Exactly.
>
> > In the second case of the DSI panel... I'm not sure. I've implemented it
> > so that the panel driver creates the backlight device, and implements
> > the backlight callbacks. It then sends the DSI commands from those
> > callbacks.
>
> That certainly sounds like the right approach to me.
>
> > > From reading the proposal for the panel/display framework, it sounds
> > > like a lot more is planned than just enabling or disabling panels, but
> > > it also seems like a lot of code needs to be written to support things
> > > like DSI, DBI or other control busses.
> > >
> > > At least for Tegra, and I think the same holds for a wide variety of
> > > other SoCs, dumb panels would be enough for a start. In the interest of
> > > getting a working solution for those setups, maybe we can start small
> > > and add just enough framework to register dumb panel drivers to along
> > > with code to wire up a backlight to light up the display. Then we could
> > > possibly still make it to have a proper solution to support the various
> > > LVDS panels for Tegra with 3.9.
> >
> > Yes, we (Laurent and me) both agree that we should start simple.
> >
> > However, the common panel framework is not strictly needed for this. I'm
> > not sure of the current architecture for Tegra, but for OMAP we already
> > have panel drivers (omap specific ones, though). The panel drivers may
> > support multiple models, (for example,
> > drivers/video/omap2/displays/panel-generic-dpi.c).
> >
> > I don't see any problem with adding small Tegra specific panel drivers
> > for the time being, with the intention of converting to common panel
> > framework when that's available.
>
> I can take a look at how such a driver could be implemented, but again,
> I'm a bit reluctant to add something ad-hoc now when maybe we can have
> it supported in a proper framework not too far away in the future.
>
> > Of course, the DT side is an issue. If you now create DT bindings for a
> > temporary model, and need to change it again later, you'll have some
> > headaches trying managing that without breaking the old bindings... This
> > is why I haven't pushed DT bindings for OMAP, as I know I have to change
> > them in the near future.
>
> We're already keeping back on this and none of the patches that define
> the bindings have been merged yet. Although bindings have been known to
> change every once in a while even for code that is already in mainline.
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCHv9 1/3] Runtime Interpreted Power Sequences
From: Tomi Valkeinen @ 2012-11-27 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6982060.HfOokt4dIn@avalon>
[-- Attachment #1: Type: text/plain, Size: 3349 bytes --]
On 2012-11-27 17:08, Laurent Pinchart wrote:
> Hi Tomi,
>
> On Wednesday 21 November 2012 14:04:17 Tomi Valkeinen wrote:
>> On 2012-11-21 13:40, Thierry Reding wrote:
>
> [snip]
>
>>> One thing that's not very clear is how the backlight subsystem should be
>>> wired up with the display framework. I have a patch on top of the Tegra
>>> DRM driver which adds some ad-hoc display support using this power
>>> sequences series and the pwm-backlight.
>>
>> I think that's a separate issue: how to associate the lcd device and
>> backlight device together. I don't have a clear answer to this.
>>
>> There are many ways the backlight may be handled. In some cases the
>> panel and the backlight are truly independent, and you can use the other
>> without using the other (not very practical, though =).
>
> From a control point of view that's always the case for DPI panels (as those
> panels have no control bus, the backlight control bus is by definition
> separate) and is the case for the two DBI panels I've seen (but I won't claim
> that's a significative number of panels).
They may have a control bus, I2C, SPI, etc. In some cases that can be
used to control the backlight. But yes, it's separate from the video bus.
>> But then with some LCDs the backlight may be controlled by sending commands
>> to the panel, and in this case the two may be quite linked. Changing the
>> backlight requires the panel driver to be up and running, and sometimes the
>> sending the backlight commands may need to be (say, DSI display, with
>> backlight commands going over the DSI bus).
>
> When you write "sending commands to the panel", do you mean on the same
> control bus that the panel use ? Or would that also include for instance an
> I2C backlight controller integrated inside a DSI panel module ? In the later
I mean the same control bus that is used to control the panel, be it
shared with video bus like DSI, or separate like I2C.
> case there might still be dependencies between the panel controller and the
> backlight controller (let's say for instance that the panel controller has a
> DSI-controller GPIO wired to the backlight controller reset signal), but in
> practice I don't know if that's ever the case.
>
>> So my feeling is that the panel driver should know about the related
>> backlight device. In the first case the panel driver would just call
>> enable/disable in the backlight device when the panel is turned on.
>
> That makes sense. Unless I'm mistaken a backlight is always associated with a
> panel (it would be called a light if there was no panel in front of it). We
> can thus expose backlight operations in the panel CDF (in-kernel) API. The
> panel driver would need a way to retrieve a pointer to the associated
> backlight device.
I agree.
>> In the second case of the DSI panel... I'm not sure. I've implemented it
>> so that the panel driver creates the backlight device, and implements
>> the backlight callbacks. It then sends the DSI commands from those
>> callbacks.
>
> If we decide to make the panel expose backlight operations we could get rid of
> the backlight device in this case.
Do you mean there would be a real backlight device only when there's a
totally independent backlight for the panel?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCHv9 1/3] Runtime Interpreted Power Sequences
From: Laurent Pinchart @ 2012-11-27 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50B4D9E9.8070607@ti.com>
[-- Attachment #1: Type: text/plain, Size: 4870 bytes --]
Hi Tomi,
On Tuesday 27 November 2012 17:19:05 Tomi Valkeinen wrote:
> On 2012-11-27 17:08, Laurent Pinchart wrote:
> > On Wednesday 21 November 2012 14:04:17 Tomi Valkeinen wrote:
> >> On 2012-11-21 13:40, Thierry Reding wrote:
> > [snip]
> >
> >>> One thing that's not very clear is how the backlight subsystem should be
> >>> wired up with the display framework. I have a patch on top of the Tegra
> >>> DRM driver which adds some ad-hoc display support using this power
> >>> sequences series and the pwm-backlight.
> >>
> >> I think that's a separate issue: how to associate the lcd device and
> >> backlight device together. I don't have a clear answer to this.
> >>
> >> There are many ways the backlight may be handled. In some cases the
> >> panel and the backlight are truly independent, and you can use the other
> >> without using the other (not very practical, though =).
> >
> > From a control point of view that's always the case for DPI panels (as
> > those panels have no control bus, the backlight control bus is by
> > definition separate) and is the case for the two DBI panels I've seen
> > (but I won't claim that's a significative number of panels).
>
> They may have a control bus, I2C, SPI, etc. In some cases that can be
> used to control the backlight. But yes, it's separate from the video bus.
>
> >> But then with some LCDs the backlight may be controlled by sending
> >> commands to the panel, and in this case the two may be quite linked.
> >> Changing the backlight requires the panel driver to be up and running,
> >> and sometimes the sending the backlight commands may need to be (say, DSI
> >> display, with backlight commands going over the DSI bus).
> >
> > When you write "sending commands to the panel", do you mean on the same
> > control bus that the panel use ? Or would that also include for instance
> > an I2C backlight controller integrated inside a DSI panel module ? In the
> > later
>
> I mean the same control bus that is used to control the panel, be it shared
> with video bus like DSI, or separate like I2C.
>
> > case there might still be dependencies between the panel controller and
> > the backlight controller (let's say for instance that the panel controller
> > has a DSI-controller GPIO wired to the backlight controller reset signal),
> > but in practice I don't know if that's ever the case.
> >
> >> So my feeling is that the panel driver should know about the related
> >> backlight device. In the first case the panel driver would just call
> >> enable/disable in the backlight device when the panel is turned on.
> >
> > That makes sense. Unless I'm mistaken a backlight is always associated
> > with a panel (it would be called a light if there was no panel in front
> > of it). We can thus expose backlight operations in the panel CDF
> > (in-kernel) API. The panel driver would need a way to retrieve a pointer
> > to the associated backlight device.
>
> I agree.
>
> >> In the second case of the DSI panel... I'm not sure. I've implemented it
> >> so that the panel driver creates the backlight device, and implements
> >> the backlight callbacks. It then sends the DSI commands from those
> >> callbacks.
> >
> > If we decide to make the panel expose backlight operations we could get
> > rid of the backlight device in this case.
>
> Do you mean there would be a real backlight device only when there's a
> totally independent backlight for the panel?
I'm toying with that idea.
I see two reasons for having backlight devices in the kernel right now.
- Integration with the fbdev API to control the backlight automatically on
fbdev blank/unblank/suspend/resume. That's something I want to get rid of,
backlight should not depend on fbdev. If the backlight in-kernel API is
exposed by the panel through CDF operations we won't need this anymore.
- Exposing backlight control to userspace in sysfs. That's quite probably
something we want to keep, if only for compatibility reasons. Backlight on/off
should be controlled through the display APIs through DPMS control, but we
have no way that I'm aware of to control the backlight brightness in the FBDEV
and KMS APIs. It might make sense to add a backlight API to KMS for the
future.
One possibly crazy idea I had was to replace backlight devices as we know them
with LED devices (a LED driver IC shouldn't be supported by different APIs
depending on whether the LEDs it drives are used as a backlight or not), and
have the panel hook up with the associated LED device to expose backlight
operations through the CDF. Panels with a backlight controller tied to the
panel controller (control through DSI for instance) would implement the
backlight operations directly without instantiating a LED device. This still
leaves the question of the userspace backlight brightness API open.
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCHv9 1/3] Runtime Interpreted Power Sequences
From: Mark Brown @ 2012-11-27 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3136860.Z3VvKjeKpU@avalon>
[-- Attachment #1: Type: text/plain, Size: 808 bytes --]
On Tue, Nov 27, 2012 at 04:37:32PM +0100, Laurent Pinchart wrote:
> One possibly crazy idea I had was to replace backlight devices as we know them
> with LED devices (a LED driver IC shouldn't be supported by different APIs
> depending on whether the LEDs it drives are used as a backlight or not), and
> have the panel hook up with the associated LED device to expose backlight
> operations through the CDF. Panels with a backlight controller tied to the
> panel controller (control through DSI for instance) would implement the
> backlight operations directly without instantiating a LED device. This still
> leaves the question of the userspace backlight brightness API open.
I remember looking at that before but never actually got round to it, it
seems like a sensible idea to me.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [GIT PULL] Exynos DP for v3.8
From: Jingoo Han @ 2012-11-27 23:59 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Kukjin Kim,
FlorianSchandinat-Mmb7MZpHnFY@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Jingoo Han,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, Sylwester Nawrocki
In-Reply-To: <28517517.77811353652672706.JavaMail.weblogic@epml06>
T24gVHVlc2RheSwgTm92ZW1iZXIgMjcsIDIwMTIgNjo1OCBQTSwgVG9taSBWYWxrZWluZW4gd3Jv
dGUNCj4gDQo+IE9uIDIwMTItMTEtMjMgMDg6MzcsIEppbmdvbyBIYW4gd3JvdGU6DQo+ID4gSGkg
VG9taSwNCj4gPg0KPiA+IFRoYW5rIHlvdSBmb3IgdGFraW5nIGNhcmUgb2YgcHVsbCByZXF1ZXN0
cyBmb3IgdGhlIHYzLjggbWVyZ2Ugd2luZG93Lg0KPiA+IFRoZXNlIHBhdGNoZXMgaGF2ZSBiZWVu
IHN1Ym1pdHRlZCBmb3IgbW9yZSB0aGFuIG9uZSBtb250aCwNCj4gPiBhbmQgdGVzdGVkIHdpdGgg
RXh5bm9zNTI1MC4NCj4gPg0KPiA+IFRoZSBmb2xsb3dpbmcgY2hhbmdlcyBzaW5jZSBjb21taXQg
ZjRhNzVkMmViN2IxZTIyMDYwOTRiOTAxYmUwOWFkYjMxYmE2MzY4MToNCj4gPg0KPiA+ICAgTGlu
dXggMy43LXJjNiAoRnJpIE5vdiAxNiAxNzo0Mjo0MCAyMDEyIC0wODAwKQ0KPiA+DQo+ID4gYXJl
IGF2YWlsYWJsZSBpbiB0aGUgZ2l0IHJlcG9zaXRvcnkgYXQ6DQo+ID4gICBnaXQ6Ly9naXRodWIu
Y29tL2ppbmdvby9saW51eC5naXQgZXh5bm9zLWRwLW5leHQNCj4gPg0KPiA+IC0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g
PiBFeHlub3MgRFAgY2hhbmdlcyBmb3IgdGhlIDMuOCBtZXJnZSB3aW5kb3cuDQo+ID4NCj4gPiAt
IERldmljZSBUcmVlIHN1cHBvcnQgZm9yIFNhbXN1bmcgRXh5bm9zIERQDQo+ID4gLSBTVyBMaW5r
IHRyYWluaW5nIGlzIGNsZWFuZWQgdXAuDQo+ID4gLSBIUEQgaW50ZXJydXB0IGlzIHN1cHBvcnRl
ZC4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tDQo+ID4NCj4gPiBBamF5IEt1bWFyICg1KToNCj4gPiAgICAgICB2aWRl
bzogZXh5bm9zX2RwOiBBZGQgZGV2aWNlIHRyZWUgc3VwcG9ydCB0byBEUCBkcml2ZXINCj4gPiAg
ICAgICB2aWRlbzogZXh5bm9zX2RwOiBkZXZpY2UgdHJlZSBkb2N1bWVudGF0aW9uDQo+ID4gICAg
ICAgdmlkZW86IGV4eW5vc19kcDogUmVzZXQgYW5kIGluaXRpYWxpemUgRFAgYmVmb3JlIHJlcXVl
c3RpbmcgaXJxDQo+ID4gICAgICAgdmlkZW86IGV4eW5vc19kcDogRml4IGluY29ycmVjdCBzZXR0
aW5nIGZvciBJTlRfQ1RMDQo+ID4gICAgICAgdmlkZW86IGV4eW5vc19kcDogcmVtb3ZlIHJlZHVu
ZGFudCBwYXJhbWV0ZXJzDQo+ID4NCj4gPiBTZWFuIFBhdWwgKDgpOg0KPiA+ICAgICAgIHZpZGVv
OiBleHlub3NfZHA6IENoZWNrIERQQ0QgcmV0dXJuIGNvZGVzDQo+ID4gICAgICAgdmlkZW86IGV4
eW5vc19kcDogQ2xlYW4gdXAgU1cgbGluayB0cmFpbmluZw0KPiA+ICAgICAgIHZpZGVvOiBleHlu
b3NfZHA6IEdldCBwbGwgbG9jayBiZWZvcmUgcGF0dGVybiBzZXQNCj4gPiAgICAgICB2aWRlbzog
ZXh5bm9zX2RwOiBJbXByb3ZlIEVESUQgZXJyb3IgaGFuZGxpbmcNCj4gPiAgICAgICB2aWRlbzog
ZXh5bm9zX2RwOiBGaXggYnVnIHdoZW4gY2hlY2tpbmcgZHAtPmlycQ0KPiA+ICAgICAgIHZpZGVv
OiBleHlub3NfZHA6IFJlbW92ZSBzaW5rIGNvbnRyb2wgdG8gRDANCj4gPiAgICAgICB2aWRlbzog
ZXh5bm9zX2RwOiBNb3ZlIGhvdHBsdWcgaW50byBhIHdvcmtxdWV1ZQ0KPiA+ICAgICAgIHZpZGVv
OiBleHlub3NfZHA6IEVuYWJsZSBob3RwbHVnIGludGVycnVwdHMNCj4gPg0KPiA+ICAuLi4vZGV2
aWNldHJlZS9iaW5kaW5ncy92aWRlby9leHlub3NfZHAudHh0ICAgICAgICB8ICAgODAgKysrDQo+
ID4gIGRyaXZlcnMvdmlkZW8vZXh5bm9zL2V4eW5vc19kcF9jb3JlLmMgICAgICAgICAgICAgIHwg
IDY5NyArKysrKysrKysrKystLS0tLS0tLQ0KPiA+ICBkcml2ZXJzL3ZpZGVvL2V4eW5vcy9leHlu
b3NfZHBfY29yZS5oICAgICAgICAgICAgICB8ICAgMjEgKy0NCj4gPiAgZHJpdmVycy92aWRlby9l
eHlub3MvZXh5bm9zX2RwX3JlZy5jICAgICAgICAgICAgICAgfCAgIDc3ICsrLQ0KPiA+ICBkcml2
ZXJzL3ZpZGVvL2V4eW5vcy9leHlub3NfZHBfcmVnLmggICAgICAgICAgICAgICB8ICAgIDMgKy0N
Cj4gPiAgNSBmaWxlcyBjaGFuZ2VkLCA1ODMgaW5zZXJ0aW9ucygrKSwgMjk1IGRlbGV0aW9ucygt
KQ0KPiA+ICBjcmVhdGUgbW9kZSAxMDA2NDQgRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRp
bmdzL3ZpZGVvL2V4eW5vc19kcC50eHQNCj4gDQo+IEhhcyB0aGUgRFQgYmluZGluZ3MgYmVlbiBy
ZXZpZXdlZCBieSB0aGUgZGV2aWNlIHRyZWUgcGVvcGxlPyBJdCB3b3VsZA0KPiBnb29kIHRvIGhh
dmUgYW4gYWNrIGZyb20gdGhlbS4NCg0KQ0MnZWQgZGV2aWNlIHRyZWUgbWFpbGluZy1saXN0LCBH
cmFudCBMaWtlbHksIFJvYiBIZXJyaW5nLCBLdWtqaW4gS2ltLCBTeWx3ZXN0ZXIgTmF3cm9ja2ku
DQoNCkhpIFRvbWksDQoNClRoZSBEVCBiaW5kaW5nIGhhcyBiZWVuIHBvc3RlZCB3aXRoIGRldmlj
ZSB0cmVlIG1haWxpbmctbGlzdA0KKGRldmljZXRyZWUtZGlzY3Vzc0BsaXN0cy5vemxhYnMub3Jn
KSBmb3IgbW9yZSB0aGFuIDIgbW9udGhzLg0KTGFzdCBwYXRjaCBWOCB3YXMgcG9zdGVkIDEgbW9u
dGggYWdvLiBIb3dldmVyLCB0aGVyZSBpcyBubyBvYmplY3Rpb24uDQooaHR0cDovL3d3dy5zcGlu
aWNzLm5ldC9saXN0cy9saW51eC1mYmRldi9tc2cwODM1NC5odG1sKQ0KDQpBbHNvLCBTYW1zdW5n
IHBlb3BsZSBhbHJlYWR5IHJldmlld2VkIGl0Lg0KSW4gbXkgb3BpbmlvbiwgdGhlcmUgaXMgbm8g
bmVlZCB0byBnZXQgQWNrIGZyb20gdGhlIGRldmljZSB0cmVlIHBlb3BsZS4NCg0KR3JhbnQsIFJv
YjogaWYgeW91IGhhdmUgYW5vdGhlciBvcGluaW9uLCBwbGVhc2UgbGV0IG1lIGtub3cga2luZGx5
Lg0KDQpCZXN0IHJlZ2FyZHMsDQpKaW5nb28gSGFuDQoNCg=
^ permalink raw reply
* [PATCH 0/7] OMAPDSS: Cleanup omap_dss_features
From: Chandrabhanu Mahapatra @ 2012-11-28 10:53 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Chandrabhanu Mahapatra
Hi everyone,
this patch series aims at cleaning up of dss_features.c by moving features to
respective submodule drivers.
The 1st patch
* moved struct omap_dss_features members burst_size_unit and buffer_size_unit
to dispc_features
The 2nd patch
* added definition of struct register_field
* created enum dispc_feat_reg_field
* moved data from dss_reg_fields to dispc_reg_fields
The 3rd patch
* added definition of struct param_range
* created enum dispc_range_param
* moved data from dss_param_range to dispc_param_range
The 4th patch
* created struct feats and initialized dsi_feats
* created enum dsi_feat_reg_field
* moved data from dss_reg_fields to dsi_reg_fields
* created dsi_init_features() to initialize dsi_feats
The 5th patch
* created enum dsi_range_param
* moved data from dss_param_range to dsi_param_range
The 6th patch
* added members fld_dispc_clk_switch and dss_fck_max to struct dss_features
and initialized corresponding dss_feats
* removed definition of dss_reg_field
* removed respective omap2_dss_reg_fields, omap3_dss_reg_fields,
omap4_dss_reg_fields and omap5_dss_reg_fields
* removed members reg_fields and num_reg_fields from struct omap_dss_features
* removed enum dss_feat_reg_field
* removed function dss_feat_get_reg_field()
The 7th patch
* added FEAT_PARAM_DSS_FCK to enum dsi_param_range and initialized
corresponding elements in dsi_param_range
* removed struct dss_param_range
* removed enum dss_range_param
* removed functions dss_feat_get_param_min() and dss_feat_get_param_max()
All your comments and suggestions are welcome.
I have based my patches on git://gitorious.org/linux-omap-dss2/linux.git master
Reference Tree:
git://gitorious.org/linux-omap-dss2/chandrabhanus-linux.git dss_cleanup
Regards,
Chandrabhanu
Chandrabhanu Mahapatra (7):
OMAPDSS: DISPC: Move burst_size and buffer_size to dispc_features
OMAPDSS: DISPC: Move DISPC specific dss_reg_fields to dispc_features
OMAPDSS: DISPC: Move DISPC specific dss_params to dispc_features
OMAPDSS: DSI: Move DSI specific reg_fields to dsi_feats
OMAPDSS: DSI: Move DSI specific dss_params to dsi_feats
OMAPDSS: DSS: Add members fld_dispc_clk_switch and dss_fck_max
OMAPDSS: DSI: Add FEAT_PARAM_DSS_FCK
drivers/video/omap2/dss/dispc.c | 188 ++++++++++++++++++++++------
drivers/video/omap2/dss/dsi.c | 198 ++++++++++++++++++++++++++---
drivers/video/omap2/dss/dss.c | 22 +++-
drivers/video/omap2/dss/dss.h | 8 ++
drivers/video/omap2/dss/dss_features.c | 212 --------------------------------
drivers/video/omap2/dss/dss_features.h | 36 ------
6 files changed, 358 insertions(+), 306 deletions(-)
--
1.7.10
^ permalink raw reply
* [PATCH 1/7] OMAPDSS: DISPC: Move burst_size and buffer_size to dispc_features
From: Chandrabhanu Mahapatra @ 2012-11-28 10:53 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Chandrabhanu Mahapatra
In-Reply-To: <cover.1354086150.git.cmahapatra@ti.com>
The burst_size and buffer_size being local data to DISPC are moved to
dispc_features and so removed from struct omap_dss_features. The functions
referring to burst and buffer size are also removed from dss_features.c as they
are now accessed locally in dispc.c.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
---
drivers/video/omap2/dss/dispc.c | 21 +++++++++++++++++----
drivers/video/omap2/dss/dss_features.c | 29 -----------------------------
drivers/video/omap2/dss/dss_features.h | 3 ---
3 files changed, 17 insertions(+), 36 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 3d0ff5b..9f259ba 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -104,6 +104,9 @@ struct dispc_features {
/* swap GFX & WB fifos */
bool gfx_fifo_workaround:1;
+
+ u32 buffer_size_unit;
+ u32 burst_size_unit;
};
#define DISPC_MAX_NR_FIFOS 5
@@ -1056,7 +1059,7 @@ static void dispc_configure_burst_sizes(void)
static u32 dispc_ovl_get_burst_size(enum omap_plane plane)
{
- unsigned unit = dss_feat_get_burst_size_unit();
+ unsigned unit = dispc.feat->burst_size_unit;
/* burst multiplier is always x8 (see dispc_configure_burst_sizes()) */
return unit * 8;
}
@@ -1145,7 +1148,7 @@ static void dispc_init_fifos(void)
u8 start, end;
u32 unit;
- unit = dss_feat_get_buffer_size_unit();
+ unit = dispc.feat->buffer_size_unit;
dss_feat_get_reg_field(FEAT_REG_FIFOSIZE, &start, &end);
@@ -1203,7 +1206,7 @@ void dispc_ovl_set_fifo_threshold(enum omap_plane plane, u32 low, u32 high)
u8 hi_start, hi_end, lo_start, lo_end;
u32 unit;
- unit = dss_feat_get_buffer_size_unit();
+ unit = dispc.feat->buffer_size_unit;
WARN_ON(low % unit != 0);
WARN_ON(high % unit != 0);
@@ -1247,7 +1250,7 @@ void dispc_ovl_compute_fifo_thresholds(enum omap_plane plane,
* buffer_units, and the fifo thresholds must be buffer_unit aligned.
*/
- unsigned buf_unit = dss_feat_get_buffer_size_unit();
+ unsigned buf_unit = dispc.feat->buffer_size_unit;
unsigned ovl_fifo_size, total_fifo_size, burst_size;
int i;
@@ -4095,6 +4098,8 @@ static const struct dispc_features omap24xx_dispc_feats __initconst = {
.calc_scaling = dispc_ovl_calc_scaling_24xx,
.calc_core_clk = calc_core_clk_24xx,
.num_fifos = 3,
+ .buffer_size_unit = 1,
+ .burst_size_unit = 8,
};
static const struct dispc_features omap34xx_rev1_0_dispc_feats __initconst = {
@@ -4111,6 +4116,8 @@ static const struct dispc_features omap34xx_rev1_0_dispc_feats __initconst = {
.calc_scaling = dispc_ovl_calc_scaling_34xx,
.calc_core_clk = calc_core_clk_34xx,
.num_fifos = 3,
+ .buffer_size_unit = 1,
+ .burst_size_unit = 8,
};
static const struct dispc_features omap34xx_rev3_0_dispc_feats __initconst = {
@@ -4127,6 +4134,8 @@ static const struct dispc_features omap34xx_rev3_0_dispc_feats __initconst = {
.calc_scaling = dispc_ovl_calc_scaling_34xx,
.calc_core_clk = calc_core_clk_34xx,
.num_fifos = 3,
+ .buffer_size_unit = 1,
+ .burst_size_unit = 8,
};
static const struct dispc_features omap44xx_dispc_feats __initconst = {
@@ -4144,6 +4153,8 @@ static const struct dispc_features omap44xx_dispc_feats __initconst = {
.calc_core_clk = calc_core_clk_44xx,
.num_fifos = 5,
.gfx_fifo_workaround = true,
+ .buffer_size_unit = 16,
+ .burst_size_unit = 16,
};
static const struct dispc_features omap54xx_dispc_feats __initconst = {
@@ -4161,6 +4172,8 @@ static const struct dispc_features omap54xx_dispc_feats __initconst = {
.calc_core_clk = calc_core_clk_44xx,
.num_fifos = 5,
.gfx_fifo_workaround = true,
+ .buffer_size_unit = 16,
+ .burst_size_unit = 16,
};
static int __init dispc_init_features(struct platform_device *pdev)
diff --git a/drivers/video/omap2/dss/dss_features.c b/drivers/video/omap2/dss/dss_features.c
index 1d125c6..092e21b 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -54,9 +54,6 @@ struct omap_dss_features {
const struct dss_param_range *dss_params;
const enum omap_dss_rotation_type supported_rotation_types;
-
- const u32 buffer_size_unit;
- const u32 burst_size_unit;
};
/* This struct is assigned to one of the below during initialization */
@@ -632,8 +629,6 @@ static const struct omap_dss_features omap2_dss_features = {
.clksrc_names = omap2_dss_clk_source_names,
.dss_params = omap2_dss_param_range,
.supported_rotation_types = OMAP_DSS_ROT_DMA | OMAP_DSS_ROT_VRFB,
- .buffer_size_unit = 1,
- .burst_size_unit = 8,
};
/* OMAP3 DSS Features */
@@ -653,8 +648,6 @@ static const struct omap_dss_features omap3430_dss_features = {
.clksrc_names = omap3_dss_clk_source_names,
.dss_params = omap3_dss_param_range,
.supported_rotation_types = OMAP_DSS_ROT_DMA | OMAP_DSS_ROT_VRFB,
- .buffer_size_unit = 1,
- .burst_size_unit = 8,
};
/*
@@ -677,8 +670,6 @@ static const struct omap_dss_features am35xx_dss_features = {
.clksrc_names = omap3_dss_clk_source_names,
.dss_params = omap3_dss_param_range,
.supported_rotation_types = OMAP_DSS_ROT_DMA | OMAP_DSS_ROT_VRFB,
- .buffer_size_unit = 1,
- .burst_size_unit = 8,
};
static const struct omap_dss_features omap3630_dss_features = {
@@ -697,8 +688,6 @@ static const struct omap_dss_features omap3630_dss_features = {
.clksrc_names = omap3_dss_clk_source_names,
.dss_params = omap3_dss_param_range,
.supported_rotation_types = OMAP_DSS_ROT_DMA | OMAP_DSS_ROT_VRFB,
- .buffer_size_unit = 1,
- .burst_size_unit = 8,
};
/* OMAP4 DSS Features */
@@ -720,8 +709,6 @@ static const struct omap_dss_features omap4430_es1_0_dss_features = {
.clksrc_names = omap4_dss_clk_source_names,
.dss_params = omap4_dss_param_range,
.supported_rotation_types = OMAP_DSS_ROT_DMA | OMAP_DSS_ROT_TILER,
- .buffer_size_unit = 16,
- .burst_size_unit = 16,
};
/* For OMAP4430 ES 2.0, 2.1 and 2.2 revisions */
@@ -742,8 +729,6 @@ static const struct omap_dss_features omap4430_es2_0_1_2_dss_features = {
.clksrc_names = omap4_dss_clk_source_names,
.dss_params = omap4_dss_param_range,
.supported_rotation_types = OMAP_DSS_ROT_DMA | OMAP_DSS_ROT_TILER,
- .buffer_size_unit = 16,
- .burst_size_unit = 16,
};
/* For all the other OMAP4 versions */
@@ -764,8 +749,6 @@ static const struct omap_dss_features omap4_dss_features = {
.clksrc_names = omap4_dss_clk_source_names,
.dss_params = omap4_dss_param_range,
.supported_rotation_types = OMAP_DSS_ROT_DMA | OMAP_DSS_ROT_TILER,
- .buffer_size_unit = 16,
- .burst_size_unit = 16,
};
/* OMAP5 DSS Features */
@@ -785,8 +768,6 @@ static const struct omap_dss_features omap5_dss_features = {
.clksrc_names = omap5_dss_clk_source_names,
.dss_params = omap5_dss_param_range,
.supported_rotation_types = OMAP_DSS_ROT_DMA | OMAP_DSS_ROT_TILER,
- .buffer_size_unit = 16,
- .burst_size_unit = 16,
};
#if defined(CONFIG_OMAP4_DSS_HDMI)
@@ -892,16 +873,6 @@ const char *dss_feat_get_clk_source_name(enum omap_dss_clk_source id)
return omap_current_dss_features->clksrc_names[id];
}
-u32 dss_feat_get_buffer_size_unit(void)
-{
- return omap_current_dss_features->buffer_size_unit;
-}
-
-u32 dss_feat_get_burst_size_unit(void)
-{
- return omap_current_dss_features->burst_size_unit;
-}
-
/* DSS has_feature check */
bool dss_has_feature(enum dss_feat_id id)
{
diff --git a/drivers/video/omap2/dss/dss_features.h b/drivers/video/omap2/dss/dss_features.h
index 385b0af..16658e1 100644
--- a/drivers/video/omap2/dss/dss_features.h
+++ b/drivers/video/omap2/dss/dss_features.h
@@ -114,9 +114,6 @@ bool dss_feat_color_mode_supported(enum omap_plane plane,
enum omap_color_mode color_mode);
const char *dss_feat_get_clk_source_name(enum omap_dss_clk_source id);
-u32 dss_feat_get_buffer_size_unit(void); /* in bytes */
-u32 dss_feat_get_burst_size_unit(void); /* in bytes */
-
bool dss_feat_rotation_type_supported(enum omap_dss_rotation_type rot_type);
bool dss_has_feature(enum dss_feat_id id);
--
1.7.10
^ permalink raw reply related
* [PATCH 2/7] OMAPDSS: DISPC: Move DISPC specific dss_reg_fields to dispc_features
From: Chandrabhanu Mahapatra @ 2012-11-28 10:53 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Chandrabhanu Mahapatra
In-Reply-To: <cover.1354086150.git.cmahapatra@ti.com>
The register fields in dss_reg_fields specific to DISPC are moved from struct
omap_dss_features to corresponding dispc_reg_fields, initialized in struct
dispc_features, thereby enabling local access.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
---
drivers/video/omap2/dss/dispc.c | 87 ++++++++++++++++++++++++++++----
drivers/video/omap2/dss/dss.h | 4 ++
drivers/video/omap2/dss/dss_features.c | 28 ----------
drivers/video/omap2/dss/dss_features.h | 7 ---
4 files changed, 80 insertions(+), 46 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 9f259ba..21fc522 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -80,6 +80,16 @@ struct dispc_irq_stats {
unsigned irqs[32];
};
+enum dispc_feat_reg_field {
+ FEAT_REG_FIRHINC,
+ FEAT_REG_FIRVINC,
+ FEAT_REG_FIFOLOWTHRESHOLD,
+ FEAT_REG_FIFOHIGHTHRESHOLD,
+ FEAT_REG_FIFOSIZE,
+ FEAT_REG_HORIZONTALACCU,
+ FEAT_REG_VERTICALACCU,
+};
+
struct dispc_features {
u8 sw_start;
u8 fp_start;
@@ -107,6 +117,8 @@ struct dispc_features {
u32 buffer_size_unit;
u32 burst_size_unit;
+
+ struct register_field *reg_fields;
};
#define DISPC_MAX_NR_FIFOS 5
@@ -1150,7 +1162,8 @@ static void dispc_init_fifos(void)
unit = dispc.feat->buffer_size_unit;
- dss_feat_get_reg_field(FEAT_REG_FIFOSIZE, &start, &end);
+ start = dispc.feat->reg_fields[FEAT_REG_FIFOSIZE].start;
+ end = dispc.feat->reg_fields[FEAT_REG_FIFOSIZE].end;
for (fifo = 0; fifo < dispc.feat->num_fifos; ++fifo) {
size = REG_GET(DISPC_OVL_FIFO_SIZE_STATUS(fifo), start, end);
@@ -1214,8 +1227,10 @@ void dispc_ovl_set_fifo_threshold(enum omap_plane plane, u32 low, u32 high)
low /= unit;
high /= unit;
- dss_feat_get_reg_field(FEAT_REG_FIFOHIGHTHRESHOLD, &hi_start, &hi_end);
- dss_feat_get_reg_field(FEAT_REG_FIFOLOWTHRESHOLD, &lo_start, &lo_end);
+ hi_start = dispc.feat->reg_fields[FEAT_REG_FIFOHIGHTHRESHOLD].start;
+ hi_end = dispc.feat->reg_fields[FEAT_REG_FIFOHIGHTHRESHOLD].end;
+ lo_start = dispc.feat->reg_fields[FEAT_REG_FIFOLOWTHRESHOLD].start;
+ lo_end = dispc.feat->reg_fields[FEAT_REG_FIFOLOWTHRESHOLD].end;
DSSDBG("fifo(%d) threshold (bytes), old %u/%u, new %u/%u\n",
plane,
@@ -1297,10 +1312,11 @@ static void dispc_ovl_set_fir(enum omap_plane plane,
if (color_comp = DISPC_COLOR_COMPONENT_RGB_Y) {
u8 hinc_start, hinc_end, vinc_start, vinc_end;
- dss_feat_get_reg_field(FEAT_REG_FIRHINC,
- &hinc_start, &hinc_end);
- dss_feat_get_reg_field(FEAT_REG_FIRVINC,
- &vinc_start, &vinc_end);
+ hinc_start = dispc.feat->reg_fields[FEAT_REG_FIRHINC].start;
+ hinc_end = dispc.feat->reg_fields[FEAT_REG_FIRHINC].end;
+ vinc_start = dispc.feat->reg_fields[FEAT_REG_FIRVINC].start;
+ vinc_end = dispc.feat->reg_fields[FEAT_REG_FIRVINC].end;
+
val = FLD_VAL(vinc, vinc_start, vinc_end) |
FLD_VAL(hinc, hinc_start, hinc_end);
@@ -1316,8 +1332,10 @@ static void dispc_ovl_set_vid_accu0(enum omap_plane plane, int haccu, int vaccu)
u32 val;
u8 hor_start, hor_end, vert_start, vert_end;
- dss_feat_get_reg_field(FEAT_REG_HORIZONTALACCU, &hor_start, &hor_end);
- dss_feat_get_reg_field(FEAT_REG_VERTICALACCU, &vert_start, &vert_end);
+ hor_start = dispc.feat->reg_fields[FEAT_REG_HORIZONTALACCU].start;
+ hor_end = dispc.feat->reg_fields[FEAT_REG_HORIZONTALACCU].end;
+ vert_start = dispc.feat->reg_fields[FEAT_REG_VERTICALACCU].start;
+ vert_end = dispc.feat->reg_fields[FEAT_REG_VERTICALACCU].end;
val = FLD_VAL(vaccu, vert_start, vert_end) |
FLD_VAL(haccu, hor_start, hor_end);
@@ -1330,8 +1348,10 @@ static void dispc_ovl_set_vid_accu1(enum omap_plane plane, int haccu, int vaccu)
u32 val;
u8 hor_start, hor_end, vert_start, vert_end;
- dss_feat_get_reg_field(FEAT_REG_HORIZONTALACCU, &hor_start, &hor_end);
- dss_feat_get_reg_field(FEAT_REG_VERTICALACCU, &vert_start, &vert_end);
+ hor_start = dispc.feat->reg_fields[FEAT_REG_HORIZONTALACCU].start;
+ hor_end = dispc.feat->reg_fields[FEAT_REG_HORIZONTALACCU].end;
+ vert_start = dispc.feat->reg_fields[FEAT_REG_VERTICALACCU].start;
+ vert_end = dispc.feat->reg_fields[FEAT_REG_VERTICALACCU].end;
val = FLD_VAL(vaccu, vert_start, vert_end) |
FLD_VAL(haccu, hor_start, hor_end);
@@ -4084,6 +4104,46 @@ static void _omap_dispc_initial_config(void)
dispc_ovl_enable_zorder_planes();
}
+static struct register_field omap2_dispc_reg_fields[] = {
+ [FEAT_REG_FIRHINC] = { 11, 0 },
+ [FEAT_REG_FIRVINC] = { 27, 16 },
+ [FEAT_REG_FIFOLOWTHRESHOLD] = { 8, 0 },
+ [FEAT_REG_FIFOHIGHTHRESHOLD] = { 24, 16 },
+ [FEAT_REG_FIFOSIZE] = { 8, 0 },
+ [FEAT_REG_HORIZONTALACCU] = { 9, 0 },
+ [FEAT_REG_VERTICALACCU] = { 25, 16 },
+};
+
+static struct register_field omap3_dispc_reg_fields[] = {
+ [FEAT_REG_FIRHINC] = { 12, 0 },
+ [FEAT_REG_FIRVINC] = { 28, 16 },
+ [FEAT_REG_FIFOLOWTHRESHOLD] = { 11, 0 },
+ [FEAT_REG_FIFOHIGHTHRESHOLD] = { 27, 16 },
+ [FEAT_REG_FIFOSIZE] = { 10, 0 },
+ [FEAT_REG_HORIZONTALACCU] = { 9, 0 },
+ [FEAT_REG_VERTICALACCU] = { 25, 16 },
+};
+
+static struct register_field omap4_dispc_reg_fields[] = {
+ [FEAT_REG_FIRHINC] = { 12, 0 },
+ [FEAT_REG_FIRVINC] = { 28, 16 },
+ [FEAT_REG_FIFOLOWTHRESHOLD] = { 15, 0 },
+ [FEAT_REG_FIFOHIGHTHRESHOLD] = { 31, 16 },
+ [FEAT_REG_FIFOSIZE] = { 15, 0 },
+ [FEAT_REG_HORIZONTALACCU] = { 10, 0 },
+ [FEAT_REG_VERTICALACCU] = { 26, 16 },
+};
+
+static struct register_field omap5_dispc_reg_fields[] = {
+ [FEAT_REG_FIRHINC] = { 12, 0 },
+ [FEAT_REG_FIRVINC] = { 28, 16 },
+ [FEAT_REG_FIFOLOWTHRESHOLD] = { 15, 0 },
+ [FEAT_REG_FIFOHIGHTHRESHOLD] = { 31, 16 },
+ [FEAT_REG_FIFOSIZE] = { 15, 0 },
+ [FEAT_REG_HORIZONTALACCU] = { 10, 0 },
+ [FEAT_REG_VERTICALACCU] = { 26, 16 },
+};
+
static const struct dispc_features omap24xx_dispc_feats __initconst = {
.sw_start = 5,
.fp_start = 15,
@@ -4100,6 +4160,7 @@ static const struct dispc_features omap24xx_dispc_feats __initconst = {
.num_fifos = 3,
.buffer_size_unit = 1,
.burst_size_unit = 8,
+ .reg_fields = omap2_dispc_reg_fields,
};
static const struct dispc_features omap34xx_rev1_0_dispc_feats __initconst = {
@@ -4118,6 +4179,7 @@ static const struct dispc_features omap34xx_rev1_0_dispc_feats __initconst = {
.num_fifos = 3,
.buffer_size_unit = 1,
.burst_size_unit = 8,
+ .reg_fields = omap3_dispc_reg_fields,
};
static const struct dispc_features omap34xx_rev3_0_dispc_feats __initconst = {
@@ -4136,6 +4198,7 @@ static const struct dispc_features omap34xx_rev3_0_dispc_feats __initconst = {
.num_fifos = 3,
.buffer_size_unit = 1,
.burst_size_unit = 8,
+ .reg_fields = omap3_dispc_reg_fields,
};
static const struct dispc_features omap44xx_dispc_feats __initconst = {
@@ -4155,6 +4218,7 @@ static const struct dispc_features omap44xx_dispc_feats __initconst = {
.gfx_fifo_workaround = true,
.buffer_size_unit = 16,
.burst_size_unit = 16,
+ .reg_fields = omap4_dispc_reg_fields,
};
static const struct dispc_features omap54xx_dispc_feats __initconst = {
@@ -4174,6 +4238,7 @@ static const struct dispc_features omap54xx_dispc_feats __initconst = {
.gfx_fifo_workaround = true,
.buffer_size_unit = 16,
.burst_size_unit = 16,
+ .reg_fields = omap5_dispc_reg_fields,
};
static int __init dispc_init_features(struct platform_device *pdev)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 84a7f6a..aa273d8 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -143,6 +143,10 @@ struct reg_field {
u8 low;
};
+struct register_field {
+ u8 start, end;
+};
+
struct dss_lcd_mgr_config {
enum dss_io_pad_mode io_pad_mode;
diff --git a/drivers/video/omap2/dss/dss_features.c b/drivers/video/omap2/dss/dss_features.c
index 092e21b..defdfc0 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -60,13 +60,6 @@ struct omap_dss_features {
static const struct omap_dss_features *omap_current_dss_features;
static const struct dss_reg_field omap2_dss_reg_fields[] = {
- [FEAT_REG_FIRHINC] = { 11, 0 },
- [FEAT_REG_FIRVINC] = { 27, 16 },
- [FEAT_REG_FIFOLOWTHRESHOLD] = { 8, 0 },
- [FEAT_REG_FIFOHIGHTHRESHOLD] = { 24, 16 },
- [FEAT_REG_FIFOSIZE] = { 8, 0 },
- [FEAT_REG_HORIZONTALACCU] = { 9, 0 },
- [FEAT_REG_VERTICALACCU] = { 25, 16 },
[FEAT_REG_DISPC_CLK_SWITCH] = { 0, 0 },
[FEAT_REG_DSIPLL_REGN] = { 0, 0 },
[FEAT_REG_DSIPLL_REGM] = { 0, 0 },
@@ -75,13 +68,6 @@ static const struct dss_reg_field omap2_dss_reg_fields[] = {
};
static const struct dss_reg_field omap3_dss_reg_fields[] = {
- [FEAT_REG_FIRHINC] = { 12, 0 },
- [FEAT_REG_FIRVINC] = { 28, 16 },
- [FEAT_REG_FIFOLOWTHRESHOLD] = { 11, 0 },
- [FEAT_REG_FIFOHIGHTHRESHOLD] = { 27, 16 },
- [FEAT_REG_FIFOSIZE] = { 10, 0 },
- [FEAT_REG_HORIZONTALACCU] = { 9, 0 },
- [FEAT_REG_VERTICALACCU] = { 25, 16 },
[FEAT_REG_DISPC_CLK_SWITCH] = { 0, 0 },
[FEAT_REG_DSIPLL_REGN] = { 7, 1 },
[FEAT_REG_DSIPLL_REGM] = { 18, 8 },
@@ -90,13 +76,6 @@ static const struct dss_reg_field omap3_dss_reg_fields[] = {
};
static const struct dss_reg_field omap4_dss_reg_fields[] = {
- [FEAT_REG_FIRHINC] = { 12, 0 },
- [FEAT_REG_FIRVINC] = { 28, 16 },
- [FEAT_REG_FIFOLOWTHRESHOLD] = { 15, 0 },
- [FEAT_REG_FIFOHIGHTHRESHOLD] = { 31, 16 },
- [FEAT_REG_FIFOSIZE] = { 15, 0 },
- [FEAT_REG_HORIZONTALACCU] = { 10, 0 },
- [FEAT_REG_VERTICALACCU] = { 26, 16 },
[FEAT_REG_DISPC_CLK_SWITCH] = { 9, 8 },
[FEAT_REG_DSIPLL_REGN] = { 8, 1 },
[FEAT_REG_DSIPLL_REGM] = { 20, 9 },
@@ -105,13 +84,6 @@ static const struct dss_reg_field omap4_dss_reg_fields[] = {
};
static const struct dss_reg_field omap5_dss_reg_fields[] = {
- [FEAT_REG_FIRHINC] = { 12, 0 },
- [FEAT_REG_FIRVINC] = { 28, 16 },
- [FEAT_REG_FIFOLOWTHRESHOLD] = { 15, 0 },
- [FEAT_REG_FIFOHIGHTHRESHOLD] = { 31, 16 },
- [FEAT_REG_FIFOSIZE] = { 15, 0 },
- [FEAT_REG_HORIZONTALACCU] = { 10, 0 },
- [FEAT_REG_VERTICALACCU] = { 26, 16 },
[FEAT_REG_DISPC_CLK_SWITCH] = { 9, 7 },
[FEAT_REG_DSIPLL_REGN] = { 8, 1 },
[FEAT_REG_DSIPLL_REGM] = { 20, 9 },
diff --git a/drivers/video/omap2/dss/dss_features.h b/drivers/video/omap2/dss/dss_features.h
index 16658e1..42a1bd1 100644
--- a/drivers/video/omap2/dss/dss_features.h
+++ b/drivers/video/omap2/dss/dss_features.h
@@ -72,13 +72,6 @@ enum dss_feat_id {
/* DSS register field id */
enum dss_feat_reg_field {
- FEAT_REG_FIRHINC,
- FEAT_REG_FIRVINC,
- FEAT_REG_FIFOHIGHTHRESHOLD,
- FEAT_REG_FIFOLOWTHRESHOLD,
- FEAT_REG_FIFOSIZE,
- FEAT_REG_HORIZONTALACCU,
- FEAT_REG_VERTICALACCU,
FEAT_REG_DISPC_CLK_SWITCH,
FEAT_REG_DSIPLL_REGN,
FEAT_REG_DSIPLL_REGM,
--
1.7.10
^ permalink raw reply related
* [PATCH 3/7] OMAPDSS: DISPC: Move DISPC specific dss_params to dispc_features
From: Chandrabhanu Mahapatra @ 2012-11-28 10:53 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Chandrabhanu Mahapatra
In-Reply-To: <cover.1354086150.git.cmahapatra@ti.com>
The DISPC specific dss_param_range are moved from struct omap_dss_features to
corresponding DSS version specific dispc_param_range struct, initialized in
dispc_features thereby enabling local access. The mgr_width_max and
mgr_height_max, members of dispc_features, are also moved to dispc_param_range.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
---
drivers/video/omap2/dss/dispc.c | 80 +++++++++++++++++++++++---------
drivers/video/omap2/dss/dss.h | 4 ++
drivers/video/omap2/dss/dss_features.c | 16 -------
drivers/video/omap2/dss/dss_features.h | 3 --
4 files changed, 63 insertions(+), 40 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 21fc522..0b7388d 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -90,6 +90,14 @@ enum dispc_feat_reg_field {
FEAT_REG_VERTICALACCU,
};
+enum dispc_range_param {
+ FEAT_PARAM_PCD,
+ FEAT_PARAM_DOWNSCALE,
+ FEAT_PARAM_LINEWIDTH,
+ FEAT_PARAM_MGR_WIDTH,
+ FEAT_PARAM_MGR_HEIGHT,
+};
+
struct dispc_features {
u8 sw_start;
u8 fp_start;
@@ -99,8 +107,6 @@ struct dispc_features {
u16 hp_max;
u8 mgr_width_start;
u8 mgr_height_start;
- u16 mgr_width_max;
- u16 mgr_height_max;
int (*calc_scaling) (enum omap_plane plane,
const struct omap_video_timings *mgr_timings,
u16 width, u16 height, u16 out_width, u16 out_height,
@@ -119,6 +125,7 @@ struct dispc_features {
u32 burst_size_unit;
struct register_field *reg_fields;
+ struct param_range *params;
};
#define DISPC_MAX_NR_FIFOS 5
@@ -2185,7 +2192,7 @@ static int dispc_ovl_calc_scaling_24xx(enum omap_plane plane,
u16 in_width, in_height;
int min_factor = min(*decim_x, *decim_y);
const int maxsinglelinewidth - dss_feat_get_param_max(FEAT_PARAM_LINEWIDTH);
+ dispc.feat->params[FEAT_PARAM_LINEWIDTH].max;
*five_taps = false;
@@ -2226,7 +2233,7 @@ static int dispc_ovl_calc_scaling_34xx(enum omap_plane plane,
u16 in_width, in_height;
int min_factor = min(*decim_x, *decim_y);
const int maxsinglelinewidth - dss_feat_get_param_max(FEAT_PARAM_LINEWIDTH);
+ dispc.feat->params[FEAT_PARAM_LINEWIDTH].max;
do {
in_height = DIV_ROUND_UP(height, *decim_y);
@@ -2292,8 +2299,8 @@ static int dispc_ovl_calc_scaling_44xx(enum omap_plane plane,
int decim_x_min = *decim_x;
u16 in_height = DIV_ROUND_UP(height, *decim_y);
const int maxsinglelinewidth - dss_feat_get_param_max(FEAT_PARAM_LINEWIDTH);
- const int maxdownscale = dss_feat_get_param_max(FEAT_PARAM_DOWNSCALE);
+ dispc.feat->params[FEAT_PARAM_LINEWIDTH].max;
+ const int maxdownscale = dispc.feat->params[FEAT_PARAM_DOWNSCALE].max;
if (mem_to_mem) {
in_width_max = out_width * maxdownscale;
@@ -2333,7 +2340,7 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
int *x_predecim, int *y_predecim, u16 pos_x,
enum omap_dss_rotation_type rotation_type, bool mem_to_mem)
{
- const int maxdownscale = dss_feat_get_param_max(FEAT_PARAM_DOWNSCALE);
+ const int maxdownscale = dispc.feat->params[FEAT_PARAM_DOWNSCALE].max;
const int max_decim_limit = 16;
unsigned long core_clk = 0;
int decim_x, decim_y, ret;
@@ -3029,8 +3036,8 @@ void dispc_mgr_set_lcd_config(enum omap_channel channel,
static bool _dispc_mgr_size_ok(u16 width, u16 height)
{
- return width <= dispc.feat->mgr_width_max &&
- height <= dispc.feat->mgr_height_max;
+ return width <= dispc.feat->params[FEAT_PARAM_MGR_WIDTH].max &&
+ height <= dispc.feat->params[FEAT_PARAM_MGR_HEIGHT].max;
}
static bool _dispc_lcd_timings_ok(int hsw, int hfp, int hbp,
@@ -3592,8 +3599,8 @@ void dispc_find_clk_divs(unsigned long req_pck, unsigned long fck,
u16 best_ld, cur_ld;
u16 best_pd, cur_pd;
- pcd_min = dss_feat_get_param_min(FEAT_PARAM_DSS_PCD);
- pcd_max = dss_feat_get_param_max(FEAT_PARAM_DSS_PCD);
+ pcd_min = dispc.feat->params[FEAT_PARAM_PCD].min;
+ pcd_max = dispc.feat->params[FEAT_PARAM_PCD].max;
best_pck = 0;
best_ld = 0;
@@ -4144,6 +4151,42 @@ static struct register_field omap5_dispc_reg_fields[] = {
[FEAT_REG_VERTICALACCU] = { 26, 16 },
};
+static struct param_range omap2_dispc_param_range[] = {
+ [FEAT_PARAM_PCD] = { 2, 255 },
+ [FEAT_PARAM_DOWNSCALE] = { 1, 2 },
+ /*
+ * Assuming the line width buffer to be 768 pixels as OMAP2 DISPC
+ * scaler cannot scale a image with width more than 768.
+ */
+ [FEAT_PARAM_LINEWIDTH] = { 1, 768 },
+ [FEAT_PARAM_MGR_WIDTH] = { 1, 2048 },
+ [FEAT_PARAM_MGR_HEIGHT] = { 1, 2048 },
+};
+
+static struct param_range omap3_dispc_param_range[] = {
+ [FEAT_PARAM_PCD] = { 1, 255 },
+ [FEAT_PARAM_DOWNSCALE] = { 1, 4 },
+ [FEAT_PARAM_LINEWIDTH] = { 1, 1024 },
+ [FEAT_PARAM_MGR_WIDTH] = { 1, 2048 },
+ [FEAT_PARAM_MGR_HEIGHT] = { 1, 2048 },
+};
+
+static struct param_range omap4_dispc_param_range[] = {
+ [FEAT_PARAM_PCD] = { 1, 255 },
+ [FEAT_PARAM_DOWNSCALE] = { 1, 4 },
+ [FEAT_PARAM_LINEWIDTH] = { 1, 2048 },
+ [FEAT_PARAM_MGR_WIDTH] = { 1, 2048 },
+ [FEAT_PARAM_MGR_HEIGHT] = { 1, 2048 },
+};
+
+static struct param_range omap5_dispc_param_range[] = {
+ [FEAT_PARAM_PCD] = { 1, 255 },
+ [FEAT_PARAM_DOWNSCALE] = { 1, 4 },
+ [FEAT_PARAM_LINEWIDTH] = { 1, 2048 },
+ [FEAT_PARAM_MGR_WIDTH] = { 1, 2048 },
+ [FEAT_PARAM_MGR_HEIGHT] = { 1, 2048 },
+};
+
static const struct dispc_features omap24xx_dispc_feats __initconst = {
.sw_start = 5,
.fp_start = 15,
@@ -4153,14 +4196,13 @@ static const struct dispc_features omap24xx_dispc_feats __initconst = {
.hp_max = 256,
.mgr_width_start = 10,
.mgr_height_start = 26,
- .mgr_width_max = 2048,
- .mgr_height_max = 2048,
.calc_scaling = dispc_ovl_calc_scaling_24xx,
.calc_core_clk = calc_core_clk_24xx,
.num_fifos = 3,
.buffer_size_unit = 1,
.burst_size_unit = 8,
.reg_fields = omap2_dispc_reg_fields,
+ .params = omap2_dispc_param_range,
};
static const struct dispc_features omap34xx_rev1_0_dispc_feats __initconst = {
@@ -4172,14 +4214,13 @@ static const struct dispc_features omap34xx_rev1_0_dispc_feats __initconst = {
.hp_max = 256,
.mgr_width_start = 10,
.mgr_height_start = 26,
- .mgr_width_max = 2048,
- .mgr_height_max = 2048,
.calc_scaling = dispc_ovl_calc_scaling_34xx,
.calc_core_clk = calc_core_clk_34xx,
.num_fifos = 3,
.buffer_size_unit = 1,
.burst_size_unit = 8,
.reg_fields = omap3_dispc_reg_fields,
+ .params = omap3_dispc_param_range,
};
static const struct dispc_features omap34xx_rev3_0_dispc_feats __initconst = {
@@ -4191,14 +4232,13 @@ static const struct dispc_features omap34xx_rev3_0_dispc_feats __initconst = {
.hp_max = 4096,
.mgr_width_start = 10,
.mgr_height_start = 26,
- .mgr_width_max = 2048,
- .mgr_height_max = 2048,
.calc_scaling = dispc_ovl_calc_scaling_34xx,
.calc_core_clk = calc_core_clk_34xx,
.num_fifos = 3,
.buffer_size_unit = 1,
.burst_size_unit = 8,
.reg_fields = omap3_dispc_reg_fields,
+ .params = omap3_dispc_param_range,
};
static const struct dispc_features omap44xx_dispc_feats __initconst = {
@@ -4210,8 +4250,6 @@ static const struct dispc_features omap44xx_dispc_feats __initconst = {
.hp_max = 4096,
.mgr_width_start = 10,
.mgr_height_start = 26,
- .mgr_width_max = 2048,
- .mgr_height_max = 2048,
.calc_scaling = dispc_ovl_calc_scaling_44xx,
.calc_core_clk = calc_core_clk_44xx,
.num_fifos = 5,
@@ -4219,6 +4257,7 @@ static const struct dispc_features omap44xx_dispc_feats __initconst = {
.buffer_size_unit = 16,
.burst_size_unit = 16,
.reg_fields = omap4_dispc_reg_fields,
+ .params = omap4_dispc_param_range,
};
static const struct dispc_features omap54xx_dispc_feats __initconst = {
@@ -4230,8 +4269,6 @@ static const struct dispc_features omap54xx_dispc_feats __initconst = {
.hp_max = 4096,
.mgr_width_start = 11,
.mgr_height_start = 27,
- .mgr_width_max = 4096,
- .mgr_height_max = 4096,
.calc_scaling = dispc_ovl_calc_scaling_44xx,
.calc_core_clk = calc_core_clk_44xx,
.num_fifos = 5,
@@ -4239,6 +4276,7 @@ static const struct dispc_features omap54xx_dispc_feats __initconst = {
.buffer_size_unit = 16,
.burst_size_unit = 16,
.reg_fields = omap5_dispc_reg_fields,
+ .params = omap5_dispc_param_range,
};
static int __init dispc_init_features(struct platform_device *pdev)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index aa273d8..da6cf81 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -147,6 +147,10 @@ struct register_field {
u8 start, end;
};
+struct param_range {
+ int min, max;
+};
+
struct dss_lcd_mgr_config {
enum dss_io_pad_mode io_pad_mode;
diff --git a/drivers/video/omap2/dss/dss_features.c b/drivers/video/omap2/dss/dss_features.c
index defdfc0..3a9d1df 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -385,24 +385,16 @@ static const char * const omap5_dss_clk_source_names[] = {
static const struct dss_param_range omap2_dss_param_range[] = {
[FEAT_PARAM_DSS_FCK] = { 0, 173000000 },
- [FEAT_PARAM_DSS_PCD] = { 2, 255 },
[FEAT_PARAM_DSIPLL_REGN] = { 0, 0 },
[FEAT_PARAM_DSIPLL_REGM] = { 0, 0 },
[FEAT_PARAM_DSIPLL_REGM_DISPC] = { 0, 0 },
[FEAT_PARAM_DSIPLL_REGM_DSI] = { 0, 0 },
[FEAT_PARAM_DSIPLL_FINT] = { 0, 0 },
[FEAT_PARAM_DSIPLL_LPDIV] = { 0, 0 },
- [FEAT_PARAM_DOWNSCALE] = { 1, 2 },
- /*
- * Assuming the line width buffer to be 768 pixels as OMAP2 DISPC
- * scaler cannot scale a image with width more than 768.
- */
- [FEAT_PARAM_LINEWIDTH] = { 1, 768 },
};
static const struct dss_param_range omap3_dss_param_range[] = {
[FEAT_PARAM_DSS_FCK] = { 0, 173000000 },
- [FEAT_PARAM_DSS_PCD] = { 1, 255 },
[FEAT_PARAM_DSIPLL_REGN] = { 0, (1 << 7) - 1 },
[FEAT_PARAM_DSIPLL_REGM] = { 0, (1 << 11) - 1 },
[FEAT_PARAM_DSIPLL_REGM_DISPC] = { 0, (1 << 4) - 1 },
@@ -410,13 +402,10 @@ static const struct dss_param_range omap3_dss_param_range[] = {
[FEAT_PARAM_DSIPLL_FINT] = { 750000, 2100000 },
[FEAT_PARAM_DSIPLL_LPDIV] = { 1, (1 << 13) - 1},
[FEAT_PARAM_DSI_FCK] = { 0, 173000000 },
- [FEAT_PARAM_DOWNSCALE] = { 1, 4 },
- [FEAT_PARAM_LINEWIDTH] = { 1, 1024 },
};
static const struct dss_param_range omap4_dss_param_range[] = {
[FEAT_PARAM_DSS_FCK] = { 0, 186000000 },
- [FEAT_PARAM_DSS_PCD] = { 1, 255 },
[FEAT_PARAM_DSIPLL_REGN] = { 0, (1 << 8) - 1 },
[FEAT_PARAM_DSIPLL_REGM] = { 0, (1 << 12) - 1 },
[FEAT_PARAM_DSIPLL_REGM_DISPC] = { 0, (1 << 5) - 1 },
@@ -424,13 +413,10 @@ static const struct dss_param_range omap4_dss_param_range[] = {
[FEAT_PARAM_DSIPLL_FINT] = { 500000, 2500000 },
[FEAT_PARAM_DSIPLL_LPDIV] = { 0, (1 << 13) - 1 },
[FEAT_PARAM_DSI_FCK] = { 0, 170000000 },
- [FEAT_PARAM_DOWNSCALE] = { 1, 4 },
- [FEAT_PARAM_LINEWIDTH] = { 1, 2048 },
};
static const struct dss_param_range omap5_dss_param_range[] = {
[FEAT_PARAM_DSS_FCK] = { 0, 200000000 },
- [FEAT_PARAM_DSS_PCD] = { 1, 255 },
[FEAT_PARAM_DSIPLL_REGN] = { 0, (1 << 8) - 1 },
[FEAT_PARAM_DSIPLL_REGM] = { 0, (1 << 12) - 1 },
[FEAT_PARAM_DSIPLL_REGM_DISPC] = { 0, (1 << 5) - 1 },
@@ -438,8 +424,6 @@ static const struct dss_param_range omap5_dss_param_range[] = {
[FEAT_PARAM_DSIPLL_FINT] = { 500000, 2500000 },
[FEAT_PARAM_DSIPLL_LPDIV] = { 0, (1 << 13) - 1 },
[FEAT_PARAM_DSI_FCK] = { 0, 170000000 },
- [FEAT_PARAM_DOWNSCALE] = { 1, 4 },
- [FEAT_PARAM_LINEWIDTH] = { 1, 2048 },
};
static const enum dss_feat_id omap2_dss_feat_list[] = {
diff --git a/drivers/video/omap2/dss/dss_features.h b/drivers/video/omap2/dss/dss_features.h
index 42a1bd1..40b98ff 100644
--- a/drivers/video/omap2/dss/dss_features.h
+++ b/drivers/video/omap2/dss/dss_features.h
@@ -81,7 +81,6 @@ enum dss_feat_reg_field {
enum dss_range_param {
FEAT_PARAM_DSS_FCK,
- FEAT_PARAM_DSS_PCD,
FEAT_PARAM_DSIPLL_REGN,
FEAT_PARAM_DSIPLL_REGM,
FEAT_PARAM_DSIPLL_REGM_DISPC,
@@ -89,8 +88,6 @@ enum dss_range_param {
FEAT_PARAM_DSIPLL_FINT,
FEAT_PARAM_DSIPLL_LPDIV,
FEAT_PARAM_DSI_FCK,
- FEAT_PARAM_DOWNSCALE,
- FEAT_PARAM_LINEWIDTH,
};
/* DSS Feature Functions */
--
1.7.10
^ permalink raw reply related
* [PATCH 4/7] OMAPDSS: DSI: Move DSI specific reg_fields to dsi_feats
From: Chandrabhanu Mahapatra @ 2012-11-28 10:53 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Chandrabhanu Mahapatra
In-Reply-To: <cover.1354086150.git.cmahapatra@ti.com>
The DSI specific dss_reg_fields are moved to corresponding dsi_reg_fields
initialized in dsi_feats. The dsi_feats structure is initialized as per
corresponding DSS version in dsi_init_features().
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
---
drivers/video/omap2/dss/dsi.c | 119 ++++++++++++++++++++++++++++++--
drivers/video/omap2/dss/dss_features.c | 16 -----
drivers/video/omap2/dss/dss_features.h | 4 --
3 files changed, 113 insertions(+), 26 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index cf32dc7..2d387cb 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -344,6 +344,19 @@ struct dsi_packet_sent_handler_data {
struct completion *completion;
};
+enum dsi_feat_reg_field {
+ FEAT_REG_DSIPLL_REGN,
+ FEAT_REG_DSIPLL_REGM,
+ FEAT_REG_DSIPLL_REGM_DISPC,
+ FEAT_REG_DSIPLL_REGM_DSI,
+};
+
+struct feats {
+ const struct register_field *reg_fields;
+};
+
+static const struct feats *dsi_feat;
+
#ifdef DEBUG
static bool dsi_perf;
module_param(dsi_perf, bool, 0644);
@@ -1645,12 +1658,15 @@ int dsi_pll_set_clock_div(struct platform_device *dsidev,
dss_feat_get_clk_source_name(OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DSI),
cinfo->dsi_pll_hsdiv_dsi_clk);
- dss_feat_get_reg_field(FEAT_REG_DSIPLL_REGN, ®n_start, ®n_end);
- dss_feat_get_reg_field(FEAT_REG_DSIPLL_REGM, ®m_start, ®m_end);
- dss_feat_get_reg_field(FEAT_REG_DSIPLL_REGM_DISPC, ®m_dispc_start,
- ®m_dispc_end);
- dss_feat_get_reg_field(FEAT_REG_DSIPLL_REGM_DSI, ®m_dsi_start,
- ®m_dsi_end);
+ regn_start = dsi_feat->reg_fields[FEAT_REG_DSIPLL_REGN].start;
+ regn_end = dsi_feat->reg_fields[FEAT_REG_DSIPLL_REGN].end;
+ regm_start = dsi_feat->reg_fields[FEAT_REG_DSIPLL_REGM].start;
+ regm_end = dsi_feat->reg_fields[FEAT_REG_DSIPLL_REGM].end;
+ regm_dispc_start + dsi_feat->reg_fields[FEAT_REG_DSIPLL_REGM_DISPC].start;
+ regm_dispc_end = dsi_feat->reg_fields[FEAT_REG_DSIPLL_REGM_DISPC].end;
+ regm_dsi_start = dsi_feat->reg_fields[FEAT_REG_DSIPLL_REGM_DSI].start;
+ regm_dsi_end = dsi_feat->reg_fields[FEAT_REG_DSIPLL_REGM_DSI].end;
/* DSI_PLL_AUTOMODE = manual */
REG_FLD_MOD(dsidev, DSI_PLL_CONTROL, 0, 0, 0);
@@ -5198,6 +5214,93 @@ static void __exit dsi_uninit_output(struct platform_device *dsidev)
dss_unregister_output(out);
}
+static struct register_field omap2_dsi_reg_fields[] = {
+ [FEAT_REG_DSIPLL_REGN] = { 0, 0 },
+ [FEAT_REG_DSIPLL_REGM] = { 0, 0 },
+ [FEAT_REG_DSIPLL_REGM_DISPC] = { 0, 0 },
+ [FEAT_REG_DSIPLL_REGM_DSI] = { 0, 0 },
+};
+
+static struct register_field omap3_dsi_reg_fields[] = {
+ [FEAT_REG_DSIPLL_REGN] = { 7, 1 },
+ [FEAT_REG_DSIPLL_REGM] = { 18, 8 },
+ [FEAT_REG_DSIPLL_REGM_DISPC] = { 22, 19 },
+ [FEAT_REG_DSIPLL_REGM_DSI] = { 26, 23 },
+};
+
+static struct register_field omap4_dsi_reg_fields[] = {
+ [FEAT_REG_DSIPLL_REGN] = { 8, 1 },
+ [FEAT_REG_DSIPLL_REGM] = { 20, 9 },
+ [FEAT_REG_DSIPLL_REGM_DISPC] = { 25, 21 },
+ [FEAT_REG_DSIPLL_REGM_DSI] = { 30, 26 },
+};
+
+static struct register_field omap5_dsi_reg_fields[] = {
+ [FEAT_REG_DSIPLL_REGN] = { 8, 1 },
+ [FEAT_REG_DSIPLL_REGM] = { 20, 9 },
+ [FEAT_REG_DSIPLL_REGM_DISPC] = { 25, 21 },
+ [FEAT_REG_DSIPLL_REGM_DSI] = { 30, 26 },
+};
+
+static const struct feats omap24xx_dsi_feats __initconst = {
+ .reg_fields = omap2_dsi_reg_fields,
+};
+
+static const struct feats omap34xx_dsi_feats __initconst = {
+ .reg_fields = omap3_dsi_reg_fields,
+};
+
+static const struct feats omap44xx_dsi_feats __initconst = {
+ .reg_fields = omap4_dsi_reg_fields,
+};
+
+static const struct feats omap54xx_dsi_feats __initconst = {
+ .reg_fields = omap5_dsi_reg_fields,
+};
+
+static int __init dsi_init_features(struct platform_device *dsidev)
+{
+ const struct feats *src;
+ struct feats *dst;
+
+ dst = devm_kzalloc(&dsidev->dev, sizeof(*dst), GFP_KERNEL);
+ if (!dst) {
+ dev_err(&dsidev->dev, "Failed to allocate DISPC Features\n");
+ return -ENOMEM;
+ }
+
+ switch (omapdss_get_version()) {
+ case OMAPDSS_VER_OMAP24xx:
+ src = &omap24xx_dsi_feats;
+ break;
+
+ case OMAPDSS_VER_OMAP34xx_ES1:
+ case OMAPDSS_VER_OMAP34xx_ES3:
+ case OMAPDSS_VER_OMAP3630:
+ case OMAPDSS_VER_AM35xx:
+ src = &omap34xx_dsi_feats;
+ break;
+
+ case OMAPDSS_VER_OMAP4430_ES1:
+ case OMAPDSS_VER_OMAP4430_ES2:
+ case OMAPDSS_VER_OMAP4:
+ src = &omap44xx_dsi_feats;
+ break;
+
+ case OMAPDSS_VER_OMAP5:
+ src = &omap54xx_dsi_feats;
+ break;
+
+ default:
+ return -ENODEV;
+ }
+
+ memcpy(dst, src, sizeof(*dst));
+ dsi_feat = dst;
+
+ return 0;
+}
+
/* DSI1 HW IP initialisation */
static int __init omap_dsihw_probe(struct platform_device *dsidev)
{
@@ -5206,6 +5309,10 @@ static int __init omap_dsihw_probe(struct platform_device *dsidev)
struct resource *dsi_mem;
struct dsi_data *dsi;
+ r = dsi_init_features(dsidev);
+ if (r)
+ return r;
+
dsi = devm_kzalloc(&dsidev->dev, sizeof(*dsi), GFP_KERNEL);
if (!dsi)
return -ENOMEM;
diff --git a/drivers/video/omap2/dss/dss_features.c b/drivers/video/omap2/dss/dss_features.c
index 3a9d1df..8e6defb 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -61,34 +61,18 @@ static const struct omap_dss_features *omap_current_dss_features;
static const struct dss_reg_field omap2_dss_reg_fields[] = {
[FEAT_REG_DISPC_CLK_SWITCH] = { 0, 0 },
- [FEAT_REG_DSIPLL_REGN] = { 0, 0 },
- [FEAT_REG_DSIPLL_REGM] = { 0, 0 },
- [FEAT_REG_DSIPLL_REGM_DISPC] = { 0, 0 },
- [FEAT_REG_DSIPLL_REGM_DSI] = { 0, 0 },
};
static const struct dss_reg_field omap3_dss_reg_fields[] = {
[FEAT_REG_DISPC_CLK_SWITCH] = { 0, 0 },
- [FEAT_REG_DSIPLL_REGN] = { 7, 1 },
- [FEAT_REG_DSIPLL_REGM] = { 18, 8 },
- [FEAT_REG_DSIPLL_REGM_DISPC] = { 22, 19 },
- [FEAT_REG_DSIPLL_REGM_DSI] = { 26, 23 },
};
static const struct dss_reg_field omap4_dss_reg_fields[] = {
[FEAT_REG_DISPC_CLK_SWITCH] = { 9, 8 },
- [FEAT_REG_DSIPLL_REGN] = { 8, 1 },
- [FEAT_REG_DSIPLL_REGM] = { 20, 9 },
- [FEAT_REG_DSIPLL_REGM_DISPC] = { 25, 21 },
- [FEAT_REG_DSIPLL_REGM_DSI] = { 30, 26 },
};
static const struct dss_reg_field omap5_dss_reg_fields[] = {
[FEAT_REG_DISPC_CLK_SWITCH] = { 9, 7 },
- [FEAT_REG_DSIPLL_REGN] = { 8, 1 },
- [FEAT_REG_DSIPLL_REGM] = { 20, 9 },
- [FEAT_REG_DSIPLL_REGM_DISPC] = { 25, 21 },
- [FEAT_REG_DSIPLL_REGM_DSI] = { 30, 26 },
};
static const enum omap_display_type omap2_dss_supported_displays[] = {
diff --git a/drivers/video/omap2/dss/dss_features.h b/drivers/video/omap2/dss/dss_features.h
index 40b98ff..3e82404 100644
--- a/drivers/video/omap2/dss/dss_features.h
+++ b/drivers/video/omap2/dss/dss_features.h
@@ -73,10 +73,6 @@ enum dss_feat_id {
/* DSS register field id */
enum dss_feat_reg_field {
FEAT_REG_DISPC_CLK_SWITCH,
- FEAT_REG_DSIPLL_REGN,
- FEAT_REG_DSIPLL_REGM,
- FEAT_REG_DSIPLL_REGM_DISPC,
- FEAT_REG_DSIPLL_REGM_DSI,
};
enum dss_range_param {
--
1.7.10
^ permalink raw reply related
* [PATCH 5/7] OMAPDSS: DSI: Move DSI specific dss_params to dsi_feats
From: Chandrabhanu Mahapatra @ 2012-11-28 10:53 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Chandrabhanu Mahapatra
In-Reply-To: <cover.1354086150.git.cmahapatra@ti.com>
The DSI specific dss_param_range are moved from struct omap_dss_features to
corresponding struct dsi_param_range, which is initialized in struct dsi_feats
thereby enabling local access.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
---
drivers/video/omap2/dss/dsi.c | 70 ++++++++++++++++++++++++++++----
drivers/video/omap2/dss/dss_features.c | 27 ------------
drivers/video/omap2/dss/dss_features.h | 7 ----
3 files changed, 62 insertions(+), 42 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 2d387cb..f1f617c 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -351,8 +351,19 @@ enum dsi_feat_reg_field {
FEAT_REG_DSIPLL_REGM_DSI,
};
+enum dsi_range_param {
+ FEAT_PARAM_DSIPLL_REGN,
+ FEAT_PARAM_DSIPLL_REGM,
+ FEAT_PARAM_DSIPLL_REGM_DISPC,
+ FEAT_PARAM_DSIPLL_REGM_DSI,
+ FEAT_PARAM_DSIPLL_FINT,
+ FEAT_PARAM_DSIPLL_LPDIV,
+ FEAT_PARAM_DSI_FCK,
+};
+
struct feats {
const struct register_field *reg_fields;
+ const struct param_range *params;
};
static const struct feats *dsi_feat;
@@ -1518,7 +1529,7 @@ static void dsi_pll_calc_dsi_fck(struct platform_device *dsidev,
{
unsigned long max_dsi_fck;
- max_dsi_fck = dss_feat_get_param_max(FEAT_PARAM_DSI_FCK);
+ max_dsi_fck = dsi_feat->params[FEAT_PARAM_DSI_FCK].max;
cinfo->regm_dsi = DIV_ROUND_UP(cinfo->clkin4ddr, max_dsi_fck);
cinfo->dsi_pll_hsdiv_dsi_clk = cinfo->clkin4ddr / cinfo->regm_dsi;
@@ -5082,14 +5093,14 @@ static void dsi_calc_clock_param_ranges(struct platform_device *dsidev)
{
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
- dsi->regn_max = dss_feat_get_param_max(FEAT_PARAM_DSIPLL_REGN);
- dsi->regm_max = dss_feat_get_param_max(FEAT_PARAM_DSIPLL_REGM);
+ dsi->regn_max = dsi_feat->params[FEAT_PARAM_DSIPLL_REGN].max;
+ dsi->regm_max = dsi_feat->params[FEAT_PARAM_DSIPLL_REGM].max;
dsi->regm_dispc_max - dss_feat_get_param_max(FEAT_PARAM_DSIPLL_REGM_DISPC);
- dsi->regm_dsi_max = dss_feat_get_param_max(FEAT_PARAM_DSIPLL_REGM_DSI);
- dsi->fint_min = dss_feat_get_param_min(FEAT_PARAM_DSIPLL_FINT);
- dsi->fint_max = dss_feat_get_param_max(FEAT_PARAM_DSIPLL_FINT);
- dsi->lpdiv_max = dss_feat_get_param_max(FEAT_PARAM_DSIPLL_LPDIV);
+ dsi_feat->params[FEAT_PARAM_DSIPLL_REGM_DISPC].max;
+ dsi->regm_dsi_max = dsi_feat->params[FEAT_PARAM_DSIPLL_REGM_DSI].max;
+ dsi->fint_min = dsi_feat->params[FEAT_PARAM_DSIPLL_FINT].min;
+ dsi->fint_max = dsi_feat->params[FEAT_PARAM_DSIPLL_FINT].max;
+ dsi->lpdiv_max = dsi_feat->params[FEAT_PARAM_DSIPLL_LPDIV].max;
}
static int dsi_get_clocks(struct platform_device *dsidev)
@@ -5242,20 +5253,63 @@ static struct register_field omap5_dsi_reg_fields[] = {
[FEAT_REG_DSIPLL_REGM_DSI] = { 30, 26 },
};
+static struct param_range omap2_dsi_param_range[] = {
+ [FEAT_PARAM_DSIPLL_REGN] = { 0, 0 },
+ [FEAT_PARAM_DSIPLL_REGM] = { 0, 0 },
+ [FEAT_PARAM_DSIPLL_REGM_DISPC] = { 0, 0 },
+ [FEAT_PARAM_DSIPLL_REGM_DSI] = { 0, 0 },
+ [FEAT_PARAM_DSIPLL_FINT] = { 0, 0 },
+ [FEAT_PARAM_DSIPLL_LPDIV] = { 0, 0 },
+};
+
+static struct param_range omap3_dsi_param_range[] = {
+ [FEAT_PARAM_DSIPLL_REGN] = { 0, (1 << 7) - 1 },
+ [FEAT_PARAM_DSIPLL_REGM] = { 0, (1 << 11) - 1 },
+ [FEAT_PARAM_DSIPLL_REGM_DISPC] = { 0, (1 << 4) - 1 },
+ [FEAT_PARAM_DSIPLL_REGM_DSI] = { 0, (1 << 4) - 1 },
+ [FEAT_PARAM_DSIPLL_FINT] = { 750000, 2100000 },
+ [FEAT_PARAM_DSIPLL_LPDIV] = { 1, (1 << 13) - 1},
+ [FEAT_PARAM_DSI_FCK] = { 0, 173000000 },
+};
+
+static struct param_range omap4_dsi_param_range[] = {
+ [FEAT_PARAM_DSIPLL_REGN] = { 0, (1 << 8) - 1 },
+ [FEAT_PARAM_DSIPLL_REGM] = { 0, (1 << 12) - 1 },
+ [FEAT_PARAM_DSIPLL_REGM_DISPC] = { 0, (1 << 5) - 1 },
+ [FEAT_PARAM_DSIPLL_REGM_DSI] = { 0, (1 << 5) - 1 },
+ [FEAT_PARAM_DSIPLL_FINT] = { 500000, 2500000 },
+ [FEAT_PARAM_DSIPLL_LPDIV] = { 0, (1 << 13) - 1 },
+ [FEAT_PARAM_DSI_FCK] = { 0, 170000000 },
+};
+
+static struct param_range omap5_dsi_param_range[] = {
+ [FEAT_PARAM_DSIPLL_REGN] = { 0, (1 << 8) - 1 },
+ [FEAT_PARAM_DSIPLL_REGM] = { 0, (1 << 12) - 1 },
+ [FEAT_PARAM_DSIPLL_REGM_DISPC] = { 0, (1 << 5) - 1 },
+ [FEAT_PARAM_DSIPLL_REGM_DSI] = { 0, (1 << 5) - 1 },
+ [FEAT_PARAM_DSIPLL_FINT] = { 500000, 2500000 },
+ [FEAT_PARAM_DSIPLL_LPDIV] = { 0, (1 << 13) - 1 },
+ [FEAT_PARAM_DSI_FCK] = { 0, 170000000 },
+};
+
static const struct feats omap24xx_dsi_feats __initconst = {
.reg_fields = omap2_dsi_reg_fields,
+ .params = omap2_dsi_param_range,
};
static const struct feats omap34xx_dsi_feats __initconst = {
.reg_fields = omap3_dsi_reg_fields,
+ .params = omap3_dsi_param_range,
};
static const struct feats omap44xx_dsi_feats __initconst = {
.reg_fields = omap4_dsi_reg_fields,
+ .params = omap4_dsi_param_range,
};
static const struct feats omap54xx_dsi_feats __initconst = {
.reg_fields = omap5_dsi_reg_fields,
+ .params = omap5_dsi_param_range,
};
static int __init dsi_init_features(struct platform_device *dsidev)
diff --git a/drivers/video/omap2/dss/dss_features.c b/drivers/video/omap2/dss/dss_features.c
index 8e6defb..75dddb2 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -369,45 +369,18 @@ static const char * const omap5_dss_clk_source_names[] = {
static const struct dss_param_range omap2_dss_param_range[] = {
[FEAT_PARAM_DSS_FCK] = { 0, 173000000 },
- [FEAT_PARAM_DSIPLL_REGN] = { 0, 0 },
- [FEAT_PARAM_DSIPLL_REGM] = { 0, 0 },
- [FEAT_PARAM_DSIPLL_REGM_DISPC] = { 0, 0 },
- [FEAT_PARAM_DSIPLL_REGM_DSI] = { 0, 0 },
- [FEAT_PARAM_DSIPLL_FINT] = { 0, 0 },
- [FEAT_PARAM_DSIPLL_LPDIV] = { 0, 0 },
};
static const struct dss_param_range omap3_dss_param_range[] = {
[FEAT_PARAM_DSS_FCK] = { 0, 173000000 },
- [FEAT_PARAM_DSIPLL_REGN] = { 0, (1 << 7) - 1 },
- [FEAT_PARAM_DSIPLL_REGM] = { 0, (1 << 11) - 1 },
- [FEAT_PARAM_DSIPLL_REGM_DISPC] = { 0, (1 << 4) - 1 },
- [FEAT_PARAM_DSIPLL_REGM_DSI] = { 0, (1 << 4) - 1 },
- [FEAT_PARAM_DSIPLL_FINT] = { 750000, 2100000 },
- [FEAT_PARAM_DSIPLL_LPDIV] = { 1, (1 << 13) - 1},
- [FEAT_PARAM_DSI_FCK] = { 0, 173000000 },
};
static const struct dss_param_range omap4_dss_param_range[] = {
[FEAT_PARAM_DSS_FCK] = { 0, 186000000 },
- [FEAT_PARAM_DSIPLL_REGN] = { 0, (1 << 8) - 1 },
- [FEAT_PARAM_DSIPLL_REGM] = { 0, (1 << 12) - 1 },
- [FEAT_PARAM_DSIPLL_REGM_DISPC] = { 0, (1 << 5) - 1 },
- [FEAT_PARAM_DSIPLL_REGM_DSI] = { 0, (1 << 5) - 1 },
- [FEAT_PARAM_DSIPLL_FINT] = { 500000, 2500000 },
- [FEAT_PARAM_DSIPLL_LPDIV] = { 0, (1 << 13) - 1 },
- [FEAT_PARAM_DSI_FCK] = { 0, 170000000 },
};
static const struct dss_param_range omap5_dss_param_range[] = {
[FEAT_PARAM_DSS_FCK] = { 0, 200000000 },
- [FEAT_PARAM_DSIPLL_REGN] = { 0, (1 << 8) - 1 },
- [FEAT_PARAM_DSIPLL_REGM] = { 0, (1 << 12) - 1 },
- [FEAT_PARAM_DSIPLL_REGM_DISPC] = { 0, (1 << 5) - 1 },
- [FEAT_PARAM_DSIPLL_REGM_DSI] = { 0, (1 << 5) - 1 },
- [FEAT_PARAM_DSIPLL_FINT] = { 500000, 2500000 },
- [FEAT_PARAM_DSIPLL_LPDIV] = { 0, (1 << 13) - 1 },
- [FEAT_PARAM_DSI_FCK] = { 0, 170000000 },
};
static const enum dss_feat_id omap2_dss_feat_list[] = {
diff --git a/drivers/video/omap2/dss/dss_features.h b/drivers/video/omap2/dss/dss_features.h
index 3e82404..d9f69c7 100644
--- a/drivers/video/omap2/dss/dss_features.h
+++ b/drivers/video/omap2/dss/dss_features.h
@@ -77,13 +77,6 @@ enum dss_feat_reg_field {
enum dss_range_param {
FEAT_PARAM_DSS_FCK,
- FEAT_PARAM_DSIPLL_REGN,
- FEAT_PARAM_DSIPLL_REGM,
- FEAT_PARAM_DSIPLL_REGM_DISPC,
- FEAT_PARAM_DSIPLL_REGM_DSI,
- FEAT_PARAM_DSIPLL_FINT,
- FEAT_PARAM_DSIPLL_LPDIV,
- FEAT_PARAM_DSI_FCK,
};
/* DSS Feature Functions */
--
1.7.10
^ permalink raw reply related
* [PATCH 6/7] OMAPDSS: DSS: Add members fld_dispc_clk_switch and dss_fck_max
From: Chandrabhanu Mahapatra @ 2012-11-28 10:53 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Chandrabhanu Mahapatra
In-Reply-To: <cover.1354086150.git.cmahapatra@ti.com>
The members fld_dispc_clk_switch and dss_fck_max are added to struct
dss_features and are initialized in corresponding dss_feats structure as per DSS
version. The reg_fields and num_reg_fields entries are removed from struct
omap_dss_features as they are no longer referenced.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
---
drivers/video/omap2/dss/dss.c | 22 ++++++++----
drivers/video/omap2/dss/dss_features.c | 57 --------------------------------
drivers/video/omap2/dss/dss_features.h | 6 ----
3 files changed, 16 insertions(+), 69 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 6ca69d5..4d74fbe 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -69,6 +69,8 @@ struct dss_features {
u8 dss_fck_multiplier;
const char *clk_name;
int (*dpi_select_source)(enum omap_channel channel);
+ struct register_field fld_dispc_clk_switch;
+ int dss_fck_max;
};
static struct {
@@ -308,7 +310,6 @@ static void dss_select_dispc_clk_source(enum omap_dss_clk_source clk_src)
{
struct platform_device *dsidev;
int b;
- u8 start, end;
switch (clk_src) {
case OMAP_DSS_CLK_SRC_FCK:
@@ -329,9 +330,8 @@ static void dss_select_dispc_clk_source(enum omap_dss_clk_source clk_src)
return;
}
- dss_feat_get_reg_field(FEAT_REG_DISPC_CLK_SWITCH, &start, &end);
-
- REG_FLD_MOD(DSS_CONTROL, b, start, end); /* DISPC_CLK_SWITCH */
+ REG_FLD_MOD(DSS_CONTROL, b, dss.feat->fld_dispc_clk_switch.start,
+ dss.feat->fld_dispc_clk_switch.end); /* DISPC_CLK_SWITCH */
dss.dispc_clk_source = clk_src;
}
@@ -497,7 +497,7 @@ static int dss_setup_default_clock(void)
if (dss.dpll4_m4_ck = NULL)
return 0;
- max_dss_fck = dss_feat_get_param_max(FEAT_PARAM_DSS_FCK);
+ max_dss_fck = dss.feat->dss_fck_max;
prate = dss_get_dpll4_rate();
@@ -533,7 +533,7 @@ int dss_calc_clock_div(unsigned long req_pck, struct dss_clock_info *dss_cinfo,
prate = dss_get_dpll4_rate();
- max_dss_fck = dss_feat_get_param_max(FEAT_PARAM_DSS_FCK);
+ max_dss_fck = dss.feat->dss_fck_max;
fck = clk_get_rate(dss.dss_clk);
if (req_pck = dss.cache_req_pck && prate = dss.cache_prate &&
@@ -822,6 +822,8 @@ static const struct dss_features omap24xx_dss_feats __initconst = {
.dss_fck_multiplier = 2,
.clk_name = NULL,
.dpi_select_source = &dss_dpi_select_source_omap2_omap3,
+ .fld_dispc_clk_switch = { 0, 0 },
+ .dss_fck_max = 173000000,
};
static const struct dss_features omap34xx_dss_feats __initconst = {
@@ -829,6 +831,8 @@ static const struct dss_features omap34xx_dss_feats __initconst = {
.dss_fck_multiplier = 2,
.clk_name = "dpll4_m4_ck",
.dpi_select_source = &dss_dpi_select_source_omap2_omap3,
+ .fld_dispc_clk_switch = { 0, 0 },
+ .dss_fck_max = 173000000,
};
static const struct dss_features omap3630_dss_feats __initconst = {
@@ -836,6 +840,8 @@ static const struct dss_features omap3630_dss_feats __initconst = {
.dss_fck_multiplier = 1,
.clk_name = "dpll4_m4_ck",
.dpi_select_source = &dss_dpi_select_source_omap2_omap3,
+ .fld_dispc_clk_switch = { 0, 0 },
+ .dss_fck_max = 173000000,
};
static const struct dss_features omap44xx_dss_feats __initconst = {
@@ -843,6 +849,8 @@ static const struct dss_features omap44xx_dss_feats __initconst = {
.dss_fck_multiplier = 1,
.clk_name = "dpll_per_m5x2_ck",
.dpi_select_source = &dss_dpi_select_source_omap4,
+ .fld_dispc_clk_switch = { 9, 8 },
+ .dss_fck_max = 186000000,
};
static const struct dss_features omap54xx_dss_feats __initconst = {
@@ -850,6 +858,8 @@ static const struct dss_features omap54xx_dss_feats __initconst = {
.dss_fck_multiplier = 1,
.clk_name = "dpll_per_h12x2_ck",
.dpi_select_source = &dss_dpi_select_source_omap5,
+ .fld_dispc_clk_switch = { 9, 7 },
+ .dss_fck_max = 200000000,
};
static int __init dss_init_features(struct platform_device *pdev)
diff --git a/drivers/video/omap2/dss/dss_features.c b/drivers/video/omap2/dss/dss_features.c
index 75dddb2..06c04f3 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -27,19 +27,11 @@
#include "dss.h"
#include "dss_features.h"
-/* Defines a generic omap register field */
-struct dss_reg_field {
- u8 start, end;
-};
-
struct dss_param_range {
int min, max;
};
struct omap_dss_features {
- const struct dss_reg_field *reg_fields;
- const int num_reg_fields;
-
const enum dss_feat_id *features;
const int num_features;
@@ -59,22 +51,6 @@ struct omap_dss_features {
/* This struct is assigned to one of the below during initialization */
static const struct omap_dss_features *omap_current_dss_features;
-static const struct dss_reg_field omap2_dss_reg_fields[] = {
- [FEAT_REG_DISPC_CLK_SWITCH] = { 0, 0 },
-};
-
-static const struct dss_reg_field omap3_dss_reg_fields[] = {
- [FEAT_REG_DISPC_CLK_SWITCH] = { 0, 0 },
-};
-
-static const struct dss_reg_field omap4_dss_reg_fields[] = {
- [FEAT_REG_DISPC_CLK_SWITCH] = { 9, 8 },
-};
-
-static const struct dss_reg_field omap5_dss_reg_fields[] = {
- [FEAT_REG_DISPC_CLK_SWITCH] = { 9, 7 },
-};
-
static const enum omap_display_type omap2_dss_supported_displays[] = {
/* OMAP_DSS_CHANNEL_LCD */
OMAP_DISPLAY_TYPE_DPI | OMAP_DISPLAY_TYPE_DBI,
@@ -527,9 +503,6 @@ static const enum dss_feat_id omap5_dss_feat_list[] = {
/* OMAP2 DSS Features */
static const struct omap_dss_features omap2_dss_features = {
- .reg_fields = omap2_dss_reg_fields,
- .num_reg_fields = ARRAY_SIZE(omap2_dss_reg_fields),
-
.features = omap2_dss_feat_list,
.num_features = ARRAY_SIZE(omap2_dss_feat_list),
@@ -546,9 +519,6 @@ static const struct omap_dss_features omap2_dss_features = {
/* OMAP3 DSS Features */
static const struct omap_dss_features omap3430_dss_features = {
- .reg_fields = omap3_dss_reg_fields,
- .num_reg_fields = ARRAY_SIZE(omap3_dss_reg_fields),
-
.features = omap3430_dss_feat_list,
.num_features = ARRAY_SIZE(omap3430_dss_feat_list),
@@ -568,9 +538,6 @@ static const struct omap_dss_features omap3430_dss_features = {
* vdds_dsi regulator.
*/
static const struct omap_dss_features am35xx_dss_features = {
- .reg_fields = omap3_dss_reg_fields,
- .num_reg_fields = ARRAY_SIZE(omap3_dss_reg_fields),
-
.features = am35xx_dss_feat_list,
.num_features = ARRAY_SIZE(am35xx_dss_feat_list),
@@ -586,9 +553,6 @@ static const struct omap_dss_features am35xx_dss_features = {
};
static const struct omap_dss_features omap3630_dss_features = {
- .reg_fields = omap3_dss_reg_fields,
- .num_reg_fields = ARRAY_SIZE(omap3_dss_reg_fields),
-
.features = omap3630_dss_feat_list,
.num_features = ARRAY_SIZE(omap3630_dss_feat_list),
@@ -606,9 +570,6 @@ static const struct omap_dss_features omap3630_dss_features = {
/* OMAP4 DSS Features */
/* For OMAP4430 ES 1.0 revision */
static const struct omap_dss_features omap4430_es1_0_dss_features = {
- .reg_fields = omap4_dss_reg_fields,
- .num_reg_fields = ARRAY_SIZE(omap4_dss_reg_fields),
-
.features = omap4430_es1_0_dss_feat_list,
.num_features = ARRAY_SIZE(omap4430_es1_0_dss_feat_list),
@@ -626,9 +587,6 @@ static const struct omap_dss_features omap4430_es1_0_dss_features = {
/* For OMAP4430 ES 2.0, 2.1 and 2.2 revisions */
static const struct omap_dss_features omap4430_es2_0_1_2_dss_features = {
- .reg_fields = omap4_dss_reg_fields,
- .num_reg_fields = ARRAY_SIZE(omap4_dss_reg_fields),
-
.features = omap4430_es2_0_1_2_dss_feat_list,
.num_features = ARRAY_SIZE(omap4430_es2_0_1_2_dss_feat_list),
@@ -646,9 +604,6 @@ static const struct omap_dss_features omap4430_es2_0_1_2_dss_features = {
/* For all the other OMAP4 versions */
static const struct omap_dss_features omap4_dss_features = {
- .reg_fields = omap4_dss_reg_fields,
- .num_reg_fields = ARRAY_SIZE(omap4_dss_reg_fields),
-
.features = omap4_dss_feat_list,
.num_features = ARRAY_SIZE(omap4_dss_feat_list),
@@ -666,9 +621,6 @@ static const struct omap_dss_features omap4_dss_features = {
/* OMAP5 DSS Features */
static const struct omap_dss_features omap5_dss_features = {
- .reg_fields = omap5_dss_reg_fields,
- .num_reg_fields = ARRAY_SIZE(omap5_dss_reg_fields),
-
.features = omap5_dss_feat_list,
.num_features = ARRAY_SIZE(omap5_dss_feat_list),
@@ -801,15 +753,6 @@ bool dss_has_feature(enum dss_feat_id id)
return false;
}
-void dss_feat_get_reg_field(enum dss_feat_reg_field id, u8 *start, u8 *end)
-{
- if (id >= omap_current_dss_features->num_reg_fields)
- BUG();
-
- *start = omap_current_dss_features->reg_fields[id].start;
- *end = omap_current_dss_features->reg_fields[id].end;
-}
-
bool dss_feat_rotation_type_supported(enum omap_dss_rotation_type rot_type)
{
return omap_current_dss_features->supported_rotation_types & rot_type;
diff --git a/drivers/video/omap2/dss/dss_features.h b/drivers/video/omap2/dss/dss_features.h
index d9f69c7..97aecf9 100644
--- a/drivers/video/omap2/dss/dss_features.h
+++ b/drivers/video/omap2/dss/dss_features.h
@@ -70,11 +70,6 @@ enum dss_feat_id {
FEAT_DSI_PHY_DCC,
};
-/* DSS register field id */
-enum dss_feat_reg_field {
- FEAT_REG_DISPC_CLK_SWITCH,
-};
-
enum dss_range_param {
FEAT_PARAM_DSS_FCK,
};
@@ -96,7 +91,6 @@ const char *dss_feat_get_clk_source_name(enum omap_dss_clk_source id);
bool dss_feat_rotation_type_supported(enum omap_dss_rotation_type rot_type);
bool dss_has_feature(enum dss_feat_id id);
-void dss_feat_get_reg_field(enum dss_feat_reg_field id, u8 *start, u8 *end);
void dss_features_init(enum omapdss_version version);
#if defined(CONFIG_OMAP4_DSS_HDMI)
void dss_init_hdmi_ip_ops(struct hdmi_ip_data *ip_data,
--
1.7.10
^ permalink raw reply related
* [PATCH 7/7] OMAPDSS: DSI: Add FEAT_PARAM_DSS_FCK
From: Chandrabhanu Mahapatra @ 2012-11-28 10:53 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Chandrabhanu Mahapatra
In-Reply-To: <cover.1354086150.git.cmahapatra@ti.com>
The FEAT_PARAM_DSS_FCK is added and initialized in corresponding DSS Version
specific struct dsi_param_range. As, the struct dss_param_range is no longer
used all its references are thereby removed from omap_dss_features.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
---
drivers/video/omap2/dss/dsi.c | 9 ++++++--
drivers/video/omap2/dss/dss_features.c | 39 --------------------------------
drivers/video/omap2/dss/dss_features.h | 6 -----
3 files changed, 7 insertions(+), 47 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index f1f617c..3e0e9d7 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -352,6 +352,7 @@ enum dsi_feat_reg_field {
};
enum dsi_range_param {
+ FEAT_PARAM_DSS_FCK,
FEAT_PARAM_DSIPLL_REGN,
FEAT_PARAM_DSIPLL_REGM,
FEAT_PARAM_DSIPLL_REGM_DISPC,
@@ -1353,7 +1354,7 @@ int dsi_pll_calc_clock_div_pck(struct platform_device *dsidev,
dss_sys_clk = clk_get_rate(dsi->sys_clk);
- max_dss_fck = dss_feat_get_param_max(FEAT_PARAM_DSS_FCK);
+ max_dss_fck = dsi_feat->params[FEAT_PARAM_DSS_FCK].max;
if (req_pck = dsi->cache_req_pck &&
dsi->cache_cinfo.clkin = dss_sys_clk) {
@@ -1547,7 +1548,7 @@ static int dsi_pll_calc_dispc_fck(struct platform_device *dsidev,
struct dispc_clock_info best_dispc;
bool match;
- max_dss_fck = dss_feat_get_param_max(FEAT_PARAM_DSS_FCK);
+ max_dss_fck = dsi_feat->params[FEAT_PARAM_DSS_FCK].max;
min_fck_per_pck = CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK;
@@ -5254,6 +5255,7 @@ static struct register_field omap5_dsi_reg_fields[] = {
};
static struct param_range omap2_dsi_param_range[] = {
+ [FEAT_PARAM_DSS_FCK] = { 0, 173000000 },
[FEAT_PARAM_DSIPLL_REGN] = { 0, 0 },
[FEAT_PARAM_DSIPLL_REGM] = { 0, 0 },
[FEAT_PARAM_DSIPLL_REGM_DISPC] = { 0, 0 },
@@ -5263,6 +5265,7 @@ static struct param_range omap2_dsi_param_range[] = {
};
static struct param_range omap3_dsi_param_range[] = {
+ [FEAT_PARAM_DSS_FCK] = { 0, 173000000 },
[FEAT_PARAM_DSIPLL_REGN] = { 0, (1 << 7) - 1 },
[FEAT_PARAM_DSIPLL_REGM] = { 0, (1 << 11) - 1 },
[FEAT_PARAM_DSIPLL_REGM_DISPC] = { 0, (1 << 4) - 1 },
@@ -5273,6 +5276,7 @@ static struct param_range omap3_dsi_param_range[] = {
};
static struct param_range omap4_dsi_param_range[] = {
+ [FEAT_PARAM_DSS_FCK] = { 0, 186000000 },
[FEAT_PARAM_DSIPLL_REGN] = { 0, (1 << 8) - 1 },
[FEAT_PARAM_DSIPLL_REGM] = { 0, (1 << 12) - 1 },
[FEAT_PARAM_DSIPLL_REGM_DISPC] = { 0, (1 << 5) - 1 },
@@ -5283,6 +5287,7 @@ static struct param_range omap4_dsi_param_range[] = {
};
static struct param_range omap5_dsi_param_range[] = {
+ [FEAT_PARAM_DSS_FCK] = { 0, 200000000 },
[FEAT_PARAM_DSIPLL_REGN] = { 0, (1 << 8) - 1 },
[FEAT_PARAM_DSIPLL_REGM] = { 0, (1 << 12) - 1 },
[FEAT_PARAM_DSIPLL_REGM_DISPC] = { 0, (1 << 5) - 1 },
diff --git a/drivers/video/omap2/dss/dss_features.c b/drivers/video/omap2/dss/dss_features.c
index 06c04f3..e7fca28 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -27,10 +27,6 @@
#include "dss.h"
#include "dss_features.h"
-struct dss_param_range {
- int min, max;
-};
-
struct omap_dss_features {
const enum dss_feat_id *features;
const int num_features;
@@ -43,7 +39,6 @@ struct omap_dss_features {
const enum omap_color_mode *supported_color_modes;
const enum omap_overlay_caps *overlay_caps;
const char * const *clksrc_names;
- const struct dss_param_range *dss_params;
const enum omap_dss_rotation_type supported_rotation_types;
};
@@ -343,22 +338,6 @@ static const char * const omap5_dss_clk_source_names[] = {
[OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DSI] = "DPLL_DSI1_C_CLK2",
};
-static const struct dss_param_range omap2_dss_param_range[] = {
- [FEAT_PARAM_DSS_FCK] = { 0, 173000000 },
-};
-
-static const struct dss_param_range omap3_dss_param_range[] = {
- [FEAT_PARAM_DSS_FCK] = { 0, 173000000 },
-};
-
-static const struct dss_param_range omap4_dss_param_range[] = {
- [FEAT_PARAM_DSS_FCK] = { 0, 186000000 },
-};
-
-static const struct dss_param_range omap5_dss_param_range[] = {
- [FEAT_PARAM_DSS_FCK] = { 0, 200000000 },
-};
-
static const enum dss_feat_id omap2_dss_feat_list[] = {
FEAT_LCDENABLEPOL,
FEAT_LCDENABLESIGNAL,
@@ -513,7 +492,6 @@ static const struct omap_dss_features omap2_dss_features = {
.supported_color_modes = omap2_dss_supported_color_modes,
.overlay_caps = omap2_dss_overlay_caps,
.clksrc_names = omap2_dss_clk_source_names,
- .dss_params = omap2_dss_param_range,
.supported_rotation_types = OMAP_DSS_ROT_DMA | OMAP_DSS_ROT_VRFB,
};
@@ -529,7 +507,6 @@ static const struct omap_dss_features omap3430_dss_features = {
.supported_color_modes = omap3_dss_supported_color_modes,
.overlay_caps = omap3430_dss_overlay_caps,
.clksrc_names = omap3_dss_clk_source_names,
- .dss_params = omap3_dss_param_range,
.supported_rotation_types = OMAP_DSS_ROT_DMA | OMAP_DSS_ROT_VRFB,
};
@@ -548,7 +525,6 @@ static const struct omap_dss_features am35xx_dss_features = {
.supported_color_modes = omap3_dss_supported_color_modes,
.overlay_caps = omap3430_dss_overlay_caps,
.clksrc_names = omap3_dss_clk_source_names,
- .dss_params = omap3_dss_param_range,
.supported_rotation_types = OMAP_DSS_ROT_DMA | OMAP_DSS_ROT_VRFB,
};
@@ -563,7 +539,6 @@ static const struct omap_dss_features omap3630_dss_features = {
.supported_color_modes = omap3_dss_supported_color_modes,
.overlay_caps = omap3630_dss_overlay_caps,
.clksrc_names = omap3_dss_clk_source_names,
- .dss_params = omap3_dss_param_range,
.supported_rotation_types = OMAP_DSS_ROT_DMA | OMAP_DSS_ROT_VRFB,
};
@@ -581,7 +556,6 @@ static const struct omap_dss_features omap4430_es1_0_dss_features = {
.supported_color_modes = omap4_dss_supported_color_modes,
.overlay_caps = omap4_dss_overlay_caps,
.clksrc_names = omap4_dss_clk_source_names,
- .dss_params = omap4_dss_param_range,
.supported_rotation_types = OMAP_DSS_ROT_DMA | OMAP_DSS_ROT_TILER,
};
@@ -598,7 +572,6 @@ static const struct omap_dss_features omap4430_es2_0_1_2_dss_features = {
.supported_color_modes = omap4_dss_supported_color_modes,
.overlay_caps = omap4_dss_overlay_caps,
.clksrc_names = omap4_dss_clk_source_names,
- .dss_params = omap4_dss_param_range,
.supported_rotation_types = OMAP_DSS_ROT_DMA | OMAP_DSS_ROT_TILER,
};
@@ -615,7 +588,6 @@ static const struct omap_dss_features omap4_dss_features = {
.supported_color_modes = omap4_dss_supported_color_modes,
.overlay_caps = omap4_dss_overlay_caps,
.clksrc_names = omap4_dss_clk_source_names,
- .dss_params = omap4_dss_param_range,
.supported_rotation_types = OMAP_DSS_ROT_DMA | OMAP_DSS_ROT_TILER,
};
@@ -631,7 +603,6 @@ static const struct omap_dss_features omap5_dss_features = {
.supported_color_modes = omap4_dss_supported_color_modes,
.overlay_caps = omap4_dss_overlay_caps,
.clksrc_names = omap5_dss_clk_source_names,
- .dss_params = omap5_dss_param_range,
.supported_rotation_types = OMAP_DSS_ROT_DMA | OMAP_DSS_ROT_TILER,
};
@@ -696,16 +667,6 @@ int dss_feat_get_num_wbs(void)
return omap_current_dss_features->num_wbs;
}
-unsigned long dss_feat_get_param_min(enum dss_range_param param)
-{
- return omap_current_dss_features->dss_params[param].min;
-}
-
-unsigned long dss_feat_get_param_max(enum dss_range_param param)
-{
- return omap_current_dss_features->dss_params[param].max;
-}
-
enum omap_display_type dss_feat_get_supported_displays(enum omap_channel channel)
{
return omap_current_dss_features->supported_displays[channel];
diff --git a/drivers/video/omap2/dss/dss_features.h b/drivers/video/omap2/dss/dss_features.h
index 97aecf9..0b84484 100644
--- a/drivers/video/omap2/dss/dss_features.h
+++ b/drivers/video/omap2/dss/dss_features.h
@@ -70,16 +70,10 @@ enum dss_feat_id {
FEAT_DSI_PHY_DCC,
};
-enum dss_range_param {
- FEAT_PARAM_DSS_FCK,
-};
-
/* DSS Feature Functions */
int dss_feat_get_num_mgrs(void);
int dss_feat_get_num_ovls(void);
int dss_feat_get_num_wbs(void);
-unsigned long dss_feat_get_param_min(enum dss_range_param param);
-unsigned long dss_feat_get_param_max(enum dss_range_param param);
enum omap_display_type dss_feat_get_supported_displays(enum omap_channel channel);
enum omap_dss_output_id dss_feat_get_supported_outputs(enum omap_channel channel);
enum omap_color_mode dss_feat_get_supported_color_modes(enum omap_plane plane);
--
1.7.10
^ permalink raw reply related
* Re: [GIT PULL] Exynos DP for v3.8
From: Rob Herring @ 2012-11-28 19:57 UTC (permalink / raw)
To: jg1.han-Sze3O3UU22JBDgjK7y7TUQ
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Kukjin Kim,
FlorianSchandinat-Mmb7MZpHnFY@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, Tomi Valkeinen,
Sylwester Nawrocki
In-Reply-To: <23089985.76751354060752557.JavaMail.weblogic@epml26>
On 11/27/2012 05:59 PM, Jingoo Han wrote:
> On Tuesday, November 27, 2012 6:58 PM, Tomi Valkeinen wrote
>>
>> On 2012-11-23 08:37, Jingoo Han wrote:
>>> Hi Tomi,
>>>
>>> Thank you for taking care of pull requests for the v3.8 merge window.
>>> These patches have been submitted for more than one month,
>>> and tested with Exynos5250.
>>>
>>> The following changes since commit f4a75d2eb7b1e2206094b901be09adb31ba63681:
>>>
>>> Linux 3.7-rc6 (Fri Nov 16 17:42:40 2012 -0800)
>>>
>>> are available in the git repository at:
>>> git://github.com/jingoo/linux.git exynos-dp-next
>>>
>>> ----------------------------------------------------------------
>>> 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.
>>> ----------------------------------------------------------------
>>>
>>> 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
>>>
>>> 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
>>>
>>> .../devicetree/bindings/video/exynos_dp.txt | 80 +++
>>> 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 +-
>>> 5 files changed, 583 insertions(+), 295 deletions(-)
>>> create mode 100644 Documentation/devicetree/bindings/video/exynos_dp.txt
>>
>> Has the DT bindings been reviewed by the device tree people? It would
>> good to have an ack from them.
>
> CC'ed device tree mailing-list, Grant Likely, Rob Herring, Kukjin Kim, Sylwester Nawrocki.
>
> Hi Tomi,
>
> The DT binding has been posted with device tree mailing-list
> (devicetree-discuss@lists.ozlabs.org) for more than 2 months.
> Last patch V8 was posted 1 month ago. However, there is no objection.
> (http://www.spinics.net/lists/linux-fbdev/msg08354.html)
>
> Also, Samsung people already reviewed it.
> In my opinion, there is no need to get Ack from the device tree people.
Grant and I can't possibly review every binding for every device of
every subsystem.
While I think there is possibility to make this more common across
platforms, I don't have any major issues with the binding, so:
Acked-by: Rob Herring <rob.herring@calxeda.com>
Rob
> Grant, Rob: if you have another opinion, please let me know kindly.
>
> Best regards,
> Jingoo Han
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
^ permalink raw reply
* [PATCH] backlight: corgi_lcd: Fix WARN_ON() when calling corgi_bl_set_intensity.
From: dromede @ 2012-11-28 21:46 UTC (permalink / raw)
To: linux-arm-kernel
From: Marko Katic <dromede.gmail.com>
Signed-off-by: Marko Katic <dromede@gmail.com>
---
drivers/video/backlight/corgi_lcd.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/corgi_lcd.c b/drivers/video/backlight/corgi_lcd.c
index c781768..8b002d7 100644
--- a/drivers/video/backlight/corgi_lcd.c
+++ b/drivers/video/backlight/corgi_lcd.c
@@ -409,10 +409,10 @@ static int corgi_bl_set_intensity(struct corgi_lcd *lcd, int intensity)
cont = !!(intensity & 0x20) ^ lcd->gpio_backlight_cont_inverted;
if (gpio_is_valid(lcd->gpio_backlight_cont))
- gpio_set_value(lcd->gpio_backlight_cont, cont);
+ gpio_set_value_cansleep(lcd->gpio_backlight_cont, cont);
if (gpio_is_valid(lcd->gpio_backlight_on))
- gpio_set_value(lcd->gpio_backlight_on, intensity);
+ gpio_set_value_cansleep(lcd->gpio_backlight_on, intensity);
if (lcd->kick_battery)
lcd->kick_battery();
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH] backlight: corgi_lcd: Fix WARN_ON() when calling corgi_bl_set_intensity.
From: Jingoo Han @ 2012-11-29 5:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1354139201-12834-1-git-send-email-dromede@gmail.com>
On Thursday, November 29, 2012 6:47 AM, Marko Katic wrote
> Subject: [PATCH] backlight: corgi_lcd: Fix WARN_ON() when calling corgi_bl_set_intensity.
CC'ed Andrew Morton.
Hi Marko Katic,
The commit subject and commit message are not clear.
How about using subject as below?
backlight: corgi_lcd: use gpio_set_value_cansleep()
In addition, 'Fix WARN_ON() when calling corgi_bl_set_intensity'
would be the reason why you submit this patch.
Please make the commit message more detail.
Also, I have a question on gpio driver.
In order to trigger WARN_ON(chip->can_sleep), 'can_sleep' should be
set as 1. However, I cannot find 'can_sleep = 1' in the PXA gpio driver.
What gpio driver do you use to test corgi_lcd driver?
Best regards,
Jingoo Han
>
> From: Marko Katic <dromede.gmail.com>
>
>
> Signed-off-by: Marko Katic <dromede@gmail.com>
> ---
> drivers/video/backlight/corgi_lcd.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/backlight/corgi_lcd.c b/drivers/video/backlight/corgi_lcd.c
> index c781768..8b002d7 100644
> --- a/drivers/video/backlight/corgi_lcd.c
> +++ b/drivers/video/backlight/corgi_lcd.c
> @@ -409,10 +409,10 @@ static int corgi_bl_set_intensity(struct corgi_lcd *lcd, int intensity)
> cont = !!(intensity & 0x20) ^ lcd->gpio_backlight_cont_inverted;
>
> if (gpio_is_valid(lcd->gpio_backlight_cont))
> - gpio_set_value(lcd->gpio_backlight_cont, cont);
> + gpio_set_value_cansleep(lcd->gpio_backlight_cont, cont);
>
> if (gpio_is_valid(lcd->gpio_backlight_on))
> - gpio_set_value(lcd->gpio_backlight_on, intensity);
> + gpio_set_value_cansleep(lcd->gpio_backlight_on, intensity);
>
> if (lcd->kick_battery)
> lcd->kick_battery();
> --
> 1.7.4.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH v2 0/2] da8xx-fb: LCDC driver cleanup
From: Manjunathappa, Prakash @ 2012-11-29 5:37 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1350363196-9340-1-git-send-email-prakash.pm@ti.com>
Hi,
On Fri, Nov 23, 2012 at 10:00:59, Manjunathappa, Prakash wrote:
> Hi Tomi,
>
> On Tue, Oct 16, 2012 at 10:23:14, Manjunathappa, Prakash wrote:
> > This patch series clean up driver as it is necessary for DT migration.
> >
> > Manjunathappa, Prakash (2):
> > da8xx-fb: adopt fb_videomode data for panel information
> > da8xx-fb: cleanup LCDC configurations
> >
>
> There are no review comment on this, Could you please accept this series?
>
I do not have external branch maintained, changes are minor and driver specific.
Please let me know If resending this series helps you to pull in?
Thanks,
Prakash
>
> > arch/arm/mach-davinci/devices-da8xx.c | 22 +----
> > drivers/video/da8xx-fb.c | 167 +++++++++++++++------------------
> > include/video/da8xx-fb.h | 25 +----
> > 3 files changed, 79 insertions(+), 135 deletions(-)
> >
> >
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source@linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
^ permalink raw reply
* Re: [GIT PULL] Exynos DP for v3.8
From: Jingoo Han @ 2012-11-29 6:38 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <28517517.77811353652672706.JavaMail.weblogic@epml06>
T24gVGh1cnNkYXksIE5vdmVtYmVyIDI5LCAyMDEyIDQ6NTggQU0sIFJvYiBIZXJyaW5nIHdyb3Rl
DQo+IE9uIDExLzI3LzIwMTIgMDU6NTkgUE0sIEppbmdvbyBIYW4gd3JvdGU6DQo+ID4gT24gVHVl
c2RheSwgTm92ZW1iZXIgMjcsIDIwMTIgNjo1OCBQTSwgVG9taSBWYWxrZWluZW4gd3JvdGUNCj4g
Pj4NCj4gPj4gT24gMjAxMi0xMS0yMyAwODozNywgSmluZ29vIEhhbiB3cm90ZToNCj4gPj4+IEhp
IFRvbWksDQo+ID4+Pg0KPiA+Pj4gVGhhbmsgeW91IGZvciB0YWtpbmcgY2FyZSBvZiBwdWxsIHJl
cXVlc3RzIGZvciB0aGUgdjMuOCBtZXJnZSB3aW5kb3cuDQo+ID4+PiBUaGVzZSBwYXRjaGVzIGhh
dmUgYmVlbiBzdWJtaXR0ZWQgZm9yIG1vcmUgdGhhbiBvbmUgbW9udGgsDQo+ID4+PiBhbmQgdGVz
dGVkIHdpdGggRXh5bm9zNTI1MC4NCj4gPj4+DQo+ID4+PiBUaGUgZm9sbG93aW5nIGNoYW5nZXMg
c2luY2UgY29tbWl0IGY0YTc1ZDJlYjdiMWUyMjA2MDk0YjkwMWJlMDlhZGIzMWJhNjM2ODE6DQo+
ID4+Pg0KPiA+Pj4gICBMaW51eCAzLjctcmM2IChGcmkgTm92IDE2IDE3OjQyOjQwIDIwMTIgLTA4
MDApDQo+ID4+Pg0KPiA+Pj4gYXJlIGF2YWlsYWJsZSBpbiB0aGUgZ2l0IHJlcG9zaXRvcnkgYXQ6
DQo+ID4+PiAgIGdpdDovL2dpdGh1Yi5jb20vamluZ29vL2xpbnV4LmdpdCBleHlub3MtZHAtbmV4
dA0KPiA+Pj4NCj4gPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+IEV4eW5vcyBEUCBjaGFuZ2VzIGZvciB0aGUg
My44IG1lcmdlIHdpbmRvdy4NCj4gPj4+DQo+ID4+PiAtIERldmljZSBUcmVlIHN1cHBvcnQgZm9y
IFNhbXN1bmcgRXh5bm9zIERQDQo+ID4+PiAtIFNXIExpbmsgdHJhaW5pbmcgaXMgY2xlYW5lZCB1
cC4NCj4gPj4+IC0gSFBEIGludGVycnVwdCBpcyBzdXBwb3J0ZWQuDQo+ID4+PiAtLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+
ID4+Pg0KPiA+Pj4gQWpheSBLdW1hciAoNSk6DQo+ID4+PiAgICAgICB2aWRlbzogZXh5bm9zX2Rw
OiBBZGQgZGV2aWNlIHRyZWUgc3VwcG9ydCB0byBEUCBkcml2ZXINCj4gPj4+ICAgICAgIHZpZGVv
OiBleHlub3NfZHA6IGRldmljZSB0cmVlIGRvY3VtZW50YXRpb24NCj4gPj4+ICAgICAgIHZpZGVv
OiBleHlub3NfZHA6IFJlc2V0IGFuZCBpbml0aWFsaXplIERQIGJlZm9yZSByZXF1ZXN0aW5nIGly
cQ0KPiA+Pj4gICAgICAgdmlkZW86IGV4eW5vc19kcDogRml4IGluY29ycmVjdCBzZXR0aW5nIGZv
ciBJTlRfQ1RMDQo+ID4+PiAgICAgICB2aWRlbzogZXh5bm9zX2RwOiByZW1vdmUgcmVkdW5kYW50
IHBhcmFtZXRlcnMNCj4gPj4+DQo+ID4+PiBTZWFuIFBhdWwgKDgpOg0KPiA+Pj4gICAgICAgdmlk
ZW86IGV4eW5vc19kcDogQ2hlY2sgRFBDRCByZXR1cm4gY29kZXMNCj4gPj4+ICAgICAgIHZpZGVv
OiBleHlub3NfZHA6IENsZWFuIHVwIFNXIGxpbmsgdHJhaW5pbmcNCj4gPj4+ICAgICAgIHZpZGVv
OiBleHlub3NfZHA6IEdldCBwbGwgbG9jayBiZWZvcmUgcGF0dGVybiBzZXQNCj4gPj4+ICAgICAg
IHZpZGVvOiBleHlub3NfZHA6IEltcHJvdmUgRURJRCBlcnJvciBoYW5kbGluZw0KPiA+Pj4gICAg
ICAgdmlkZW86IGV4eW5vc19kcDogRml4IGJ1ZyB3aGVuIGNoZWNraW5nIGRwLT5pcnENCj4gPj4+
ICAgICAgIHZpZGVvOiBleHlub3NfZHA6IFJlbW92ZSBzaW5rIGNvbnRyb2wgdG8gRDANCj4gPj4+
ICAgICAgIHZpZGVvOiBleHlub3NfZHA6IE1vdmUgaG90cGx1ZyBpbnRvIGEgd29ya3F1ZXVlDQo+
ID4+PiAgICAgICB2aWRlbzogZXh5bm9zX2RwOiBFbmFibGUgaG90cGx1ZyBpbnRlcnJ1cHRzDQo+
ID4+Pg0KPiA+Pj4gIC4uLi9kZXZpY2V0cmVlL2JpbmRpbmdzL3ZpZGVvL2V4eW5vc19kcC50eHQg
ICAgICAgIHwgICA4MCArKysNCj4gPj4+ICBkcml2ZXJzL3ZpZGVvL2V4eW5vcy9leHlub3NfZHBf
Y29yZS5jICAgICAgICAgICAgICB8ICA2OTcgKysrKysrKysrKysrLS0tLS0tLS0NCj4gPj4+ICBk
cml2ZXJzL3ZpZGVvL2V4eW5vcy9leHlub3NfZHBfY29yZS5oICAgICAgICAgICAgICB8ICAgMjEg
Ky0NCj4gPj4+ICBkcml2ZXJzL3ZpZGVvL2V4eW5vcy9leHlub3NfZHBfcmVnLmMgICAgICAgICAg
ICAgICB8ICAgNzcgKystDQo+ID4+PiAgZHJpdmVycy92aWRlby9leHlub3MvZXh5bm9zX2RwX3Jl
Zy5oICAgICAgICAgICAgICAgfCAgICAzICstDQo+ID4+PiAgNSBmaWxlcyBjaGFuZ2VkLCA1ODMg
aW5zZXJ0aW9ucygrKSwgMjk1IGRlbGV0aW9ucygtKQ0KPiA+Pj4gIGNyZWF0ZSBtb2RlIDEwMDY0
NCBEb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvdmlkZW8vZXh5bm9zX2RwLnR4dA0K
PiA+Pg0KPiA+PiBIYXMgdGhlIERUIGJpbmRpbmdzIGJlZW4gcmV2aWV3ZWQgYnkgdGhlIGRldmlj
ZSB0cmVlIHBlb3BsZT8gSXQgd291bGQNCj4gPj4gZ29vZCB0byBoYXZlIGFuIGFjayBmcm9tIHRo
ZW0uDQo+ID4NCj4gPiBDQydlZCBkZXZpY2UgdHJlZSBtYWlsaW5nLWxpc3QsIEdyYW50IExpa2Vs
eSwgUm9iIEhlcnJpbmcsIEt1a2ppbiBLaW0sIFN5bHdlc3RlciBOYXdyb2NraS4NCj4gPg0KPiA+
IEhpIFRvbWksDQo+ID4NCj4gPiBUaGUgRFQgYmluZGluZyBoYXMgYmVlbiBwb3N0ZWQgd2l0aCBk
ZXZpY2UgdHJlZSBtYWlsaW5nLWxpc3QNCj4gPiAoZGV2aWNldHJlZS1kaXNjdXNzQGxpc3RzLm96
bGFicy5vcmcpIGZvciBtb3JlIHRoYW4gMiBtb250aHMuDQo+ID4gTGFzdCBwYXRjaCBWOCB3YXMg
cG9zdGVkIDEgbW9udGggYWdvLiBIb3dldmVyLCB0aGVyZSBpcyBubyBvYmplY3Rpb24uDQo+ID4g
KGh0dHA6Ly93d3cuc3Bpbmljcy5uZXQvbGlzdHMvbGludXgtZmJkZXYvbXNnMDgzNTQuaHRtbCkN
Cj4gPg0KPiA+IEFsc28sIFNhbXN1bmcgcGVvcGxlIGFscmVhZHkgcmV2aWV3ZWQgaXQuDQo+ID4g
SW4gbXkgb3BpbmlvbiwgdGhlcmUgaXMgbm8gbmVlZCB0byBnZXQgQWNrIGZyb20gdGhlIGRldmlj
ZSB0cmVlIHBlb3BsZS4NCj4gDQo+IEdyYW50IGFuZCBJIGNhbid0IHBvc3NpYmx5IHJldmlldyBl
dmVyeSBiaW5kaW5nIGZvciBldmVyeSBkZXZpY2Ugb2YNCj4gZXZlcnkgc3Vic3lzdGVtLg0KPiAN
Cj4gV2hpbGUgSSB0aGluayB0aGVyZSBpcyBwb3NzaWJpbGl0eSB0byBtYWtlIHRoaXMgbW9yZSBj
b21tb24gYWNyb3NzDQo+IHBsYXRmb3JtcywgSSBkb24ndCBoYXZlIGFueSBtYWpvciBpc3N1ZXMg
d2l0aCB0aGUgYmluZGluZywgc286DQo+IA0KPiBBY2tlZC1ieTogUm9iIEhlcnJpbmcgPHJvYi5o
ZXJyaW5nQGNhbHhlZGEuY29tPg0KDQpIaSBSb2IsDQpJIGFkZGVkIHlvdXIgQWNrZWQtYnkgdG8g
RFQgYmluZGluZyBwYXRjaC4gVGhhbmsgeW91Lg0KKGh0dHBzOi8vZ2l0aHViLmNvbS9qaW5nb28v
bGludXgvY29tbWl0LzgyNWU5MGQwYTEzODczODY1NzUwOWQ3NDYwZDc3ZWRiMjhmY2ZkYzApDQoN
ClRvbWksDQpJIGhhdmUgYW4gQWNrIGZyb20gYSBEZXZpY2UgdHJlZSBNYWludGFpbmVyLCBSb2Ig
SGVycmluZy4gDQpQbGVhc2UsIHB1bGwgdGhlIHBhdGNoZXMuDQoNCkJlc3QgcmVnYXJkcywNCkpp
bmdvbyBIYW4NCg0KPiANCj4gUm9iDQo+IA0KPiA+IEdyYW50LCBSb2I6IGlmIHlvdSBoYXZlIGFu
b3RoZXIgb3BpbmlvbiwgcGxlYXNlIGxldCBtZSBrbm93IGtpbmRseS4NCj4gPg0KPiA+IEJlc3Qg
cmVnYXJkcywNCj4gPiBKaW5nb28gSGFuDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IGRldmljZXRyZWUtZGlzY3VzcyBtYWlsaW5n
IGxpc3QNCj4gPiBkZXZpY2V0cmVlLWRpc2N1c3NAbGlzdHMub3psYWJzLm9yZw0KPiA+IGh0dHBz
Oi8vbGlzdHMub3psYWJzLm9yZy9saXN0aW5mby9kZXZpY2V0cmVlLWRpc2N1c3MNCj4gPg0K
^ permalink raw reply
* Re: [GIT PULL] Exynos DP for v3.8
From: Jingoo Han @ 2012-11-29 6:42 UTC (permalink / raw)
To: Rob Herring
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Kukjin Kim,
FlorianSchandinat-Mmb7MZpHnFY@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
Jingoo Han, rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org,
Tomi Valkeinen, Sylwester Nawrocki
In-Reply-To: <28517517.77811353652672706.JavaMail.weblogic@epml06>
T24gVGh1cnNkYXksIE5vdmVtYmVyIDI5LCAyMDEyIDQ6NTggQU0sIFJvYiBIZXJyaW5nIHdyb3Rl
DQo+IE9uIDExLzI3LzIwMTIgMDU6NTkgUE0sIEppbmdvbyBIYW4gd3JvdGU6DQo+ID4gT24gVHVl
c2RheSwgTm92ZW1iZXIgMjcsIDIwMTIgNjo1OCBQTSwgVG9taSBWYWxrZWluZW4gd3JvdGUNCj4g
Pj4NCj4gPj4gT24gMjAxMi0xMS0yMyAwODozNywgSmluZ29vIEhhbiB3cm90ZToNCj4gPj4+IEhp
IFRvbWksDQo+ID4+Pg0KPiA+Pj4gVGhhbmsgeW91IGZvciB0YWtpbmcgY2FyZSBvZiBwdWxsIHJl
cXVlc3RzIGZvciB0aGUgdjMuOCBtZXJnZSB3aW5kb3cuDQo+ID4+PiBUaGVzZSBwYXRjaGVzIGhh
dmUgYmVlbiBzdWJtaXR0ZWQgZm9yIG1vcmUgdGhhbiBvbmUgbW9udGgsDQo+ID4+PiBhbmQgdGVz
dGVkIHdpdGggRXh5bm9zNTI1MC4NCj4gPj4+DQo+ID4+PiBUaGUgZm9sbG93aW5nIGNoYW5nZXMg
c2luY2UgY29tbWl0IGY0YTc1ZDJlYjdiMWUyMjA2MDk0YjkwMWJlMDlhZGIzMWJhNjM2ODE6DQo+
ID4+Pg0KPiA+Pj4gICBMaW51eCAzLjctcmM2IChGcmkgTm92IDE2IDE3OjQyOjQwIDIwMTIgLTA4
MDApDQo+ID4+Pg0KPiA+Pj4gYXJlIGF2YWlsYWJsZSBpbiB0aGUgZ2l0IHJlcG9zaXRvcnkgYXQ6
DQo+ID4+PiAgIGdpdDovL2dpdGh1Yi5jb20vamluZ29vL2xpbnV4LmdpdCBleHlub3MtZHAtbmV4
dA0KPiA+Pj4NCj4gPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+IEV4eW5vcyBEUCBjaGFuZ2VzIGZvciB0aGUg
My44IG1lcmdlIHdpbmRvdy4NCj4gPj4+DQo+ID4+PiAtIERldmljZSBUcmVlIHN1cHBvcnQgZm9y
IFNhbXN1bmcgRXh5bm9zIERQDQo+ID4+PiAtIFNXIExpbmsgdHJhaW5pbmcgaXMgY2xlYW5lZCB1
cC4NCj4gPj4+IC0gSFBEIGludGVycnVwdCBpcyBzdXBwb3J0ZWQuDQo+ID4+PiAtLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+
ID4+Pg0KPiA+Pj4gQWpheSBLdW1hciAoNSk6DQo+ID4+PiAgICAgICB2aWRlbzogZXh5bm9zX2Rw
OiBBZGQgZGV2aWNlIHRyZWUgc3VwcG9ydCB0byBEUCBkcml2ZXINCj4gPj4+ICAgICAgIHZpZGVv
OiBleHlub3NfZHA6IGRldmljZSB0cmVlIGRvY3VtZW50YXRpb24NCj4gPj4+ICAgICAgIHZpZGVv
OiBleHlub3NfZHA6IFJlc2V0IGFuZCBpbml0aWFsaXplIERQIGJlZm9yZSByZXF1ZXN0aW5nIGly
cQ0KPiA+Pj4gICAgICAgdmlkZW86IGV4eW5vc19kcDogRml4IGluY29ycmVjdCBzZXR0aW5nIGZv
ciBJTlRfQ1RMDQo+ID4+PiAgICAgICB2aWRlbzogZXh5bm9zX2RwOiByZW1vdmUgcmVkdW5kYW50
IHBhcmFtZXRlcnMNCj4gPj4+DQo+ID4+PiBTZWFuIFBhdWwgKDgpOg0KPiA+Pj4gICAgICAgdmlk
ZW86IGV4eW5vc19kcDogQ2hlY2sgRFBDRCByZXR1cm4gY29kZXMNCj4gPj4+ICAgICAgIHZpZGVv
OiBleHlub3NfZHA6IENsZWFuIHVwIFNXIGxpbmsgdHJhaW5pbmcNCj4gPj4+ICAgICAgIHZpZGVv
OiBleHlub3NfZHA6IEdldCBwbGwgbG9jayBiZWZvcmUgcGF0dGVybiBzZXQNCj4gPj4+ICAgICAg
IHZpZGVvOiBleHlub3NfZHA6IEltcHJvdmUgRURJRCBlcnJvciBoYW5kbGluZw0KPiA+Pj4gICAg
ICAgdmlkZW86IGV4eW5vc19kcDogRml4IGJ1ZyB3aGVuIGNoZWNraW5nIGRwLT5pcnENCj4gPj4+
ICAgICAgIHZpZGVvOiBleHlub3NfZHA6IFJlbW92ZSBzaW5rIGNvbnRyb2wgdG8gRDANCj4gPj4+
ICAgICAgIHZpZGVvOiBleHlub3NfZHA6IE1vdmUgaG90cGx1ZyBpbnRvIGEgd29ya3F1ZXVlDQo+
ID4+PiAgICAgICB2aWRlbzogZXh5bm9zX2RwOiBFbmFibGUgaG90cGx1ZyBpbnRlcnJ1cHRzDQo+
ID4+Pg0KPiA+Pj4gIC4uLi9kZXZpY2V0cmVlL2JpbmRpbmdzL3ZpZGVvL2V4eW5vc19kcC50eHQg
ICAgICAgIHwgICA4MCArKysNCj4gPj4+ICBkcml2ZXJzL3ZpZGVvL2V4eW5vcy9leHlub3NfZHBf
Y29yZS5jICAgICAgICAgICAgICB8ICA2OTcgKysrKysrKysrKysrLS0tLS0tLS0NCj4gPj4+ICBk
cml2ZXJzL3ZpZGVvL2V4eW5vcy9leHlub3NfZHBfY29yZS5oICAgICAgICAgICAgICB8ICAgMjEg
Ky0NCj4gPj4+ICBkcml2ZXJzL3ZpZGVvL2V4eW5vcy9leHlub3NfZHBfcmVnLmMgICAgICAgICAg
ICAgICB8ICAgNzcgKystDQo+ID4+PiAgZHJpdmVycy92aWRlby9leHlub3MvZXh5bm9zX2RwX3Jl
Zy5oICAgICAgICAgICAgICAgfCAgICAzICstDQo+ID4+PiAgNSBmaWxlcyBjaGFuZ2VkLCA1ODMg
aW5zZXJ0aW9ucygrKSwgMjk1IGRlbGV0aW9ucygtKQ0KPiA+Pj4gIGNyZWF0ZSBtb2RlIDEwMDY0
NCBEb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvdmlkZW8vZXh5bm9zX2RwLnR4dA0K
PiA+Pg0KPiA+PiBIYXMgdGhlIERUIGJpbmRpbmdzIGJlZW4gcmV2aWV3ZWQgYnkgdGhlIGRldmlj
ZSB0cmVlIHBlb3BsZT8gSXQgd291bGQNCj4gPj4gZ29vZCB0byBoYXZlIGFuIGFjayBmcm9tIHRo
ZW0uDQo+ID4NCj4gPiBDQydlZCBkZXZpY2UgdHJlZSBtYWlsaW5nLWxpc3QsIEdyYW50IExpa2Vs
eSwgUm9iIEhlcnJpbmcsIEt1a2ppbiBLaW0sIFN5bHdlc3RlciBOYXdyb2NraS4NCj4gPg0KPiA+
IEhpIFRvbWksDQo+ID4NCj4gPiBUaGUgRFQgYmluZGluZyBoYXMgYmVlbiBwb3N0ZWQgd2l0aCBk
ZXZpY2UgdHJlZSBtYWlsaW5nLWxpc3QNCj4gPiAoZGV2aWNldHJlZS1kaXNjdXNzQGxpc3RzLm96
bGFicy5vcmcpIGZvciBtb3JlIHRoYW4gMiBtb250aHMuDQo+ID4gTGFzdCBwYXRjaCBWOCB3YXMg
cG9zdGVkIDEgbW9udGggYWdvLiBIb3dldmVyLCB0aGVyZSBpcyBubyBvYmplY3Rpb24uDQo+ID4g
KGh0dHA6Ly93d3cuc3Bpbmljcy5uZXQvbGlzdHMvbGludXgtZmJkZXYvbXNnMDgzNTQuaHRtbCkN
Cj4gPg0KPiA+IEFsc28sIFNhbXN1bmcgcGVvcGxlIGFscmVhZHkgcmV2aWV3ZWQgaXQuDQo+ID4g
SW4gbXkgb3BpbmlvbiwgdGhlcmUgaXMgbm8gbmVlZCB0byBnZXQgQWNrIGZyb20gdGhlIGRldmlj
ZSB0cmVlIHBlb3BsZS4NCj4gDQo+IEdyYW50IGFuZCBJIGNhbid0IHBvc3NpYmx5IHJldmlldyBl
dmVyeSBiaW5kaW5nIGZvciBldmVyeSBkZXZpY2Ugb2YNCj4gZXZlcnkgc3Vic3lzdGVtLg0KPiAN
Cj4gV2hpbGUgSSB0aGluayB0aGVyZSBpcyBwb3NzaWJpbGl0eSB0byBtYWtlIHRoaXMgbW9yZSBj
b21tb24gYWNyb3NzDQo+IHBsYXRmb3JtcywgSSBkb24ndCBoYXZlIGFueSBtYWpvciBpc3N1ZXMg
d2l0aCB0aGUgYmluZGluZywgc286DQo+IA0KPiBBY2tlZC1ieTogUm9iIEhlcnJpbmcgPHJvYi5o
ZXJyaW5nQGNhbHhlZGEuY29tPg0KDQpIaSBSb2IsDQpJIGFkZGVkIHlvdXIgQWNrZWQtYnkgdG8g
RFQgYmluZGluZyBwYXRjaC4gVGhhbmsgeW91LiA6KQ0KKGh0dHBzOi8vZ2l0aHViLmNvbS9qaW5n
b28vbGludXgvY29tbWl0LzgyNWU5MGQwYTEzODczODY1NzUwOWQ3NDYwZDc3ZWRiMjhmY2ZkYzAp
DQoNClRvbWksDQpJIGhhdmUgYW4gQWNrIGZyb20gYSBEZXZpY2UgdHJlZSBNYWludGFpbmVyLCBS
b2IgSGVycmluZy4gDQpQbGVhc2UsIHB1bGwgdGhlIHBhdGNoZXMuDQoNCkJlc3QgcmVnYXJkcywN
CkppbmdvbyBIYW4NCg0KPiANCj4gUm9iDQo+IA0KPiA+IEdyYW50LCBSb2I6IGlmIHlvdSBoYXZl
IGFub3RoZXIgb3BpbmlvbiwgcGxlYXNlIGxldCBtZSBrbm93IGtpbmRseS4NCj4gPg0KPiA+IEJl
c3QgcmVnYXJkcywNCj4gPiBKaW5nb28gSGFuDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IGRldmljZXRyZWUtZGlzY3VzcyBtYWls
aW5nIGxpc3QNCj4gPiBkZXZpY2V0cmVlLWRpc2N1c3NAbGlzdHMub3psYWJzLm9yZw0KPiA+IGh0
dHBzOi8vbGlzdHMub3psYWJzLm9yZy9saXN0aW5mby9kZXZpY2V0cmVlLWRpc2N1c3MNCj4gPg=
^ permalink raw reply
* Re: [GIT PULL FOR v3.8] SH Mobile LCDC patches
From: Tomi Valkeinen @ 2012-11-29 8:40 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <2641878.cGkiV3BMeH@avalon>
[-- Attachment #1: Type: text/plain, Size: 486 bytes --]
On 2012-11-22 16:39, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for taking care of pull requests for the v3.8 merge window. Here's
> one already :-)
>
> The following changes since commit f4a75d2eb7b1e2206094b901be09adb31ba63681:
>
> Linux 3.7-rc6 (2012-11-16 17:42:40 -0800)
>
> are available in the git repository at:
> git://linuxtv.org/pinchartl/fbdev.git lcdc-next
>
Pulled to:
git://gitorious.org/linux-omap-dss2/linux.git for-next
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [GIT PULL] Samsung Framebuffer for v3.8
From: Tomi Valkeinen @ 2012-11-29 8:41 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <16376487.77671353652569048.JavaMail.weblogic@epml06>
[-- Attachment #1: Type: text/plain, Size: 561 bytes --]
On 2012-11-23 08:36, Jingoo Han wrote:
> Hi Tomi,
>
> Thank you for taking care of pull requests for the v3.8 merge window.
> These patches have been submitted for about two months,
> and tested with Exynos4210 and Exynos5250.
>
> The following changes since commit f4a75d2eb7b1e2206094b901be09adb31ba63681:
>
> Linux 3.7-rc6 (Fri Nov 16 17:42:40 2012 -0800)
>
> are available in the git repository at:
> git://github.com/jingoo/linux.git samsung-fb-next
Pulled to:
git://gitorious.org/linux-omap-dss2/linux.git for-next
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 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