* 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: 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 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: [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: [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: [PATCH 1/5] backlight: Add GPIO-based backlight driver
From: Laurent Pinchart @ 2012-11-27 11:54 UTC (permalink / raw)
To: jg1.han
Cc: Laurent Pinchart, akpm, linux-kernel, linux-sh@vger.kernel.org,
linux-fbdev@vger.kernel.org, Paul Mundt, Magnus Damm,
Richard Purdie, Kuninori Morimoto
In-Reply-To: <33110366.44811353978636788.JavaMail.weblogic@epv6ml07>
Hi Jingoo,
On Tuesday 27 November 2012 01:10:36 Jingoo Han wrote:
> On Saturday, November 24, 2012 1:35 AM, Laurent Pinchart wrote
>
> >
> > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > ---
> >
> > drivers/video/backlight/Kconfig | 7 ++
> > drivers/video/backlight/Makefile | 1 +
> > drivers/video/backlight/gpio_backlight.c | 158 +++++++++++++++++++++++++
> > include/video/gpio_backlight.h | 21 ++++
> > 4 files changed, 187 insertions(+), 0 deletions(-)
> > create mode 100644 drivers/video/backlight/gpio_backlight.c
> > create mode 100644 include/video/gpio_backlight.h
>
>
> [...]
>
>
> > +static int __devinit gpio_backlight_probe(struct platform_device *pdev)
> > +{
> > + struct gpio_backlight_platform_data *pdata = pdev->dev.platform_data;
> > + struct backlight_properties props;
> > + struct backlight_device *bl;
> > + struct gpio_backlight *gbl;
> > + int ret;
> > +
> > + gbl = devm_kzalloc(&pdev->dev, sizeof(*gbl), GFP_KERNEL);
> > + if (gbl = NULL)
> > + return -ENOMEM;
> > +
> > + gbl->dev = &pdev->dev;
> > +
> > + if (!pdata) {
> > + dev_err(&pdev->dev, "failed to find platform data\n");
> > + return -ENODEV;
> > + }
> > +
> > + gbl->fbdev = pdata->fbdev;
> > + gbl->gpio = pdata->gpio;
> > + gbl->active = pdata->active_low ? 0 : 1;
> > +
> > + ret = devm_gpio_request_one(gbl->dev, gbl->gpio, GPIOF_DIR_OUT,
> > + pdata->name);
>
>
> Please use GPIOF_INIT flags if you want to turn off GPIO backlight.
> If gbl->active is inverted, GPIOF_INIT_HIGH can be used as below:
>
> ret = devm_gpio_request_one(gbl->dev, gbl->gpio,
> GPIOF_DIR_OUT | (gbl->active ?
> GPIOF_INIT_LOW : GPIOF_INIT_HIGH),
> pdata->name);
Good point, thank you. I'll fix that.
> > + if (ret < 0) {
> > + dev_err(&pdev->dev, "unable to request GPIO\n");
> > + return ret;
> > + }
> > +
> > + memset(&props, 0, sizeof(props));
> > + props.type = BACKLIGHT_RAW;
> > + props.max_brightness = 1;
> > + bl = backlight_device_register(dev_name(&pdev->dev), &pdev->dev, gbl,
> > + &gpio_backlight_ops, &props);
> > + if (IS_ERR(bl)) {
> > + dev_err(&pdev->dev, "failed to register backlight\n");
> > + return PTR_ERR(bl);
> > + }
> > +
> > + bl->props.brightness = pdata->def_value;
> > + backlight_update_status(bl);
> > +
> > + platform_set_drvdata(pdev, bl);
> > + return 0;
> > +}
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [GIT PULL] Exynos DP for v3.8
From: Tomi Valkeinen @ 2012-11-27 9:58 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <28517517.77811353652672706.JavaMail.weblogic@epml06>
[-- Attachment #1: Type: text/plain, Size: 2161 bytes --]
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.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: Temporary fbdev maintainership for 3.8 merge window
From: Tabi Timur-B04825 @ 2012-11-27 2:23 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <50AE34DE.7030209@ti.com>
On Thu, Nov 22, 2012 at 8:21 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> If you have just a few patches, I can apply them directly. If you have
> more, please send a proper pull request to me.
I have a set of nine patches that I posted on October 16th:
https://patchwork.kernel.org/project/linux-fbdev/list/?submitter=timur
These are intended for 3.8.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 1/5] backlight: Add GPIO-based backlight driver
From: Jingoo Han @ 2012-11-27 1:24 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Jingoo Han, Laurent Pinchart, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, linux-sh@vger.kernel.org,
linux-fbdev@vger.kernel.org, Paul Mundt, Magnus Damm,
Richard Purdie, Kuninori Morimoto
In-Reply-To: <1353688515-30458-2-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
T24gTW9uZGF5LCBOb3ZlbWJlciAyNiwgMjAxMiA3OjI1IFBNLCBMYXVyZW50IFBpbmNoYXJ0IHdy
b3RlDQo+IA0KPiBIaSBKaW5nb28sDQo+IA0KPiBPbiBNb25kYXkgMjYgTm92ZW1iZXIgMjAxMiAw
OTo0OTozNiBKaW5nb28gSGFuIHdyb3RlOg0KPiA+IE9uIFNhdHVyZGF5LCBOb3ZlbWJlciAyNCwg
MjAxMiAxOjM1IEFNLCBMYXVyZW50IFBpbmNoYXJ0IHdyb3RlDQo+ID4gPg0KPiA+ID4gU2lnbmVk
LW9mZi1ieTogTGF1cmVudCBQaW5jaGFydCA8bGF1cmVudC5waW5jaGFydEBpZGVhc29uYm9hcmQu
Y29tPg0KPiA+DQo+ID4gQ0MnZWQgQW5kcmV3IE1vcnRvbg0KPiA+DQo+ID4gSXQgbG9va3MgZ29v
ZC4gQWxzbywgSSB0ZXN0ZWQgdGhpcyBwYXRjaCB3aXRoIFNNREs0MjEwIGJvYXJkLg0KPiA+IEFj
a2VkLWJ5OiBKaW5nb28gSGFuIDxqZzEuaGFuQHNhbXN1bmcuY29tPg0KPiANCj4gVGhhbmsgeW91
Lg0KPiANCj4gVW5sZXNzIFJpY2hhcmQgd2FudHMgdG8gdGFrZSAxLzUgYW5kIDIvNSwgSSBwbGFu
IHRvIHB1c2ggdGhlbSB0aHJvdWdoIGVpdGhlcg0KPiB0aGUgUmVuZXNhcyBBUk0gb3IgUmVuZXNh
cyBTSCB0cmVlIHdpdGggdGhlIGJvYXJkIGNvZGUgcGF0Y2hlcy4NCg0KSGkgTGF1cmVudCwNCg0K
T0ssIEkgc2VlLg0KTWF5YmUgUmljaGFyZCB3b24ndCB0YWtlIDEvNSBhbmQgMi81LiBBcyB5b3Ug
bWVudGlvbmVkLCBpdCB3b3VsZCBiZSBnb29kDQp0byBwdXNoIHRoZW0gdGhyb3VnaG91dCB0aGUg
UmVuZXNhcyB0cmVlIHRvIGF2b2lkIGJpc2VjdGlvbiBicmVha2FnZXMuDQoNCkJlc3QgcmVnYXJk
cywNCkppbmdvbyBIYW4NCg0KDQo
^ permalink raw reply
* Re: [PATCH 1/5] backlight: Add GPIO-based backlight driver
From: Jingoo Han @ 2012-11-27 1:10 UTC (permalink / raw)
To: Laurent Pinchart
Cc: akpm, linux-kernel, linux-sh@vger.kernel.org,
linux-fbdev@vger.kernel.org, Paul Mundt, Magnus Damm,
Richard Purdie, Kuninori Morimoto, Jingoo Han
In-Reply-To: <1353688515-30458-2-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
T24gU2F0dXJkYXksIE5vdmVtYmVyIDI0LCAyMDEyIDE6MzUgQU0sIExhdXJlbnQgUGluY2hhcnQg
d3JvdGUNCj4gDQo+IFNpZ25lZC1vZmYtYnk6IExhdXJlbnQgUGluY2hhcnQgPGxhdXJlbnQucGlu
Y2hhcnRAaWRlYXNvbmJvYXJkLmNvbT4NCj4gLS0tDQo+ICBkcml2ZXJzL3ZpZGVvL2JhY2tsaWdo
dC9LY29uZmlnICAgICAgICAgIHwgICAgNyArKw0KPiAgZHJpdmVycy92aWRlby9iYWNrbGlnaHQv
TWFrZWZpbGUgICAgICAgICB8ICAgIDEgKw0KPiAgZHJpdmVycy92aWRlby9iYWNrbGlnaHQvZ3Bp
b19iYWNrbGlnaHQuYyB8ICAxNTggKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrDQo+ICBp
bmNsdWRlL3ZpZGVvL2dwaW9fYmFja2xpZ2h0LmggICAgICAgICAgIHwgICAyMSArKysrDQo+ICA0
IGZpbGVzIGNoYW5nZWQsIDE4NyBpbnNlcnRpb25zKCspLCAwIGRlbGV0aW9ucygtKQ0KPiAgY3Jl
YXRlIG1vZGUgMTAwNjQ0IGRyaXZlcnMvdmlkZW8vYmFja2xpZ2h0L2dwaW9fYmFja2xpZ2h0LmMN
Cj4gIGNyZWF0ZSBtb2RlIDEwMDY0NCBpbmNsdWRlL3ZpZGVvL2dwaW9fYmFja2xpZ2h0LmgNCg0K
Wy4uLl0NCg0KPiArc3RhdGljIGludCBfX2RldmluaXQgZ3Bpb19iYWNrbGlnaHRfcHJvYmUoc3Ry
dWN0IHBsYXRmb3JtX2RldmljZSAqcGRldikNCj4gK3sNCj4gKwlzdHJ1Y3QgZ3Bpb19iYWNrbGln
aHRfcGxhdGZvcm1fZGF0YSAqcGRhdGEgPSBwZGV2LT5kZXYucGxhdGZvcm1fZGF0YTsNCj4gKwlz
dHJ1Y3QgYmFja2xpZ2h0X3Byb3BlcnRpZXMgcHJvcHM7DQo+ICsJc3RydWN0IGJhY2tsaWdodF9k
ZXZpY2UgKmJsOw0KPiArCXN0cnVjdCBncGlvX2JhY2tsaWdodCAqZ2JsOw0KPiArCWludCByZXQ7
DQo+ICsNCj4gKwlnYmwgPSBkZXZtX2t6YWxsb2MoJnBkZXYtPmRldiwgc2l6ZW9mKCpnYmwpLCBH
RlBfS0VSTkVMKTsNCj4gKwlpZiAoZ2JsID09IE5VTEwpDQo+ICsJCXJldHVybiAtRU5PTUVNOw0K
PiArDQo+ICsJZ2JsLT5kZXYgPSAmcGRldi0+ZGV2Ow0KPiArDQo+ICsJaWYgKCFwZGF0YSkgew0K
PiArCQlkZXZfZXJyKCZwZGV2LT5kZXYsICJmYWlsZWQgdG8gZmluZCBwbGF0Zm9ybSBkYXRhXG4i
KTsNCj4gKwkJcmV0dXJuIC1FTk9ERVY7DQo+ICsJfQ0KPiArDQo+ICsJZ2JsLT5mYmRldiA9IHBk
YXRhLT5mYmRldjsNCj4gKwlnYmwtPmdwaW8gPSBwZGF0YS0+Z3BpbzsNCj4gKwlnYmwtPmFjdGl2
ZSA9IHBkYXRhLT5hY3RpdmVfbG93ID8gMCA6IDE7DQo+ICsNCj4gKwlyZXQgPSBkZXZtX2dwaW9f
cmVxdWVzdF9vbmUoZ2JsLT5kZXYsIGdibC0+Z3BpbywgR1BJT0ZfRElSX09VVCwNCj4gKwkJCQkg
ICAgcGRhdGEtPm5hbWUpOw0KDQpQbGVhc2UgdXNlIEdQSU9GX0lOSVQgZmxhZ3MgaWYgeW91IHdh
bnQgdG8gdHVybiBvZmYgR1BJTyBiYWNrbGlnaHQuDQpJZiBnYmwtPmFjdGl2ZSBpcyBpbnZlcnRl
ZCwgR1BJT0ZfSU5JVF9ISUdIIGNhbiBiZSB1c2VkIGFzIGJlbG93Og0KDQoJcmV0ID0gZGV2bV9n
cGlvX3JlcXVlc3Rfb25lKGdibC0+ZGV2LCBnYmwtPmdwaW8sDQoJCQkJICAgIEdQSU9GX0RJUl9P
VVQgfCAoZ2JsLT5hY3RpdmUgPw0KCQkJCSAgICBHUElPRl9JTklUX0xPVyA6IEdQSU9GX0lOSVRf
SElHSCksDQoJCQkJICAgIHBkYXRhLT5uYW1lKTsNCg0KQmVzdCByZWdhcmRzLA0KSmluZ29vIEhh
bg0KDQo+ICsJaWYgKHJldCA8IDApIHsNCj4gKwkJZGV2X2VycigmcGRldi0+ZGV2LCAidW5hYmxl
IHRvIHJlcXVlc3QgR1BJT1xuIik7DQo+ICsJCXJldHVybiByZXQ7DQo+ICsJfQ0KPiArDQo+ICsJ
bWVtc2V0KCZwcm9wcywgMCwgc2l6ZW9mKHByb3BzKSk7DQo+ICsJcHJvcHMudHlwZSA9IEJBQ0tM
SUdIVF9SQVc7DQo+ICsJcHJvcHMubWF4X2JyaWdodG5lc3MgPSAxOw0KPiArCWJsID0gYmFja2xp
Z2h0X2RldmljZV9yZWdpc3RlcihkZXZfbmFtZSgmcGRldi0+ZGV2KSwgJnBkZXYtPmRldiwgZ2Js
LA0KPiArCQkJCSAgICAgICAmZ3Bpb19iYWNrbGlnaHRfb3BzLCAmcHJvcHMpOw0KPiArCWlmIChJ
U19FUlIoYmwpKSB7DQo+ICsJCWRldl9lcnIoJnBkZXYtPmRldiwgImZhaWxlZCB0byByZWdpc3Rl
ciBiYWNrbGlnaHRcbiIpOw0KPiArCQlyZXR1cm4gUFRSX0VSUihibCk7DQo+ICsJfQ0KPiArDQo+
ICsJYmwtPnByb3BzLmJyaWdodG5lc3MgPSBwZGF0YS0+ZGVmX3ZhbHVlOw0KPiArCWJhY2tsaWdo
dF91cGRhdGVfc3RhdHVzKGJsKTsNCj4gKw0KPiArCXBsYXRmb3JtX3NldF9kcnZkYXRhKHBkZXYs
IGJsKTsNCj4gKwlyZXR1cm4gMDsNCj4gK30NCg0KDQo
^ permalink raw reply
* Re: Temporary fbdev maintainership for 3.8 merge window
From: Timur Tabi @ 2012-11-26 17:16 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <50AE34DE.7030209@ti.com>
On Mon, Nov 26, 2012 at 10:57 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Please send me a pull request. It's much easier for me to pull than
> apply bunch of patches.
Ok, that will take a while. I don't have an external repository that
I can use. I would need to create one on github first.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: Temporary fbdev maintainership for 3.8 merge window
From: Tomi Valkeinen @ 2012-11-26 16:57 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <50AE34DE.7030209@ti.com>
[-- Attachment #1: Type: text/plain, Size: 754 bytes --]
On 2012-11-26 18:48, Timur Tabi wrote:
> On Thu, Nov 22, 2012 at 8:21 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
>> Florian told me he's very busy for the time being, and this probably
>> last at least until sometime early December. The merge window is coming
>> near, and instead of everybody sending their fbdev related patches
>> directly to Linus, I offer my services as a temporary fbdev maintainer
>> for the next merge window.
>
> Tomi,
>
> I have a set of nine patches that I posted on October 16th:
>
> https://patchwork.kernel.org/project/linux-fbdev/list/?submitter=timur
>
> These are intended for 3.8.
Please send me a pull request. It's much easier for me to pull than
apply bunch of patches.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCHv15 3/7] video: add of helper for display timings/videomode
From: Tomi Valkeinen @ 2012-11-26 16:56 UTC (permalink / raw)
To: Steffen Trumtrar
Cc: linux-fbdev, kernel, David Airlie, devicetree-discuss,
Florian Tobias Schandinat, dri-devel, Laurent Pinchart,
Philipp Zabel, Guennady Liakhovetski, linux-media
In-Reply-To: <20121126161055.GB30791@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 5578 bytes --]
On 2012-11-26 18:10, Steffen Trumtrar wrote:
> Hi,
>
> On Mon, Nov 26, 2012 at 04:38:36PM +0200, Tomi Valkeinen wrote:
>>> +optional properties:
>>> + - hsync-active: hsync pulse is active low/high/ignored
>>> + - vsync-active: vsync pulse is active low/high/ignored
>>> + - de-active: data-enable pulse is active low/high/ignored
>>> + - pixelclk-inverted: pixelclock is inverted (active on falling edge)/
>>> + non-inverted (active on rising edge)/
>>> + ignored (ignore property)
>>
>> I think hsync-active and vsync-active are clear, and commonly used, and
>> they are used for both drm and fb mode conversions in later patches.
>>
>> de-active is not used in drm and fb mode conversions, but I think it's
>> also clear.
>>
>> pixelclk-inverted is not used in the mode conversions. It's also a bit
>> unclear to me. What does it mean that pix clock is "active on rising
>> edge"? The pixel data is driven on rising edge? How about the sync
>> signals and DE, when are they driven? Does your HW have any settings
>> related to those?
>>
>
> Those are properties commonly found in display specs. That is why they are here.
> If the GPU does not support the property it can be omitted.
So what does the pixelclk-inverted mean? Normally the SoC drives pixel
data on rising edge, and the panel samples it at falling edge? And
vice-versa for inverted? Or the other way around?
When is hsync/vsync set? On rising or falling edge of pclk?
My point here is that the pixelclk-inverted is not crystal clear thing,
like the hsync/vsync/de-active values are.
And while thinking about this, I realized that the meaning of
pixelclk-inverted depends on what component is it applied to. Presuming
normal pixclk means "pixel data on rising edge", the meaning of that
depends on do we consider the SoC or the panel. The panel needs to
sample the data on the other edge from the one the SoC uses to drive the
data.
Does the videomode describe the panel, or does it describe the settings
programmed to the SoC?
>> OMAP has the invert pclk setting, but it also has a setting to define
>> when the sync signals are driven. The options are:
>> - syncs are driven on rising edge of pclk
>> - syncs are driven on falling edge of pclk
>> - syncs are driven on the opposite edge of pclk compared to the pixel data
>>
>> For DE there's no setting, except the active high/low.
>>
>> And if I'm not mistaken, if the optional properties are not defined,
>> they are not ignored, but left to the default 0. Which means active low,
>> or active on rising edge(?). I think it would be good to have a
>> "undefined" value for the properties.
>>
>
> Yes. As mentioned in my other mail, the intention of the omitted properties do
> not propagate properly. Omitted must be a value < 0, so it is clear in a later
> stage, that this property shall not be used. And isn't unintentionally considered
> to be active low.
Ok. Just note that the values are currently stored into u32, and I don't
think using negative error values with u32 is a good idea.
>> I have some of the same concerns for this series than with the
>> interpreted power sequences (on fbdev): when you publish the DT
>> bindings, it's somewhat final version then, and fixing it later will be
>> difficult. Of course, video modes are much clearer than the power
>> sequences, so it's possible there won't be any problems with the DT
>> bindings.
>>
>
> The binding is pretty much at the bare minimum after a lot of discussion about
> the properties. Even if the binding changes, I think it will rather grow than
> shrink. Take the doubleclock property for example. It got here mistakingly,
> because we had a display that has this feature.
Right. That's why I would leave the pixelclock-inverted out for now, if
we're not totally sure how it's defined. Of course, it could be just me
who is not understanding the pixclk-inverted =).
>> However, I'd still feel safer if the series would be split to non-DT and
>> DT parts. The non-DT parts could be merged quite easily, and people
>> could start using them in their kernels. This should expose
>> bugs/problems related to the code.
>>
>> The DT part could be merged later, when there's confidence that the
>> timings are good for all platforms.
>>
>> Or, alternatively, all the non-common bindings (de-active, pck
>> invert,...) that are not used for fbdev or drm currently could be left
>> out for now. But I'd stil prefer merging it in two parts.
>
> I don't say that I'm against it, but the whole reason for the series was
> getting the display timings from a DT into a graphics driver. And I think
> I remember seeing some other attempts at achieving this, but all specific
> to one special case. There is even already a mainline driver that uses an older
> version of the DT bindings (vt8500-fb).
I think it'd be very useful even without DT bindings. But yes, I
understand your need for it.
You're now in v15 of the series. Are you sure v16 will be good enough to
freeze the DT bindings, if 15 previous versions weren't? =). Perhaps I'm
just overly cautious with DT bindings. APIs that are exposed outside the
kernel scare me, as they should be just and not almost right.
However, I want to also point out that where ever you're going to use
the videomode DT bindings, when the common display framework is merged
and presuming you'll use it, you may need to change the DT stuff again
(for the SoC/gfx card, not the videomode bindings).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: Temporary fbdev maintainership for 3.8 merge window
From: Timur Tabi @ 2012-11-26 16:48 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <50AE34DE.7030209@ti.com>
On Thu, Nov 22, 2012 at 8:21 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Florian told me he's very busy for the time being, and this probably
> last at least until sometime early December. The merge window is coming
> near, and instead of everybody sending their fbdev related patches
> directly to Linus, I offer my services as a temporary fbdev maintainer
> for the next merge window.
Tomi,
I have a set of nine patches that I posted on October 16th:
https://patchwork.kernel.org/project/linux-fbdev/list/?submitter=timur
These are intended for 3.8.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCHv15 3/7] video: add of helper for display timings/videomode
From: Steffen Trumtrar @ 2012-11-26 16:10 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev, kernel, David Airlie, devicetree-discuss,
Florian Tobias Schandinat, dri-devel, Laurent Pinchart,
Philipp Zabel, Guennady Liakhovetski, linux-media
In-Reply-To: <50B37EEC.6090808@ti.com>
Hi,
On Mon, Nov 26, 2012 at 04:38:36PM +0200, Tomi Valkeinen wrote:
> Hi,
>
> On 2012-11-26 11:07, Steffen Trumtrar wrote:
> > This adds support for reading display timings from DT into a struct
> > display_timings. The of_display_timing implementation supports multiple
> > subnodes. All children are read into an array, that can be queried.
> >
> > If no native mode is specified, the first subnode will be used.
> >
> > For cases where the graphics driver knows there can be only one
> > mode description or where the driver only supports one mode, a helper
> > function of_get_videomode is added, that gets a struct videomode from DT.
> >
> > Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> > Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> > Acked-by: Stephen Warren <swarren@nvidia.com>
> > Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
> > Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
> > Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
> > Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
> > Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > ---
> > .../devicetree/bindings/video/display-timing.txt | 107 ++++++++++
> > drivers/video/Kconfig | 15 ++
> > drivers/video/Makefile | 2 +
> > drivers/video/of_display_timing.c | 219 ++++++++++++++++++++
> > drivers/video/of_videomode.c | 54 +++++
> > include/linux/of_display_timing.h | 20 ++
> > include/linux/of_videomode.h | 18 ++
> > 7 files changed, 435 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/video/display-timing.txt
> > create mode 100644 drivers/video/of_display_timing.c
> > create mode 100644 drivers/video/of_videomode.c
> > create mode 100644 include/linux/of_display_timing.h
> > create mode 100644 include/linux/of_videomode.h
> >
> > diff --git a/Documentation/devicetree/bindings/video/display-timing.txt b/Documentation/devicetree/bindings/video/display-timing.txt
> > new file mode 100644
> > index 0000000..e238f27
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/video/display-timing.txt
> > @@ -0,0 +1,107 @@
> > +display-timing bindings
> > +===========> > +
> > +display-timings node
> > +--------------------
> > +
> > +required properties:
> > + - none
> > +
> > +optional properties:
> > + - native-mode: The native mode for the display, in case multiple modes are
> > + provided. When omitted, assume the first node is the native.
> > +
> > +timing subnode
> > +--------------
> > +
> > +required properties:
> > + - hactive, vactive: display resolution
> > + - hfront-porch, hback-porch, hsync-len: horizontal display timing parameters
> > + in pixels
> > + vfront-porch, vback-porch, vsync-len: vertical display timing parameters in
> > + lines
> > + - clock-frequency: display clock in Hz
> > +
> > +optional properties:
> > + - hsync-active: hsync pulse is active low/high/ignored
> > + - vsync-active: vsync pulse is active low/high/ignored
> > + - de-active: data-enable pulse is active low/high/ignored
> > + - pixelclk-inverted: pixelclock is inverted (active on falling edge)/
> > + non-inverted (active on rising edge)/
> > + ignored (ignore property)
>
> I think hsync-active and vsync-active are clear, and commonly used, and
> they are used for both drm and fb mode conversions in later patches.
>
> de-active is not used in drm and fb mode conversions, but I think it's
> also clear.
>
> pixelclk-inverted is not used in the mode conversions. It's also a bit
> unclear to me. What does it mean that pix clock is "active on rising
> edge"? The pixel data is driven on rising edge? How about the sync
> signals and DE, when are they driven? Does your HW have any settings
> related to those?
>
Those are properties commonly found in display specs. That is why they are here.
If the GPU does not support the property it can be omitted.
> OMAP has the invert pclk setting, but it also has a setting to define
> when the sync signals are driven. The options are:
> - syncs are driven on rising edge of pclk
> - syncs are driven on falling edge of pclk
> - syncs are driven on the opposite edge of pclk compared to the pixel data
>
> For DE there's no setting, except the active high/low.
>
> And if I'm not mistaken, if the optional properties are not defined,
> they are not ignored, but left to the default 0. Which means active low,
> or active on rising edge(?). I think it would be good to have a
> "undefined" value for the properties.
>
Yes. As mentioned in my other mail, the intention of the omitted properties do
not propagate properly. Omitted must be a value < 0, so it is clear in a later
stage, that this property shall not be used. And isn't unintentionally considered
to be active low.
> > + - interlaced (bool): boolean to enable interlaced mode
> > + - doublescan (bool): boolean to enable doublescan mode
> > + - doubleclk (bool)
>
> As I mentioned in the other mail, doubleclk is not used nor documented here.
>
Yes. Rebase mistake I overlooked.
> > +All the optional properties that are not bool follow the following logic:
> > + <1>: high active
> > + <0>: low active
> > + omitted: not used on hardware
> > +
> > +There are different ways of describing the capabilities of a display. The devicetree
> > +representation corresponds to the one commonly found in datasheets for displays.
> > +If a display supports multiple signal timings, the native-mode can be specified.
>
> I have some of the same concerns for this series than with the
> interpreted power sequences (on fbdev): when you publish the DT
> bindings, it's somewhat final version then, and fixing it later will be
> difficult. Of course, video modes are much clearer than the power
> sequences, so it's possible there won't be any problems with the DT
> bindings.
>
The binding is pretty much at the bare minimum after a lot of discussion about
the properties. Even if the binding changes, I think it will rather grow than
shrink. Take the doubleclock property for example. It got here mistakingly,
because we had a display that has this feature.
> However, I'd still feel safer if the series would be split to non-DT and
> DT parts. The non-DT parts could be merged quite easily, and people
> could start using them in their kernels. This should expose
> bugs/problems related to the code.
>
> The DT part could be merged later, when there's confidence that the
> timings are good for all platforms.
>
> Or, alternatively, all the non-common bindings (de-active, pck
> invert,...) that are not used for fbdev or drm currently could be left
> out for now. But I'd stil prefer merging it in two parts.
I don't say that I'm against it, but the whole reason for the series was
getting the display timings from a DT into a graphics driver. And I think
I remember seeing some other attempts at achieving this, but all specific
to one special case. There is even already a mainline driver that uses an older
version of the DT bindings (vt8500-fb).
Regards,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCHv15 2/7] video: add display_timing and videomode
From: Steffen Trumtrar @ 2012-11-26 15:39 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree-discuss, Rob Herring, linux-fbdev, dri-devel,
Laurent Pinchart, Thierry Reding, Guennady Liakhovetski,
linux-media, Stephen Warren, kernel, Florian Tobias Schandinat,
David Airlie
In-Reply-To: <50B36286.7010704@ti.com>
On Mon, Nov 26, 2012 at 02:37:26PM +0200, Tomi Valkeinen wrote:
> On 2012-11-26 11:07, Steffen Trumtrar wrote:
>
> > +/*
> > + * Subsystem independent description of a videomode.
> > + * Can be generated from struct display_timing.
> > + */
> > +struct videomode {
> > + u32 pixelclock; /* pixelclock in Hz */
>
> I don't know if this is of any importance, but the linux clock framework
> manages clock rates with unsigned long. Would it be better to use the
> same type here?
>
Hm, I don't know. Anyone? u32 should be large enough for a pixelclock.
> > + u32 hactive;
> > + u32 hfront_porch;
> > + u32 hback_porch;
> > + u32 hsync_len;
> > +
> > + u32 vactive;
> > + u32 vfront_porch;
> > + u32 vback_porch;
> > + u32 vsync_len;
> > +
> > + u32 hah; /* hsync active high */
> > + u32 vah; /* vsync active high */
> > + u32 de; /* data enable */
> > + u32 pixelclk_pol;
>
> What values will these 4 have? Aren't these booleans?
>
> The data enable comment should be "data enable active high".
>
> The next patch says in the devtree binding documentation that the values
> may be on/off/ignored. Is that represented here somehow, i.e. values are
> 0/1/2 or so? If not, what does it mean if the value is left out from
> devtree data, meaning "not used on hardware"?
>
Hm, I think you might be right here. It is no problem in the DT part of the code.
The properties are optional, left out means "not used on hardware".
But this does not propagate correctly to the videomode. I should set the fields
to -EINVAL in case they are omitted, than everything should work nicely.
> There's also a "doubleclk" value mentioned in the devtree bindings doc,
> but not shown here.
>
Argh. That slipped through. I have patches that add this property to all
structs and the devicetree binding. But it is not supposed to be in this
series, because I want to at least have the binding stable for now.
> I think this videomode struct is the one that display drivers are going
> to use (?), in addition to the display_timing, so it would be good to
> document it well.
>
Yes. Maybe I have to put more of the devicetree documentation in the code.
Regards,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCHv9 1/3] Runtime Interpreted Power Sequences
From: Grant Likely @ 2012-11-26 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121122214021.GA14771@avionic-0098.adnet.avionic-design.de>
On Thu, 22 Nov 2012 22:40:21 +0100, Thierry Reding <thierry.reding@avionic-design.de> wrote:
> On Thu, Nov 22, 2012 at 01:39:41PM +0000, Grant Likely wrote:
> [...]
> > I do think that each sequence should be contained within a single
> > property, but I'm open to other suggestions.
>
> IIRC a very early prototype did implement something like that. However
> because of the resource issues this had to be string based, so that the
> sequences looked somewhat like (Alex, correct me if I'm wrong):
>
> power-on = <"REGULATOR", "power", 1, "GPIO", "enable", 1>;
>
> Instead we could possibly have something like:
>
> power-on = <0 ® 1,
> 1 &gpio 42 0 1>;
Yes, that would work, although I still think it would be a good idea to
split the used resources off into the gpios/pwms/regs/etc properties.
> Where the first cell in each entry defines the type (0 = regulator, 1 > GPIO) and the rest would be a regular OF specifier for the given type of
> resource along with some defined parameter such as enable/disable,
> voltage, delay in ms, ... I don't know if that sounds any better. It
> looks sort of cryptic but it is more "in the spirit of" DT, right Grant?
It is still kind of a ham-handed approach, but it does fit better with
existing conventions than the hierarchy of nodes does.
g.
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Alan Cox @ 2012-11-26 14:47 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Thierry Reding, Thomas Petazzoni, linux-fbdev, Benjamin Gaignard,
Tom Gall, Kyungmin Park, dri-devel, Rob Clark,
Ragesh Radhakrishnan, Laurent Pinchart, Philipp Zabel, Bryan Wu,
Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec,
linux-media
In-Reply-To: <50B07427.1010605@ti.com>
On Sat, 24 Nov 2012 09:15:51 +0200
Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 2012-11-23 21:56, Thierry Reding wrote:
> > On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote:
> > [...]
> >> Display entities are accessed by driver using notifiers. Any driver can
> >> register a display entity notifier with the CDF, which then calls the notifier
> >> when a matching display entity is registered.
The framebuffer layer has some similar 'anyone can' type notifier
behaviour and its not a good thing. That kind of "any one can" behaviour
leads to some really horrible messes unless the connections and the
locking are well defined IMHO.
Alan
^ permalink raw reply
* Re: [PATCHv15 3/7] video: add of helper for display timings/videomode
From: Tomi Valkeinen @ 2012-11-26 14:38 UTC (permalink / raw)
To: Steffen Trumtrar
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
David Airlie, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
Florian Tobias Schandinat,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Laurent Pinchart,
Philipp Zabel, Guennady Liakhovetski,
linux-media-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1353920848-1705-4-git-send-email-s.trumtrar-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 5997 bytes --]
Hi,
On 2012-11-26 11:07, Steffen Trumtrar wrote:
> This adds support for reading display timings from DT into a struct
> display_timings. The of_display_timing implementation supports multiple
> subnodes. All children are read into an array, that can be queried.
>
> If no native mode is specified, the first subnode will be used.
>
> For cases where the graphics driver knows there can be only one
> mode description or where the driver only supports one mode, a helper
> function of_get_videomode is added, that gets a struct videomode from DT.
>
> Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> Acked-by: Stephen Warren <swarren@nvidia.com>
> Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
> Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
> Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
> Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> .../devicetree/bindings/video/display-timing.txt | 107 ++++++++++
> drivers/video/Kconfig | 15 ++
> drivers/video/Makefile | 2 +
> drivers/video/of_display_timing.c | 219 ++++++++++++++++++++
> drivers/video/of_videomode.c | 54 +++++
> include/linux/of_display_timing.h | 20 ++
> include/linux/of_videomode.h | 18 ++
> 7 files changed, 435 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/display-timing.txt
> create mode 100644 drivers/video/of_display_timing.c
> create mode 100644 drivers/video/of_videomode.c
> create mode 100644 include/linux/of_display_timing.h
> create mode 100644 include/linux/of_videomode.h
>
> diff --git a/Documentation/devicetree/bindings/video/display-timing.txt b/Documentation/devicetree/bindings/video/display-timing.txt
> new file mode 100644
> index 0000000..e238f27
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/display-timing.txt
> @@ -0,0 +1,107 @@
> +display-timing bindings
> +=======================
> +
> +display-timings node
> +--------------------
> +
> +required properties:
> + - none
> +
> +optional properties:
> + - native-mode: The native mode for the display, in case multiple modes are
> + provided. When omitted, assume the first node is the native.
> +
> +timing subnode
> +--------------
> +
> +required properties:
> + - hactive, vactive: display resolution
> + - hfront-porch, hback-porch, hsync-len: horizontal display timing parameters
> + in pixels
> + vfront-porch, vback-porch, vsync-len: vertical display timing parameters in
> + lines
> + - clock-frequency: display clock in Hz
> +
> +optional properties:
> + - hsync-active: hsync pulse is active low/high/ignored
> + - vsync-active: vsync pulse is active low/high/ignored
> + - de-active: data-enable pulse is active low/high/ignored
> + - pixelclk-inverted: pixelclock is inverted (active on falling edge)/
> + non-inverted (active on rising edge)/
> + ignored (ignore property)
I think hsync-active and vsync-active are clear, and commonly used, and
they are used for both drm and fb mode conversions in later patches.
de-active is not used in drm and fb mode conversions, but I think it's
also clear.
pixelclk-inverted is not used in the mode conversions. It's also a bit
unclear to me. What does it mean that pix clock is "active on rising
edge"? The pixel data is driven on rising edge? How about the sync
signals and DE, when are they driven? Does your HW have any settings
related to those?
OMAP has the invert pclk setting, but it also has a setting to define
when the sync signals are driven. The options are:
- syncs are driven on rising edge of pclk
- syncs are driven on falling edge of pclk
- syncs are driven on the opposite edge of pclk compared to the pixel data
For DE there's no setting, except the active high/low.
And if I'm not mistaken, if the optional properties are not defined,
they are not ignored, but left to the default 0. Which means active low,
or active on rising edge(?). I think it would be good to have a
"undefined" value for the properties.
> + - interlaced (bool): boolean to enable interlaced mode
> + - doublescan (bool): boolean to enable doublescan mode
> + - doubleclk (bool)
As I mentioned in the other mail, doubleclk is not used nor documented here.
> +All the optional properties that are not bool follow the following logic:
> + <1>: high active
> + <0>: low active
> + omitted: not used on hardware
> +
> +There are different ways of describing the capabilities of a display. The devicetree
> +representation corresponds to the one commonly found in datasheets for displays.
> +If a display supports multiple signal timings, the native-mode can be specified.
I have some of the same concerns for this series than with the
interpreted power sequences (on fbdev): when you publish the DT
bindings, it's somewhat final version then, and fixing it later will be
difficult. Of course, video modes are much clearer than the power
sequences, so it's possible there won't be any problems with the DT
bindings.
However, I'd still feel safer if the series would be split to non-DT and
DT parts. The non-DT parts could be merged quite easily, and people
could start using them in their kernels. This should expose
bugs/problems related to the code.
The DT part could be merged later, when there's confidence that the
timings are good for all platforms.
Or, alternatively, all the non-common bindings (de-active, pck
invert,...) that are not used for fbdev or drm currently could be left
out for now. But I'd stil prefer merging it in two parts.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCHv15 2/7] video: add display_timing and videomode
From: Tomi Valkeinen @ 2012-11-26 12:37 UTC (permalink / raw)
To: Steffen Trumtrar
Cc: devicetree-discuss, Rob Herring, linux-fbdev, dri-devel,
Laurent Pinchart, Thierry Reding, Guennady Liakhovetski,
linux-media, Stephen Warren, kernel, Florian Tobias Schandinat,
David Airlie
In-Reply-To: <1353920848-1705-3-git-send-email-s.trumtrar@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1378 bytes --]
On 2012-11-26 11:07, Steffen Trumtrar wrote:
> +/*
> + * Subsystem independent description of a videomode.
> + * Can be generated from struct display_timing.
> + */
> +struct videomode {
> + u32 pixelclock; /* pixelclock in Hz */
I don't know if this is of any importance, but the linux clock framework
manages clock rates with unsigned long. Would it be better to use the
same type here?
> + u32 hactive;
> + u32 hfront_porch;
> + u32 hback_porch;
> + u32 hsync_len;
> +
> + u32 vactive;
> + u32 vfront_porch;
> + u32 vback_porch;
> + u32 vsync_len;
> +
> + u32 hah; /* hsync active high */
> + u32 vah; /* vsync active high */
> + u32 de; /* data enable */
> + u32 pixelclk_pol;
What values will these 4 have? Aren't these booleans?
The data enable comment should be "data enable active high".
The next patch says in the devtree binding documentation that the values
may be on/off/ignored. Is that represented here somehow, i.e. values are
0/1/2 or so? If not, what does it mean if the value is left out from
devtree data, meaning "not used on hardware"?
There's also a "doubleclk" value mentioned in the devtree bindings doc,
but not shown here.
I think this videomode struct is the one that display drivers are going
to use (?), in addition to the display_timing, so it would be good to
document it well.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH 1/5] backlight: Add GPIO-based backlight driver
From: Laurent Pinchart @ 2012-11-26 11:59 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Laurent Pinchart, jg1.han, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, linux-sh@vger.kernel.org,
linux-fbdev@vger.kernel.org, Paul Mundt, Magnus Damm,
Richard Purdie, Kuninori Morimoto
In-Reply-To: <50B347F4.2080705@metafoo.de>
Hi Lars-Peter,
On Monday 26 November 2012 11:44:04 Lars-Peter Clausen wrote:
> On 11/26/2012 10:49 AM, Jingoo Han wrote:
> > On Saturday, November 24, 2012 1:35 AM, Laurent Pinchart wrote
>
> [...]
>
> >> +static int gpio_backlight_check_fb(struct backlight_device *bl,
> >> + struct fb_info *info)
> >> +{
> >> + struct gpio_backlight *gbl = bl_get_data(bl);
> >> +
> >> + return gbl->fbdev = info->dev;
>
> I think it makes sense to return true if fbdev is NULL, to provide a simple
> fallback for systems with only one framebuffer device.
Agreed, I'll change that.
> >> +}
> >> +
>
> [...]
>
> >> +#ifdef CONFIG_PM
> >> +static int gpio_backlight_suspend(struct device *dev)
> >> +{
> >> + struct backlight_device *bl = dev_get_drvdata(dev);
> >> + struct gpio_backlight *gbl = bl_get_data(bl);
> >> +
> >> + gpio_set_value(gbl->gpio, !gbl->active);
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static int gpio_backlight_resume(struct device *dev)
> >> +{
> >> + struct backlight_device *bl = dev_get_drvdata(dev);
> >> +
> >> + backlight_update_status(bl);
> >> + return 0;
> >> +}
>
> If you use BL_CORE_SUSPENDRESUME you can get rid of the custom
> suspend/resume handlers.
Good point, I'll do that.
> >> +
> >> +static SIMPLE_DEV_PM_OPS(gpio_backlight_pm_ops, gpio_backlight_suspend,
> >> + gpio_backlight_resume);
> >> +
> >> +#endif
> >> +
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCHv9 1/3] Runtime Interpreted Power Sequences
From: Alex Courbot @ 2012-11-26 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121122214021.GA14771@avionic-0098.adnet.avionic-design.de>
On Friday 23 November 2012 05:40:21 Thierry Reding wrote:
> On Thu, Nov 22, 2012 at 01:39:41PM +0000, Grant Likely wrote:
> [...]
>
> > I do think that each sequence should be contained within a single
> > property, but I'm open to other suggestions.
>
> IIRC a very early prototype did implement something like that. However
> because of the resource issues this had to be string based, so that the
> sequences looked somewhat like (Alex, correct me if I'm wrong):
>
> power-on = <"REGULATOR", "power", 1, "GPIO", "enable", 1>;
You're right. Back when the burning sun of July was beating down a little bit
too hard on my head.
https://lkml.org/lkml/2012/7/9/30
> Instead we could possibly have something like:
>
> power-on = <0 ® 1,
> 1 &gpio 42 0 1>;
>
> Where the first cell in each entry defines the type (0 = regulator, 1 > GPIO) and the rest would be a regular OF specifier for the given type of
> resource along with some defined parameter such as enable/disable,
> voltage, delay in ms, ... I don't know if that sounds any better. It
> looks sort of cryptic but it is more "in the spirit of" DT, right Grant?
>
> Writing this down, it seems to me like even that proposal was already
> discussed at some point. Again, Alex may remember better.
The idea that we had was to use preprocessor support in DTC to use macros
instead of strings for the step type. We also thought about using phandles
directly in there as well, but this would require some more API support.
Anyway, at the current point we are not even sure whether we want or need
power seqs in the DT - so let's keep this topic on hold for a while. We can
still introduce the feature without DT support, and if it eventually turns out
during this winter that expressing power seqs in the DT makes sense, we will
have plenty of archives to read in front of the fire.
Alex.
^ permalink raw reply
* Re: [PATCH 1/5] backlight: Add GPIO-based backlight driver
From: Lars-Peter Clausen @ 2012-11-26 10:44 UTC (permalink / raw)
To: Laurent Pinchart
Cc: jg1.han, akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-sh@vger.kernel.org, linux-fbdev@vger.kernel.org, Paul Mundt,
Magnus Damm, Richard Purdie, Kuninori Morimoto
In-Reply-To: <32552643.33371353923376540.JavaMail.weblogic@epv6ml07>
On 11/26/2012 10:49 AM, Jingoo Han wrote:
> On Saturday, November 24, 2012 1:35 AM, Laurent Pinchart wrote
[...]
>> +static int gpio_backlight_check_fb(struct backlight_device *bl,
>> + struct fb_info *info)
>> +{
>> + struct gpio_backlight *gbl = bl_get_data(bl);
>> +
>> + return gbl->fbdev = info->dev;
I think it makes sense to return true if fbdev is NULL, to provide a simple
fallback for systems with only one framebuffer device.
>> +}
>> +
[...]
>> +#ifdef CONFIG_PM
>> +static int gpio_backlight_suspend(struct device *dev)
>> +{
>> + struct backlight_device *bl = dev_get_drvdata(dev);
>> + struct gpio_backlight *gbl = bl_get_data(bl);
>> +
>> + gpio_set_value(gbl->gpio, !gbl->active);
>> +
>> + return 0;
>> +}
>> +
>> +static int gpio_backlight_resume(struct device *dev)
>> +{
>> + struct backlight_device *bl = dev_get_drvdata(dev);
>> +
>> + backlight_update_status(bl);
>> + return 0;
>> +}
If you use BL_CORE_SUSPENDRESUME you can get rid of the custom
suspend/resume handlers.
>> +
>> +static SIMPLE_DEV_PM_OPS(gpio_backlight_pm_ops, gpio_backlight_suspend,
>> + gpio_backlight_resume);
>> +
>> +#endif
>> +
[...]
^ permalink raw reply
* Re: [PATCH 1/5] backlight: Add GPIO-based backlight driver
From: Laurent Pinchart @ 2012-11-26 10:25 UTC (permalink / raw)
To: jg1.han
Cc: Laurent Pinchart, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, linux-sh@vger.kernel.org,
linux-fbdev@vger.kernel.org, Paul Mundt, Magnus Damm,
Richard Purdie, Kuninori Morimoto
In-Reply-To: <32552643.33371353923376540.JavaMail.weblogic@epv6ml07>
Hi Jingoo,
On Monday 26 November 2012 09:49:36 Jingoo Han wrote:
> On Saturday, November 24, 2012 1:35 AM, Laurent Pinchart wrote
> >
> > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> CC'ed Andrew Morton
>
> It looks good. Also, I tested this patch with SMDK4210 board.
> Acked-by: Jingoo Han <jg1.han@samsung.com>
Thank you.
Unless Richard wants to take 1/5 and 2/5, I plan to push them through either
the Renesas ARM or Renesas SH tree with the board code patches.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 1/5] backlight: Add GPIO-based backlight driver
From: Jingoo Han @ 2012-11-26 9:49 UTC (permalink / raw)
To: Laurent Pinchart
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-sh@vger.kernel.org, linux-fbdev@vger.kernel.org, Paul Mundt,
Magnus Damm, Richard Purdie, Kuninori Morimoto, Jingoo Han
In-Reply-To: <1353688515-30458-2-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
T24gU2F0dXJkYXksIE5vdmVtYmVyIDI0LCAyMDEyIDE6MzUgQU0sIExhdXJlbnQgUGluY2hhcnQg
d3JvdGUNCj4gDQo+IFNpZ25lZC1vZmYtYnk6IExhdXJlbnQgUGluY2hhcnQgPGxhdXJlbnQucGlu
Y2hhcnRAaWRlYXNvbmJvYXJkLmNvbT4NCg0KQ0MnZWQgQW5kcmV3IE1vcnRvbg0KDQpJdCBsb29r
cyBnb29kLiBBbHNvLCBJIHRlc3RlZCB0aGlzIHBhdGNoIHdpdGggU01ESzQyMTAgYm9hcmQuDQpB
Y2tlZC1ieTogSmluZ29vIEhhbiA8amcxLmhhbkBzYW1zdW5nLmNvbT4NCg0KQmVzdCByZWdhcmRz
LA0KSmluZ29vIEhhbg0KDQo+IC0tLQ0KPiAgZHJpdmVycy92aWRlby9iYWNrbGlnaHQvS2NvbmZp
ZyAgICAgICAgICB8ICAgIDcgKysNCj4gIGRyaXZlcnMvdmlkZW8vYmFja2xpZ2h0L01ha2VmaWxl
ICAgICAgICAgfCAgICAxICsNCj4gIGRyaXZlcnMvdmlkZW8vYmFja2xpZ2h0L2dwaW9fYmFja2xp
Z2h0LmMgfCAgMTU4ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKw0KPiAgaW5jbHVkZS92
aWRlby9ncGlvX2JhY2tsaWdodC5oICAgICAgICAgICB8ICAgMjEgKysrKw0KPiAgNCBmaWxlcyBj
aGFuZ2VkLCAxODcgaW5zZXJ0aW9ucygrKSwgMCBkZWxldGlvbnMoLSkNCj4gIGNyZWF0ZSBtb2Rl
IDEwMDY0NCBkcml2ZXJzL3ZpZGVvL2JhY2tsaWdodC9ncGlvX2JhY2tsaWdodC5jDQo+ICBjcmVh
dGUgbW9kZSAxMDA2NDQgaW5jbHVkZS92aWRlby9ncGlvX2JhY2tsaWdodC5oDQo+IA0KPiBkaWZm
IC0tZ2l0IGEvZHJpdmVycy92aWRlby9iYWNrbGlnaHQvS2NvbmZpZyBiL2RyaXZlcnMvdmlkZW8v
YmFja2xpZ2h0L0tjb25maWcNCj4gaW5kZXggNzY1YTk0NS4uMjU5NDQyZCAxMDA2NDQNCj4gLS0t
IGEvZHJpdmVycy92aWRlby9iYWNrbGlnaHQvS2NvbmZpZw0KPiArKysgYi9kcml2ZXJzL3ZpZGVv
L2JhY2tsaWdodC9LY29uZmlnDQo+IEBAIC0zOTAsNiArMzkwLDEzIEBAIGNvbmZpZyBCQUNLTElH
SFRfVFBTNjUyMTcNCj4gIAkgIElmIHlvdSBoYXZlIGEgVGV4YXMgSW5zdHJ1bWVudHMgVFBTNjUy
MTcgc2F5IFkgdG8gZW5hYmxlIHRoZQ0KPiAgCSAgYmFja2xpZ2h0IGRyaXZlci4NCj4gDQo+ICtj
b25maWcgQkFDS0xJR0hUX0dQSU8NCj4gKwl0cmlzdGF0ZSAiR2VuZXJpYyBHUElPIGJhc2VkIEJh
Y2tsaWdodCBEcml2ZXIiDQo+ICsJZGVwZW5kcyBvbiBHRU5FUklDX0dQSU8NCj4gKwloZWxwDQo+
ICsJICBJZiB5b3UgaGF2ZSBhIExDRCBiYWNrbGlnaHQgYWRqdXN0YWJsZSBieSBHUElPLCBzYXkg
WSB0byBlbmFibGUNCj4gKwkgIHRoaXMgZHJpdmVyLg0KPiArDQo+ICBlbmRpZiAjIEJBQ0tMSUdI
VF9DTEFTU19ERVZJQ0UNCj4gDQo+ICBlbmRpZiAjIEJBQ0tMSUdIVF9MQ0RfU1VQUE9SVA0KPiBk
aWZmIC0tZ2l0IGEvZHJpdmVycy92aWRlby9iYWNrbGlnaHQvTWFrZWZpbGUgYi9kcml2ZXJzL3Zp
ZGVvL2JhY2tsaWdodC9NYWtlZmlsZQ0KPiBpbmRleCBlN2NlNzI5Li5lYzkxYzRhIDEwMDY0NA0K
PiAtLS0gYS9kcml2ZXJzL3ZpZGVvL2JhY2tsaWdodC9NYWtlZmlsZQ0KPiArKysgYi9kcml2ZXJz
L3ZpZGVvL2JhY2tsaWdodC9NYWtlZmlsZQ0KPiBAQCAtNDUsMyArNDUsNCBAQCBvYmotJChDT05G
SUdfQkFDS0xJR0hUX1BDRjUwNjMzKQkrPSBwY2Y1MDYzMy1iYWNrbGlnaHQubw0KPiAgb2JqLSQo
Q09ORklHX0JBQ0tMSUdIVF9BQVQyODcwKSArPSBhYXQyODcwX2JsLm8NCj4gIG9iai0kKENPTkZJ
R19CQUNLTElHSFRfT1QyMDApICs9IG90MjAwX2JsLm8NCj4gIG9iai0kKENPTkZJR19CQUNLTElH
SFRfVFBTNjUyMTcpICs9IHRwczY1MjE3X2JsLm8NCj4gK29iai0kKENPTkZJR19CQUNLTElHSFRf
R1BJTykJKz0gZ3Bpb19iYWNrbGlnaHQubw0KPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy92aWRlby9i
YWNrbGlnaHQvZ3Bpb19iYWNrbGlnaHQuYyBiL2RyaXZlcnMvdmlkZW8vYmFja2xpZ2h0L2dwaW9f
YmFja2xpZ2h0LmMNCj4gbmV3IGZpbGUgbW9kZSAxMDA2NDQNCj4gaW5kZXggMDAwMDAwMC4uNWE4
Y2QzNA0KPiAtLS0gL2Rldi9udWxsDQo+ICsrKyBiL2RyaXZlcnMvdmlkZW8vYmFja2xpZ2h0L2dw
aW9fYmFja2xpZ2h0LmMNCj4gQEAgLTAsMCArMSwxNTggQEANCj4gKy8qDQo+ICsgKiBncGlvX2Jh
Y2tsaWdodC5jIC0gU2ltcGxlIEdQSU8tY29udHJvbGxlZCBiYWNrbGlnaHQNCj4gKyAqDQo+ICsg
KiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQg
YW5kL29yIG1vZGlmeQ0KPiArICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJh
bCBQdWJsaWMgTGljZW5zZSB2ZXJzaW9uIDIgYXMNCj4gKyAqIHB1Ymxpc2hlZCBieSB0aGUgRnJl
ZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLg0KPiArICovDQo+ICsNCj4gKyNpbmNsdWRlIDxsaW51eC9i
YWNrbGlnaHQuaD4NCj4gKyNpbmNsdWRlIDxsaW51eC9lcnIuaD4NCj4gKyNpbmNsdWRlIDxsaW51
eC9mYi5oPg0KPiArI2luY2x1ZGUgPGxpbnV4L2dwaW8uaD4NCj4gKyNpbmNsdWRlIDxsaW51eC9p
bml0Lmg+DQo+ICsjaW5jbHVkZSA8bGludXgva2VybmVsLmg+DQo+ICsjaW5jbHVkZSA8bGludXgv
bW9kdWxlLmg+DQo+ICsjaW5jbHVkZSA8bGludXgvcGxhdGZvcm1fZGV2aWNlLmg+DQo+ICsjaW5j
bHVkZSA8bGludXgvc2xhYi5oPg0KPiArI2luY2x1ZGUgPHZpZGVvL2dwaW9fYmFja2xpZ2h0Lmg+
DQo+ICsNCj4gK3N0cnVjdCBncGlvX2JhY2tsaWdodCB7DQo+ICsJc3RydWN0IGRldmljZSAqZGV2
Ow0KPiArCXN0cnVjdCBkZXZpY2UgKmZiZGV2Ow0KPiArDQo+ICsJaW50IGdwaW87DQo+ICsJaW50
IGFjdGl2ZTsNCj4gK307DQo+ICsNCj4gK3N0YXRpYyBpbnQgZ3Bpb19iYWNrbGlnaHRfdXBkYXRl
X3N0YXR1cyhzdHJ1Y3QgYmFja2xpZ2h0X2RldmljZSAqYmwpDQo+ICt7DQo+ICsJc3RydWN0IGdw
aW9fYmFja2xpZ2h0ICpnYmwgPSBibF9nZXRfZGF0YShibCk7DQo+ICsJaW50IGJyaWdodG5lc3Mg
PSBibC0+cHJvcHMuYnJpZ2h0bmVzczsNCj4gKw0KPiArCWlmIChibC0+cHJvcHMucG93ZXIgIT0g
RkJfQkxBTktfVU5CTEFOSyB8fA0KPiArCSAgICBibC0+cHJvcHMuZmJfYmxhbmsgIT0gRkJfQkxB
TktfVU5CTEFOSyB8fA0KPiArCSAgICBibC0+cHJvcHMuc3RhdGUgJiAoQkxfQ09SRV9TVVNQRU5E
RUQgfCBCTF9DT1JFX0ZCQkxBTkspKQ0KPiArCQlicmlnaHRuZXNzID0gMDsNCj4gKw0KPiArCWdw
aW9fc2V0X3ZhbHVlKGdibC0+Z3BpbywgYnJpZ2h0bmVzcyA/IGdibC0+YWN0aXZlIDogIWdibC0+
YWN0aXZlKTsNCj4gKw0KPiArCXJldHVybiAwOw0KPiArfQ0KPiArDQo+ICtzdGF0aWMgaW50IGdw
aW9fYmFja2xpZ2h0X2dldF9icmlnaHRuZXNzKHN0cnVjdCBiYWNrbGlnaHRfZGV2aWNlICpibCkN
Cj4gK3sNCj4gKwlyZXR1cm4gYmwtPnByb3BzLmJyaWdodG5lc3M7DQo+ICt9DQo+ICsNCj4gK3N0
YXRpYyBpbnQgZ3Bpb19iYWNrbGlnaHRfY2hlY2tfZmIoc3RydWN0IGJhY2tsaWdodF9kZXZpY2Ug
KmJsLA0KPiArCQkJCSAgIHN0cnVjdCBmYl9pbmZvICppbmZvKQ0KPiArew0KPiArCXN0cnVjdCBn
cGlvX2JhY2tsaWdodCAqZ2JsID0gYmxfZ2V0X2RhdGEoYmwpOw0KPiArDQo+ICsJcmV0dXJuIGdi
bC0+ZmJkZXYgPT0gaW5mby0+ZGV2Ow0KPiArfQ0KPiArDQo+ICtzdGF0aWMgY29uc3Qgc3RydWN0
IGJhY2tsaWdodF9vcHMgZ3Bpb19iYWNrbGlnaHRfb3BzID0gew0KPiArCS51cGRhdGVfc3RhdHVz
CT0gZ3Bpb19iYWNrbGlnaHRfdXBkYXRlX3N0YXR1cywNCj4gKwkuZ2V0X2JyaWdodG5lc3MJPSBn
cGlvX2JhY2tsaWdodF9nZXRfYnJpZ2h0bmVzcywNCj4gKwkuY2hlY2tfZmIJPSBncGlvX2JhY2ts
aWdodF9jaGVja19mYiwNCj4gK307DQo+ICsNCj4gKyNpZmRlZiBDT05GSUdfUE0NCj4gK3N0YXRp
YyBpbnQgZ3Bpb19iYWNrbGlnaHRfc3VzcGVuZChzdHJ1Y3QgZGV2aWNlICpkZXYpDQo+ICt7DQo+
ICsJc3RydWN0IGJhY2tsaWdodF9kZXZpY2UgKmJsID0gZGV2X2dldF9kcnZkYXRhKGRldik7DQo+
ICsJc3RydWN0IGdwaW9fYmFja2xpZ2h0ICpnYmwgPSBibF9nZXRfZGF0YShibCk7DQo+ICsNCj4g
KwlncGlvX3NldF92YWx1ZShnYmwtPmdwaW8sICFnYmwtPmFjdGl2ZSk7DQo+ICsNCj4gKwlyZXR1
cm4gMDsNCj4gK30NCj4gKw0KPiArc3RhdGljIGludCBncGlvX2JhY2tsaWdodF9yZXN1bWUoc3Ry
dWN0IGRldmljZSAqZGV2KQ0KPiArew0KPiArCXN0cnVjdCBiYWNrbGlnaHRfZGV2aWNlICpibCA9
IGRldl9nZXRfZHJ2ZGF0YShkZXYpOw0KPiArDQo+ICsJYmFja2xpZ2h0X3VwZGF0ZV9zdGF0dXMo
YmwpOw0KPiArCXJldHVybiAwOw0KPiArfQ0KPiArDQo+ICtzdGF0aWMgU0lNUExFX0RFVl9QTV9P
UFMoZ3Bpb19iYWNrbGlnaHRfcG1fb3BzLCBncGlvX2JhY2tsaWdodF9zdXNwZW5kLA0KPiArCQkJ
IGdwaW9fYmFja2xpZ2h0X3Jlc3VtZSk7DQo+ICsNCj4gKyNlbmRpZg0KPiArDQo+ICtzdGF0aWMg
aW50IF9fZGV2aW5pdCBncGlvX2JhY2tsaWdodF9wcm9iZShzdHJ1Y3QgcGxhdGZvcm1fZGV2aWNl
ICpwZGV2KQ0KPiArew0KPiArCXN0cnVjdCBncGlvX2JhY2tsaWdodF9wbGF0Zm9ybV9kYXRhICpw
ZGF0YSA9IHBkZXYtPmRldi5wbGF0Zm9ybV9kYXRhOw0KPiArCXN0cnVjdCBiYWNrbGlnaHRfcHJv
cGVydGllcyBwcm9wczsNCj4gKwlzdHJ1Y3QgYmFja2xpZ2h0X2RldmljZSAqYmw7DQo+ICsJc3Ry
dWN0IGdwaW9fYmFja2xpZ2h0ICpnYmw7DQo+ICsJaW50IHJldDsNCj4gKw0KPiArCWdibCA9IGRl
dm1fa3phbGxvYygmcGRldi0+ZGV2LCBzaXplb2YoKmdibCksIEdGUF9LRVJORUwpOw0KPiArCWlm
IChnYmwgPT0gTlVMTCkNCj4gKwkJcmV0dXJuIC1FTk9NRU07DQo+ICsNCj4gKwlnYmwtPmRldiA9
ICZwZGV2LT5kZXY7DQo+ICsNCj4gKwlpZiAoIXBkYXRhKSB7DQo+ICsJCWRldl9lcnIoJnBkZXYt
PmRldiwgImZhaWxlZCB0byBmaW5kIHBsYXRmb3JtIGRhdGFcbiIpOw0KPiArCQlyZXR1cm4gLUVO
T0RFVjsNCj4gKwl9DQo+ICsNCj4gKwlnYmwtPmZiZGV2ID0gcGRhdGEtPmZiZGV2Ow0KPiArCWdi
bC0+Z3BpbyA9IHBkYXRhLT5ncGlvOw0KPiArCWdibC0+YWN0aXZlID0gcGRhdGEtPmFjdGl2ZV9s
b3cgPyAwIDogMTsNCj4gKw0KPiArCXJldCA9IGRldm1fZ3Bpb19yZXF1ZXN0X29uZShnYmwtPmRl
diwgZ2JsLT5ncGlvLCBHUElPRl9ESVJfT1VULA0KPiArCQkJCSAgICBwZGF0YS0+bmFtZSk7DQo+
ICsJaWYgKHJldCA8IDApIHsNCj4gKwkJZGV2X2VycigmcGRldi0+ZGV2LCAidW5hYmxlIHRvIHJl
cXVlc3QgR1BJT1xuIik7DQo+ICsJCXJldHVybiByZXQ7DQo+ICsJfQ0KPiArDQo+ICsJbWVtc2V0
KCZwcm9wcywgMCwgc2l6ZW9mKHByb3BzKSk7DQo+ICsJcHJvcHMudHlwZSA9IEJBQ0tMSUdIVF9S
QVc7DQo+ICsJcHJvcHMubWF4X2JyaWdodG5lc3MgPSAxOw0KPiArCWJsID0gYmFja2xpZ2h0X2Rl
dmljZV9yZWdpc3RlcihkZXZfbmFtZSgmcGRldi0+ZGV2KSwgJnBkZXYtPmRldiwgZ2JsLA0KPiAr
CQkJCSAgICAgICAmZ3Bpb19iYWNrbGlnaHRfb3BzLCAmcHJvcHMpOw0KPiArCWlmIChJU19FUlIo
YmwpKSB7DQo+ICsJCWRldl9lcnIoJnBkZXYtPmRldiwgImZhaWxlZCB0byByZWdpc3RlciBiYWNr
bGlnaHRcbiIpOw0KPiArCQlyZXR1cm4gUFRSX0VSUihibCk7DQo+ICsJfQ0KPiArDQo+ICsJYmwt
PnByb3BzLmJyaWdodG5lc3MgPSBwZGF0YS0+ZGVmX3ZhbHVlOw0KPiArCWJhY2tsaWdodF91cGRh
dGVfc3RhdHVzKGJsKTsNCj4gKw0KPiArCXBsYXRmb3JtX3NldF9kcnZkYXRhKHBkZXYsIGJsKTsN
Cj4gKwlyZXR1cm4gMDsNCj4gK30NCj4gKw0KPiArc3RhdGljIGludCBfX2RldmV4aXQgZ3Bpb19i
YWNrbGlnaHRfcmVtb3ZlKHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UgKnBkZXYpDQo+ICt7DQo+ICsJ
c3RydWN0IGJhY2tsaWdodF9kZXZpY2UgKmJsID0gcGxhdGZvcm1fZ2V0X2RydmRhdGEocGRldik7
DQo+ICsNCj4gKwliYWNrbGlnaHRfZGV2aWNlX3VucmVnaXN0ZXIoYmwpOw0KPiArCXJldHVybiAw
Ow0KPiArfQ0KPiArDQo+ICtzdGF0aWMgc3RydWN0IHBsYXRmb3JtX2RyaXZlciBncGlvX2JhY2ts
aWdodF9kcml2ZXIgPSB7DQo+ICsJLmRyaXZlcgkJPSB7DQo+ICsJCS5uYW1lCQk9ICJncGlvLWJh
Y2tsaWdodCIsDQo+ICsJCS5vd25lcgkJPSBUSElTX01PRFVMRSwNCj4gKyNpZmRlZiBDT05GSUdf
UE0NCj4gKwkJLnBtCQk9ICZncGlvX2JhY2tsaWdodF9wbV9vcHMsDQo+ICsjZW5kaWYNCj4gKwl9
LA0KPiArCS5wcm9iZQkJPSBncGlvX2JhY2tsaWdodF9wcm9iZSwNCj4gKwkucmVtb3ZlCQk9IF9f
ZGV2ZXhpdF9wKGdwaW9fYmFja2xpZ2h0X3JlbW92ZSksDQo+ICt9Ow0KPiArDQo+ICttb2R1bGVf
cGxhdGZvcm1fZHJpdmVyKGdwaW9fYmFja2xpZ2h0X2RyaXZlcik7DQo+ICsNCj4gK01PRFVMRV9B
VVRIT1IoIkxhdXJlbnQgUGluY2hhcnQgPGxhdXJlbnQucGluY2hhcnRAaWRlYXNvbmJvYXJkLmNv
bT4iKTsNCj4gK01PRFVMRV9ERVNDUklQVElPTigiR1BJTy1iYXNlZCBCYWNrbGlnaHQgRHJpdmVy
Iik7DQo+ICtNT0RVTEVfTElDRU5TRSgiR1BMIik7DQo+ICtNT0RVTEVfQUxJQVMoInBsYXRmb3Jt
OmdwaW8tYmFja2xpZ2h0Iik7DQo+IGRpZmYgLS1naXQgYS9pbmNsdWRlL3ZpZGVvL2dwaW9fYmFj
a2xpZ2h0LmggYi9pbmNsdWRlL3ZpZGVvL2dwaW9fYmFja2xpZ2h0LmgNCj4gbmV3IGZpbGUgbW9k
ZSAxMDA2NDQNCj4gaW5kZXggMDAwMDAwMC4uNWFlMGQ5Yw0KPiAtLS0gL2Rldi9udWxsDQo+ICsr
KyBiL2luY2x1ZGUvdmlkZW8vZ3Bpb19iYWNrbGlnaHQuaA0KPiBAQCAtMCwwICsxLDIxIEBADQo+
ICsvKg0KPiArICogZ3Bpb19iYWNrbGlnaHQuaCAtIFNpbXBsZSBHUElPLWNvbnRyb2xsZWQgYmFj
a2xpZ2h0DQo+ICsgKg0KPiArICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBj
YW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkNCj4gKyAqIGl0IHVuZGVyIHRoZSB0ZXJt
cyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgdmVyc2lvbiAyIGFzDQo+ICsgKiBw
dWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbi4NCj4gKyAqLw0KPiArI2lm
bmRlZiBfX0dQSU9fQkFDS0xJR0hUX0hfXw0KPiArI2RlZmluZSBfX0dQSU9fQkFDS0xJR0hUX0hf
Xw0KPiArDQo+ICtzdHJ1Y3QgZGV2aWNlOw0KPiArDQo+ICtzdHJ1Y3QgZ3Bpb19iYWNrbGlnaHRf
cGxhdGZvcm1fZGF0YSB7DQo+ICsJc3RydWN0IGRldmljZSAqZmJkZXY7DQo+ICsJaW50IGdwaW87
DQo+ICsJaW50IGRlZl92YWx1ZTsNCj4gKwlib29sIGFjdGl2ZV9sb3c7DQo+ICsJY29uc3QgY2hh
ciAqbmFtZTsNCj4gK307DQo+ICsNCj4gKyNlbmRpZg0KPiAtLQ0KPiAxLjcuOC42DQo+IA0KPiAt
LQ0KPiBUbyB1bnN1YnNjcmliZSBmcm9tIHRoaXMgbGlzdDogc2VuZCB0aGUgbGluZSAidW5zdWJz
Y3JpYmUgbGludXgtZmJkZXYiIGluDQo+IHRoZSBib2R5IG9mIGEgbWVzc2FnZSB0byBtYWpvcmRv
bW9Admdlci5rZXJuZWwub3JnDQo+IE1vcmUgbWFqb3Jkb21vIGluZm8gYXQgIGh0dHA6Ly92Z2Vy
Lmtlcm5lbC5vcmcvbWFqb3Jkb21vLWluZm8uaHRtbA0K
^ 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