* Re: [PATCH 06/15] OMAPDSS: remove all old panel drivers
From: Archit Taneja @ 2013-08-29 14:20 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <521F555C.8090802@ti.com>
On Thursday 29 August 2013 07:36 PM, Tomi Valkeinen wrote:
> Hi,
>
> On 29/08/13 17:00, Archit Taneja wrote:
>> On Thursday 29 August 2013 07:01 PM, Tomi Valkeinen wrote:
>>> The board files now use the new panel drivers, making the old panel
>>> drivers obsolete.
>>>
>>> Remove the old panel drivers, Kconfig and Makefile entries, and the
>>> panels' platform data structs.
>>
>> Can we convert the picodlp driver to the new panel driver model, and
>> report it as broken for now?
>
> (please cut your quotes a bit, you just included some thousands of lines
> of code there =).
Oops, sure, will try to remember.
>
> We could, but I'm not sure what would be the point. The new picodlp
> would be (more or less) totally new driver, so we would still end up
> removing the old driver. We can as well add it later if we manage to get
> it working.
Okay. Let's do that then.
Archit
^ permalink raw reply
* Re: [PATCH 13/15] OMAPDSS: DSS: remove legacy dss bus support
From: Archit Taneja @ 2013-08-29 14:44 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1377783120-14001-14-git-send-email-tomi.valkeinen@ti.com>
On Thursday 29 August 2013 07:01 PM, Tomi Valkeinen wrote:
> With all the old panels removed and all the old panel model APIs removed
> from the DSS encoders, we can now remove the custom omapdss-bus which
> was used in the old panel model.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/dss/core.c | 279 +----------------------------------------
> drivers/video/omap2/dss/dss.h | 9 --
> include/video/omapdss.h | 6 -
> 3 files changed, 3 insertions(+), 291 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
> index 71e6a77..54f3320 100644
> --- a/drivers/video/omap2/dss/core.c
> +++ b/drivers/video/omap2/dss/core.c
> @@ -248,235 +248,6 @@ static struct platform_driver omap_dss_driver = {
> },
> };
>
> -/* BUS */
> -static int dss_bus_match(struct device *dev, struct device_driver *driver)
> -{
> - struct omap_dss_device *dssdev = to_dss_device(dev);
> -
> - DSSDBG("bus_match. dev %s/%s, drv %s\n",
> - dev_name(dev), dssdev->driver_name, driver->name);
> -
> - return strcmp(dssdev->driver_name, driver->name) = 0;
> -}
> -
> -static struct bus_type dss_bus_type = {
> - .name = "omapdss",
> - .match = dss_bus_match,
> -};
> -
> -static void dss_bus_release(struct device *dev)
> -{
> - DSSDBG("bus_release\n");
> -}
> -
> -static struct device dss_bus = {
> - .release = dss_bus_release,
> -};
> -
> -struct bus_type *dss_get_bus(void)
> -{
> - return &dss_bus_type;
> -}
> -
> -/* DRIVER */
> -static int dss_driver_probe(struct device *dev)
> -{
> - int r;
> - struct omap_dss_driver *dssdrv = to_dss_driver(dev->driver);
> - struct omap_dss_device *dssdev = to_dss_device(dev);
> -
> - DSSDBG("driver_probe: dev %s/%s, drv %s\n",
> - dev_name(dev), dssdev->driver_name,
> - dssdrv->driver.name);
> -
> - r = dssdrv->probe(dssdev);
> -
> - if (r) {
> - DSSERR("driver probe failed: %d\n", r);
> - return r;
> - }
> -
> - DSSDBG("probe done for device %s\n", dev_name(dev));
> -
> - dssdev->driver = dssdrv;
> -
> - return 0;
> -}
> -
> -static int dss_driver_remove(struct device *dev)
> -{
> - struct omap_dss_driver *dssdrv = to_dss_driver(dev->driver);
> - struct omap_dss_device *dssdev = to_dss_device(dev);
> -
> - DSSDBG("driver_remove: dev %s/%s\n", dev_name(dev),
> - dssdev->driver_name);
> -
> - dssdrv->remove(dssdev);
> -
> - dssdev->driver = NULL;
> -
> - return 0;
> -}
> -
> -static int omapdss_default_connect(struct omap_dss_device *dssdev)
> -{
> - struct omap_dss_device *out;
> - struct omap_overlay_manager *mgr;
> - int r;
> -
> - out = dssdev->output;
> -
> - if (out = NULL)
> - return -ENODEV;
> -
> - mgr = omap_dss_get_overlay_manager(out->dispc_channel);
> - if (!mgr)
> - return -ENODEV;
> -
> - r = dss_mgr_connect(mgr, out);
> - if (r)
> - return r;
> -
> - return 0;
> -}
> -
> -static void omapdss_default_disconnect(struct omap_dss_device *dssdev)
> -{
> - struct omap_dss_device *out;
> - struct omap_overlay_manager *mgr;
> -
> - out = dssdev->output;
> -
> - if (out = NULL)
> - return;
> -
> - mgr = out->manager;
> -
> - if (mgr = NULL)
> - return;
> -
> - dss_mgr_disconnect(mgr, out);
> -}
> -
> -int omap_dss_register_driver(struct omap_dss_driver *dssdriver)
> -{
> - dssdriver->driver.bus = &dss_bus_type;
> - dssdriver->driver.probe = dss_driver_probe;
> - dssdriver->driver.remove = dss_driver_remove;
> -
> - if (dssdriver->get_resolution = NULL)
> - dssdriver->get_resolution = omapdss_default_get_resolution;
> - if (dssdriver->get_recommended_bpp = NULL)
> - dssdriver->get_recommended_bpp > - omapdss_default_get_recommended_bpp;
> - if (dssdriver->get_timings = NULL)
> - dssdriver->get_timings = omapdss_default_get_timings;
> - if (dssdriver->connect = NULL)
> - dssdriver->connect = omapdss_default_connect;
> - if (dssdriver->disconnect = NULL)
> - dssdriver->disconnect = omapdss_default_disconnect;
> -
> - return driver_register(&dssdriver->driver);
> -}
> -EXPORT_SYMBOL(omap_dss_register_driver);
> -
> -void omap_dss_unregister_driver(struct omap_dss_driver *dssdriver)
> -{
> - driver_unregister(&dssdriver->driver);
> -}
> -EXPORT_SYMBOL(omap_dss_unregister_driver);
> -
> -/* DEVICE */
> -
> -static void omap_dss_dev_release(struct device *dev)
> -{
> - struct omap_dss_device *dssdev = to_dss_device(dev);
> - kfree(dssdev);
> -}
> -
> -static int disp_num_counter;
> -
> -struct omap_dss_device *dss_alloc_and_init_device(struct device *parent)
> -{
> - struct omap_dss_device *dssdev;
> -
> - dssdev = kzalloc(sizeof(*dssdev), GFP_KERNEL);
> - if (!dssdev)
> - return NULL;
> -
> - dssdev->old_dev.bus = &dss_bus_type;
> - dssdev->old_dev.parent = parent;
> - dssdev->old_dev.release = omap_dss_dev_release;
> - dev_set_name(&dssdev->old_dev, "display%d", disp_num_counter++);
> -
> - device_initialize(&dssdev->old_dev);
> -
> - return dssdev;
> -}
> -
> -int dss_add_device(struct omap_dss_device *dssdev)
> -{
> - dssdev->dev = &dssdev->old_dev;
> -
> - omapdss_register_display(dssdev);
> - return device_add(&dssdev->old_dev);
> -}
> -
> -void dss_put_device(struct omap_dss_device *dssdev)
> -{
> - put_device(&dssdev->old_dev);
> -}
> -
> -void dss_unregister_device(struct omap_dss_device *dssdev)
> -{
> - device_unregister(&dssdev->old_dev);
> - omapdss_unregister_display(dssdev);
> -}
> -
> -static int dss_unregister_dss_dev(struct device *dev, void *data)
> -{
> - struct omap_dss_device *dssdev = to_dss_device(dev);
> - dss_unregister_device(dssdev);
> - return 0;
> -}
> -
> -void dss_unregister_child_devices(struct device *parent)
> -{
> - device_for_each_child(parent, NULL, dss_unregister_dss_dev);
> -}
> -
> -void dss_copy_device_pdata(struct omap_dss_device *dst,
> - const struct omap_dss_device *src)
> -{
> - u8 *d = (u8 *)dst;
> - u8 *s = (u8 *)src;
> - size_t dsize = sizeof(struct device);
> -
> - memcpy(d + dsize, s + dsize, sizeof(struct omap_dss_device) - dsize);
> -}
> -
> -/* BUS */
> -static int __init omap_dss_bus_register(void)
> -{
> - int r;
> -
> - r = bus_register(&dss_bus_type);
> - if (r) {
> - DSSERR("bus register failed\n");
> - return r;
> - }
> -
> - dev_set_name(&dss_bus, "omapdss");
> - r = device_register(&dss_bus);
> - if (r) {
> - DSSERR("bus driver register failed\n");
> - bus_unregister(&dss_bus_type);
> - return r;
> - }
> -
> - return 0;
> -}
> -
> /* INIT */
> static int (*dss_output_drv_reg_funcs[])(void) __initdata = {
> #ifdef CONFIG_OMAP2_DSS_DSI
> @@ -553,6 +324,8 @@ static int __init omap_dss_register_drivers(void)
> dss_output_drv_loaded[i] = true;
> }
>
> + dss_initialized = true;
> +
> return 0;
>
> err_dispc:
> @@ -578,64 +351,18 @@ static void __exit omap_dss_unregister_drivers(void)
> platform_driver_unregister(&omap_dss_driver);
> }
>
> -#ifdef CONFIG_OMAP2_DSS_MODULE
> -static void omap_dss_bus_unregister(void)
> -{
> - device_unregister(&dss_bus);
> -
> - bus_unregister(&dss_bus_type);
> -}
> -
> static int __init omap_dss_init(void)
> {
> - int r;
> -
> - r = omap_dss_bus_register();
> - if (r)
> - return r;
> -
> - r = omap_dss_register_drivers();
> - if (r) {
> - omap_dss_bus_unregister();
> - return r;
> - }
> -
> - dss_initialized = true;
> -
> - return 0;
> + return omap_dss_register_drivers();
> }
>
> static void __exit omap_dss_exit(void)
> {
> omap_dss_unregister_drivers();
> -
> - omap_dss_bus_unregister();
> }
>
> module_init(omap_dss_init);
> module_exit(omap_dss_exit);
minor comment here, we could use
omap_dss_register_driver/unregister_driver for the module_init/exit
directly, the funcs omap_dss_init/ext don't seem to be doing much here.
Archit
^ permalink raw reply
* Re: [PATCH 00/15] OMAPDSS: remove old panel model code
From: Archit Taneja @ 2013-08-29 14:47 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1377783120-14001-1-git-send-email-tomi.valkeinen@ti.com>
On Thursday 29 August 2013 07:01 PM, Tomi Valkeinen wrote:
> Here's a series removing all the old panel model code from the omapdss driver.
> This series depends on the series that changes the board files to use the new
> panel drivers.
>
> There's nothing much special in this series, as it's mostly removing code that
> is not used. There are also related cleanups, like making functions static if
> they are no longer called from outside the file, and such.
>
> Tested on OMAP4 SDP, OMAP4 Panda, OMAP3 Beagle, OMAP3 Beagle xM.
>
> This series can also be found from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git 3.12/dss-legacy-removal
>
For the series:
Reviewed-by: Archit Taneja <archit@ti.com>
Acked-by: Archit Taneja <archit@ti.com>
Thanks,
Archit
^ permalink raw reply
* Re: [PATCH/RFC v3 06/19] video: display: OF support
From: Laurent Pinchart @ 2013-08-30 0:47 UTC (permalink / raw)
To: Philipp Zabel; +Cc: Laurent Pinchart, dri-devel, linux-fbdev, linux-media
In-Reply-To: <1377595851.4338.18.camel@pizza.hi.pengutronix.de>
Hi Philipp,
On Tuesday 27 August 2013 11:30:51 Philipp Zabel wrote:
> Hi Laurent,
>
> I have another small issue with the graph helpers below:
>
> Am Samstag, den 10.08.2013, 01:03 +0200 schrieb Laurent Pinchart:
> [...]
>
> > +/*
> > -------------------------------------------------------------------------
> > ---->
> > * Graph Helpers
> > */
> >
> > @@ -420,6 +599,161 @@ int display_entity_link_graph(struct device *dev,
> > struct list_head *entities)>
> > }
> > EXPORT_SYMBOL_GPL(display_entity_link_graph);
> >
> > +#ifdef CONFIG_OF
> > +
> > +static int display_of_entity_link_entity(struct device *dev,
> > + struct display_entity *entity,
> > + struct list_head *entities,
> > + struct display_entity *root)
> > +{
> > + u32 link_flags = MEDIA_LNK_FL_IMMUTABLE | MEDIA_LNK_FL_ENABLED;
> > + const struct device_node *node = entity->dev->of_node;
> > + struct media_entity *local = &entity->entity;
> > + struct device_node *ep = NULL;
> > + int ret = 0;
> > +
> > + dev_dbg(dev, "creating links for entity %s\n", local->name);
> > +
> > + while (1) {
> > + struct media_entity *remote = NULL;
> > + struct media_pad *remote_pad;
> > + struct media_pad *local_pad;
> > + struct display_of_link link;
> > + struct display_entity *ent;
> > + struct device_node *next;
> > +
> > + /* Get the next endpoint and parse its link. */
> > + next = display_of_get_next_endpoint(node, ep);
> > + if (next = NULL)
> > + break;
> > +
> > + of_node_put(ep);
> > + ep = next;
> > +
> > + dev_dbg(dev, "processing endpoint %s\n", ep->full_name);
> > +
> > + ret = display_of_parse_link(ep, &link);
> > + if (ret < 0) {
> > + dev_err(dev, "failed to parse link for %s\n",
> > + ep->full_name);
> > + continue;
> > + }
> > +
> > + /* Skip source pads, they will be processed from the other end of
> > + * the link.
> > + */
> > + if (link.local_port >= local->num_pads) {
> > + dev_err(dev, "invalid port number %u on %s\n",
> > + link.local_port, link.local_node->full_name);
> > + display_of_put_link(&link);
> > + ret = -EINVAL;
> > + break;
> > + }
> > +
> > + local_pad = &local->pads[link.local_port];
> > +
> > + if (local_pad->flags & MEDIA_PAD_FL_SOURCE) {
> > + dev_dbg(dev, "skipping source port %s:%u\n",
> > + link.local_node->full_name, link.local_port);
> > + display_of_put_link(&link);
> > + continue;
> > + }
> > +
> > + /* Find the remote entity. If not found, just skip the link as
> > + * it goes out of scope of the entities handled by the notifier.
> > + */
> > + list_for_each_entry(ent, entities, list) {
> > + if (ent->dev->of_node = link.remote_node) {
> > + remote = &ent->entity;
> > + break;
> > + }
> > + }
> > +
> > + if (root->dev->of_node = link.remote_node)
> > + remote = &root->entity;
> > +
> > + if (remote = NULL) {
> > + dev_dbg(dev, "no entity found for %s\n",
> > + link.remote_node->full_name);
> > + display_of_put_link(&link);
> > + continue;
> > + }
> > +
> > + if (link.remote_port >= remote->num_pads) {
> > + dev_err(dev, "invalid port number %u on %s\n",
> > + link.remote_port, link.remote_node->full_name);
> > + display_of_put_link(&link);
> > + ret = -EINVAL;
> > + break;
> > + }
> > +
> > + remote_pad = &remote->pads[link.remote_port];
> > +
> > + display_of_put_link(&link);
> > +
> > + /* Create the media link. */
> > + dev_dbg(dev, "creating %s:%u -> %s:%u link\n",
> > + remote->name, remote_pad->index,
> > + local->name, local_pad->index);
> > +
> > + ret = media_entity_create_link(remote, remote_pad->index,
> > + local, local_pad->index,
> > + link_flags);
> > + if (ret < 0) {
> > + dev_err(dev,
> > + "failed to create %s:%u -> %s:%u link\n",
> > + remote->name, remote_pad->index,
> > + local->name, local_pad->index);
> > + break;
> > + }
> > + }
> > +
> > + of_node_put(ep);
> > + return ret;
> > +}
> > +
> > +/**
> > + * display_of_entity_link_graph - Link all entities in a graph
> > + * @dev: device used to print debugging and error messages
> > + * @root: optional root display entity
> > + * @entities: list of display entities in the graph
> > + *
> > + * This function creates media controller links for all entities in a
> > graph + * based on the device tree graph representation. It relies on all
> > entities + * having been instantiated from the device tree.
> > + *
> > + * The list of entities is typically taken directly from a display
> > notifier + * done list. It will thus not include any display entity not
> > handled by the + * notifier, such as entities directly accessible by the
> > caller without going + * through the notification process. The optional
> > root entity parameter can be + * used to pass such a display entity and
> > include it in the graph. For all + * practical purpose the root entity is
> > handled is if it was part of the + * entities list.
> > + *
> > + * Return 0 on success or a negative error code otherwise.
> > + */
> > +int display_of_entity_link_graph(struct device *dev, struct list_head
> > *entities, + struct display_entity *root)
> > +{
> > + struct display_entity *entity;
> > + int ret;
> > +
> > + list_for_each_entry(entity, entities, list) {
> > + if (WARN_ON(entity->match->type != DISPLAY_ENTITY_BUS_DT))
> > + return -EINVAL;
> > +
> > + ret = display_of_entity_link_entity(dev, entity, entities,
> > + root);
> > + if (ret < 0)
> > + return ret;
> > + }
> > +
> > + return display_of_entity_link_entity(dev, root, entities, root);
> > +}
> > +EXPORT_SYMBOL_GPL(display_of_entity_link_graph);
>
> The root display entity given to display_of_entity_link_graph is documented
> to be optional. Therefore, do not try to dereference root if it is NULL:
Good catch ! I'll fix it in v4, thank you.
> diff --git a/drivers/video/display/display-core.c
> b/drivers/video/display/display-core.c index 328ead7..6c8094f 100644
> --- a/drivers/video/display/display-core.c
> +++ b/drivers/video/display/display-core.c
> @@ -669,7 +669,7 @@ static int display_of_entity_link_entity(struct device
> *dev, }
> }
>
> - if (root->dev->of_node = link.remote_node)
> + if (root && root->dev->of_node = link.remote_node)
> remote = &root->entity;
>
> if (remote = NULL) {
> @@ -748,6 +748,9 @@ int display_of_entity_link_graph(struct device *dev,
> struct list_head *entities, return ret;
> }
>
> + if (!root)
> + return 0;
> +
> return display_of_entity_link_entity(dev, root, entities, root);
> }
> EXPORT_SYMBOL_GPL(display_of_entity_link_graph);
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 13/15] OMAPDSS: DSS: remove legacy dss bus support
From: Tomi Valkeinen @ 2013-08-30 5:52 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <521F5B80.6080802@ti.com>
[-- Attachment #1: Type: text/plain, Size: 751 bytes --]
On 29/08/13 17:32, Archit Taneja wrote:
> On Thursday 29 August 2013 07:01 PM, Tomi Valkeinen wrote:
>> With all the old panels removed and all the old panel model APIs removed
>> from the DSS encoders, we can now remove the custom omapdss-bus which
>> was used in the old panel model.
>>
>> static void __exit omap_dss_exit(void)
>> {
>> omap_dss_unregister_drivers();
>> -
>> - omap_dss_bus_unregister();
>> }
>>
>> module_init(omap_dss_init);
>> module_exit(omap_dss_exit);
>
> minor comment here, we could use
> omap_dss_register_driver/unregister_driver for the module_init/exit
> directly, the funcs omap_dss_init/ext don't seem to be doing much here.
Yes, that's true. I'll clean it up.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 00/15] OMAPDSS: remove old panel model code
From: Tomi Valkeinen @ 2013-08-30 6:00 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <521F5C35.4040106@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]
On 29/08/13 17:35, Archit Taneja wrote:
> On Thursday 29 August 2013 07:01 PM, Tomi Valkeinen wrote:
>> Here's a series removing all the old panel model code from the omapdss
>> driver.
>> This series depends on the series that changes the board files to use
>> the new
>> panel drivers.
>>
>> There's nothing much special in this series, as it's mostly removing
>> code that
>> is not used. There are also related cleanups, like making functions
>> static if
>> they are no longer called from outside the file, and such.
>>
>> Tested on OMAP4 SDP, OMAP4 Panda, OMAP3 Beagle, OMAP3 Beagle xM.
>>
>> This series can also be found from:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git
>> 3.12/dss-legacy-removal
>>
>
> For the series:
>
> Reviewed-by: Archit Taneja <archit@ti.com>
> Acked-by: Archit Taneja <archit@ti.com>
Thanks for review. I've updated the branch in my git tree.
You may want to rebase your HDMI work on top of this branch at some point.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] video: exynos: Ensure definitions match prototypes
From: Tomi Valkeinen @ 2013-08-30 7:15 UTC (permalink / raw)
To: Mark Brown
Cc: Jingoo Han, linux-fbdev, linux-samsung-soc, linaro-kernel,
Mark Brown
In-Reply-To: <1372764414-9102-1-git-send-email-broonie@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 355 bytes --]
On 02/07/13 14:26, Mark Brown wrote:
> From: Mark Brown <broonie@linaro.org>
>
> Ensure that the definitions of functions match the prototypes used by
> other modules by including the header with the prototypes in the files
> with the definitions.
>
> Signed-off-by: Mark Brown <broonie@linaro.org>
Thanks, queued this for 3.12.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH v4 3/5] at91/avr32/atmel_lcdfb: prepare clk before calling enable
From: Tomi Valkeinen @ 2013-08-30 7:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1374133225-19141-1-git-send-email-b.brezillon@overkiz.com>
[-- Attachment #1: Type: text/plain, Size: 1225 bytes --]
On 18/07/13 10:40, Boris BREZILLON wrote:
> Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
> avoid common clk framework warnings.
>
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> drivers/video/atmel_lcdfb.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
> index ece49d5..bf9c5d0 100644
> --- a/drivers/video/atmel_lcdfb.c
> +++ b/drivers/video/atmel_lcdfb.c
> @@ -954,14 +954,14 @@ static int __init atmel_lcdfb_init_fbinfo(struct atmel_lcdfb_info *sinfo)
>
> static void atmel_lcdfb_start_clock(struct atmel_lcdfb_info *sinfo)
> {
> - clk_enable(sinfo->bus_clk);
> - clk_enable(sinfo->lcdc_clk);
> + clk_prepare_enable(sinfo->bus_clk);
> + clk_prepare_enable(sinfo->lcdc_clk);
> }
>
> static void atmel_lcdfb_stop_clock(struct atmel_lcdfb_info *sinfo)
> {
> - clk_disable(sinfo->bus_clk);
> - clk_disable(sinfo->lcdc_clk);
> + clk_disable_unprepare(sinfo->bus_clk);
> + clk_disable_unprepare(sinfo->lcdc_clk);
> }
>
> #ifdef CONFIG_OF
Thanks, queued this for 3.12.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] drivers: video: i740fb: add 'default' processing contents for 'switch'.
From: Tomi Valkeinen @ 2013-08-30 7:21 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <51ECF12D.8060903@asianux.com>
[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]
On 22/07/13 11:45, Chen Gang wrote:
> Need add related 'default' processing contents for 'switch', or may
> report 'wm' uninitialized warning.
>
> The related warning:
>
> drivers/video/i740fb.c:662:26: warning: ‘wm’ may be used uninitialized in this function [-Wmaybe-uninitialized]
>
>
> Signed-off-by: Chen Gang <gang.chen@asianux.com>
> ---
> drivers/video/i740fb.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/i740fb.c b/drivers/video/i740fb.c
> index 6c48388..e82e767 100644
> --- a/drivers/video/i740fb.c
> +++ b/drivers/video/i740fb.c
> @@ -336,6 +336,9 @@ static u32 i740_calc_fifo(struct i740fb_par *par, u32 freq, int bpp)
> wm = 0x16110000;
> }
> break;
> + default:
> + wm = 0;
> + BUG();
> }
I don't think you should use BUG there. BUG should be used when there's
not really a good way to continue. Here you could have just a WARN, and
return some default FIFO watermark value.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] Release efifb's colormap in efifb_destroy()
From: Tomi Valkeinen @ 2013-08-30 7:47 UTC (permalink / raw)
To: Peter Jones
Cc: Catalin Marinas, Alexandra N. Kossovsky, linux-fbdev,
linux-kernel
In-Reply-To: <1374767291-2874-1-git-send-email-pjones@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1930 bytes --]
On 25/07/13 18:48, Peter Jones wrote:
> This was found by Alexandra Kossovsky, who noted this traceback from
> kmemleak:
>
>> unreferenced object 0xffff880216fcfe00 (size 512):
>> comm "swapper/0", pid 1, jiffies 4294895429 (age 1415.320s)
>> hex dump (first 32 bytes):
>> 00 00 00 00 00 00 00 00 aa aa aa aa aa aa aa aa ................
>> 55 55 55 55 55 55 55 55 ff ff ff ff ff ff ff ff UUUUUUUU........
>> backtrace:
>> [<ffffffff813e415c>] kmemleak_alloc+0x21/0x3e
>> [<ffffffff8111c17f>]
>> kmemleak_alloc_recursive.constprop.57+0x16/0x18
>> [<ffffffff8111e63b>] __kmalloc+0xf9/0x144
>> [<ffffffff8123d9cf>] fb_alloc_cmap_gfp+0x47/0xe1
>> [<ffffffff8123da77>] fb_alloc_cmap+0xe/0x10
>> [<ffffffff81aff40a>] efifb_probe+0x3e9/0x48f
>> [<ffffffff812c566f>] platform_drv_probe+0x34/0x5e
>> [<ffffffff812c3e6d>] driver_probe_device+0x98/0x1b4
>> [<ffffffff812c3fd7>] __driver_attach+0x4e/0x6f
>> [<ffffffff812c25bf>] bus_for_each_dev+0x57/0x8a
>> [<ffffffff812c3984>] driver_attach+0x19/0x1b
>> [<ffffffff812c362b>] bus_add_driver+0xde/0x201
>> [<ffffffff812c453f>] driver_register+0x8c/0x110
>> [<ffffffff812c510d>] platform_driver_register+0x41/0x43
>> [<ffffffff812c5127>] platform_driver_probe+0x18/0x8a
>> [<ffffffff81aff002>] efifb_init+0x276/0x295
> ---
> drivers/video/efifb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/efifb.c b/drivers/video/efifb.c
> index 390b61b..1f3eab3 100644
> --- a/drivers/video/efifb.c
> +++ b/drivers/video/efifb.c
> @@ -289,6 +289,7 @@ static void efifb_destroy(struct fb_info *info)
> if (request_mem_succeeded)
> release_mem_region(info->apertures->ranges[0].base,
> info->apertures->ranges[0].size);
> + fb_dealloc_cmap(&info->cmap);
> framebuffer_release(info);
> }
>
Thanks, queued for 3.12.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 2/29] video: mxsfb: simplify use of devm_ioremap_resource
From: Tomi Valkeinen @ 2013-08-30 7:51 UTC (permalink / raw)
To: Julia Lawall
Cc: Jean-Christophe Plagniol-Villard, kernel-janitors, linux-fbdev,
linux-kernel
In-Reply-To: <1376471493-22215-3-git-send-email-Julia.Lawall@lip6.fr>
[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]
On 14/08/13 12:11, Julia Lawall wrote:
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> Remove unneeded error handling on the result of a call to
> platform_get_resource when the value is passed to devm_ioremap_resource.
>
> Move the call to platform_get_resource adjacent to the call to
> devm_ioremap_resource to make the connection between them more clear.
>
> A simplified version of the semantic patch that makes this change is as
> follows: (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @@
> expression pdev,res,n,e,e1;
> expression ret != 0;
> identifier l;
> @@
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, n);
> ... when != res
> - if (res == NULL) { ... \(goto l;\|return ret;\) }
> ... when != res
> + res = platform_get_resource(pdev, IORESOURCE_MEM, n);
> e = devm_ioremap_resource(e1, res);
> // </smpl>
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
>
> ---
> drivers/video/mxsfb.c | 7 +------
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
> index c2d3514..d250ed0 100644
> --- a/drivers/video/mxsfb.c
> +++ b/drivers/video/mxsfb.c
> @@ -855,12 +855,6 @@ static int mxsfb_probe(struct platform_device *pdev)
> if (of_id)
> pdev->id_entry = of_id->data;
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res) {
> - dev_err(&pdev->dev, "Cannot get memory IO resource\n");
> - return -ENODEV;
> - }
> -
> fb_info = framebuffer_alloc(sizeof(struct mxsfb_info), &pdev->dev);
> if (!fb_info) {
> dev_err(&pdev->dev, "Failed to allocate fbdev\n");
> @@ -869,6 +863,7 @@ static int mxsfb_probe(struct platform_device *pdev)
>
> host = to_imxfb_host(fb_info);
>
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> host->base = devm_ioremap_resource(&pdev->dev, res);
> if (IS_ERR(host->base)) {
> ret = PTR_ERR(host->base);
>
Thanks, queued for 3.12.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] omap2: panel-generic: Added panel parameters for ortus-com37h3m05dtc/99dtc and sharp-lq0
From: Tomi Valkeinen @ 2013-08-30 7:57 UTC (permalink / raw)
To: Marek Belisko
Cc: plagnioj, linux-omap, linux-fbdev, linux-kernel,
H. Nikolaus Schaller
In-Reply-To: <1377779724-30648-1-git-send-email-marek@goldelico.com>
[-- Attachment #1: Type: text/plain, Size: 862 bytes --]
On 29/08/13 15:35, Marek Belisko wrote:
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> Signed-off-by: Marek Belisko <marek@goldelico.com>
> ---
> drivers/video/omap2/displays/panel-generic-dpi.c | 53 ++++++++++++++++++++++++
> 1 file changed, 53 insertions(+)
>
> diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c b/drivers/video/omap2/displays/panel-generic-dpi.c
> index bebebd4..d573291 100644
> --- a/drivers/video/omap2/displays/panel-generic-dpi.c
> +++ b/drivers/video/omap2/displays/panel-generic-dpi.c
> @@ -107,6 +107,33 @@ static struct panel_config generic_dpi_panels[] = {
> .name = "sharp_ls",
> },
The drivers in drivers/video/omap2/displays/ are on their way out, and
will probably be removed for 3.12. Please look at the new one at
drivers/video/omap2/displays-new/panel-dpi.c.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] drivers: video: i740fb: add 'default' processing contents for 'switch'.
From: Chen Gang @ 2013-08-30 8:17 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <51ECF12D.8060903@asianux.com>
On 08/30/2013 03:21 PM, Tomi Valkeinen wrote:
> On 22/07/13 11:45, Chen Gang wrote:
>> Need add related 'default' processing contents for 'switch', or may
>> report 'wm' uninitialized warning.
>>
>> The related warning:
>>
>> drivers/video/i740fb.c:662:26: warning: �wm� may be used uninitialized in this function [-Wmaybe-uninitialized]
>>
>>
>> Signed-off-by: Chen Gang <gang.chen@asianux.com>
>> ---
>> drivers/video/i740fb.c | 3 +++
>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/video/i740fb.c b/drivers/video/i740fb.c
>> index 6c48388..e82e767 100644
>> --- a/drivers/video/i740fb.c
>> +++ b/drivers/video/i740fb.c
>> @@ -336,6 +336,9 @@ static u32 i740_calc_fifo(struct i740fb_par *par, u32 freq, int bpp)
>> wm = 0x16110000;
>> }
>> break;
>> + default:
>> + wm = 0;
>> + BUG();
>> }
>
> I don't think you should use BUG there. BUG should be used when there's
> not really a good way to continue. Here you could have just a WARN, and
> return some default FIFO watermark value.
>
i740_calc_fifo() is a static function, so we can check its caller's
information to find the suitable fixing ways (for extern function, we
almost can not do like this).
it has only one caller i740fb_decode_var(), which has already let 'bpp'
within the values (8, 15, 16, 24, 32). So if another values occurs, it
must be a BUG (e.g. the stack may override under ia32).
Hmm... it really has quite a few same cases in kernel wide like our
case, but at least they do not report warnings (this does not like our
case), so let just fix our case to satisfy the compiler. :-)
> Tomi
>
>
Thanks.
--
Chen Gang
^ permalink raw reply
* Re: [PATCH] drivers: video: i740fb: add 'default' processing contents for 'switch'.
From: Tomi Valkeinen @ 2013-08-30 8:36 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <51ECF12D.8060903@asianux.com>
[-- Attachment #1: Type: text/plain, Size: 976 bytes --]
On 30/08/13 11:17, Chen Gang wrote:
> On 08/30/2013 03:21 PM, Tomi Valkeinen wrote:
>> I don't think you should use BUG there. BUG should be used when there's
>> not really a good way to continue. Here you could have just a WARN, and
>> return some default FIFO watermark value.
>>
>
> i740_calc_fifo() is a static function, so we can check its caller's
> information to find the suitable fixing ways (for extern function, we
> almost can not do like this).
>
> it has only one caller i740fb_decode_var(), which has already let 'bpp'
> within the values (8, 15, 16, 24, 32). So if another values occurs, it
> must be a BUG (e.g. the stack may override under ia32).
My point was that there should almost never be need for BUG in a normal
driver. BUG means that the whole kernel will probably halt. Even if an
fb driver encounters a problem that should never happen, it should maybe
give a WARN, and continue or fail in a controlled manner.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH v2] drivers: video: fbcmap: remove the redundency and incorrect checkings
From: Tomi Valkeinen @ 2013-08-30 8:41 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <5212D594.3020802@asianux.com>
[-- Attachment #1: Type: text/plain, Size: 1088 bytes --]
On 20/08/13 05:33, Chen Gang wrote:
> fb_set_cmap() already checks the parameters, so need remove the
> redundancy checking.
>
> This redundancy checking is also incorrect, the related warning:
>
> drivers/video/fbcmap.c:288:2: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
>
>
> Signed-off-by: Chen Gang <gang.chen@asianux.com>
> ---
> drivers/video/fbcmap.c | 7 +------
> 1 files changed, 1 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/fbcmap.c b/drivers/video/fbcmap.c
> index 5c3960d..f89245b 100644
> --- a/drivers/video/fbcmap.c
> +++ b/drivers/video/fbcmap.c
> @@ -285,13 +285,8 @@ int fb_set_user_cmap(struct fb_cmap_user *cmap, struct fb_info *info)
> rc = -ENODEV;
> goto out;
> }
> - if (cmap->start < 0 || (!info->fbops->fb_setcolreg &&
> - !info->fbops->fb_setcmap)) {
> - rc = -EINVAL;
> - goto out1;
> - }
> +
> rc = fb_set_cmap(&umap, info);
> -out1:
> unlock_fb_info(info);
> out:
> fb_dealloc_cmap(&umap);
>
Thanks, queued this for 3.12.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] drivers: video: i740fb: add 'default' processing contents for 'switch'.
From: Chen Gang @ 2013-08-30 8:44 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <51ECF12D.8060903@asianux.com>
On 08/30/2013 04:36 PM, Tomi Valkeinen wrote:
> On 30/08/13 11:17, Chen Gang wrote:
>> On 08/30/2013 03:21 PM, Tomi Valkeinen wrote:
>
>>> I don't think you should use BUG there. BUG should be used when there's
>>> not really a good way to continue. Here you could have just a WARN, and
>>> return some default FIFO watermark value.
>>>
>>
>> i740_calc_fifo() is a static function, so we can check its caller's
>> information to find the suitable fixing ways (for extern function, we
>> almost can not do like this).
>>
>> it has only one caller i740fb_decode_var(), which has already let 'bpp'
>> within the values (8, 15, 16, 24, 32). So if another values occurs, it
>> must be a BUG (e.g. the stack may override under ia32).
>
> My point was that there should almost never be need for BUG in a normal
> driver. BUG means that the whole kernel will probably halt. Even if an
> fb driver encounters a problem that should never happen, it should maybe
> give a WARN, and continue or fail in a controlled manner.
>
e.g when the stack is override under ia32, it is better to stop continue
as soon as possible to try to avoid the kernel continue blindly, that
may let the coredump/KDB analyzers' work much easier.
Hmm... when driver cause issue, it has effect with the whole kernel
(kernel may die soon), so BUG() is used under the whole kernel wide
(include normal drivers).
> Tomi
>
>
Thanks.
--
Chen Gang
^ permalink raw reply
* Re: [PATCH] fbmem: move EXPORT_SYMBOL annotation next to symbol declarations
From: Tomi Valkeinen @ 2013-08-30 8:44 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1376575975-13215-1-git-send-email-zonque@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 335 bytes --]
On 15/08/13 17:12, Daniel Mack wrote:
> Just a cosmetic thing to bring that file in line with others in the
> tree.
>
> Signed-off-by: Daniel Mack <zonque@gmail.com>
> ---
> drivers/video/fbmem.c | 29 +++++++++++++----------------
> 1 file changed, 13 insertions(+), 16 deletions(-)
Thanks, queued for 3.12.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH v2] drivers: video: fbcmap: remove the redundency and incorrect checkings
From: Chen Gang @ 2013-08-30 8:47 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <5212D594.3020802@asianux.com>
On 08/30/2013 04:41 PM, Tomi Valkeinen wrote:
> On 20/08/13 05:33, Chen Gang wrote:
>> fb_set_cmap() already checks the parameters, so need remove the
>> redundancy checking.
>>
>> This redundancy checking is also incorrect, the related warning:
>>
>> drivers/video/fbcmap.c:288:2: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
>>
>>
>> Signed-off-by: Chen Gang <gang.chen@asianux.com>
>> ---
>> drivers/video/fbcmap.c | 7 +------
>> 1 files changed, 1 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/video/fbcmap.c b/drivers/video/fbcmap.c
>> index 5c3960d..f89245b 100644
>> --- a/drivers/video/fbcmap.c
>> +++ b/drivers/video/fbcmap.c
>> @@ -285,13 +285,8 @@ int fb_set_user_cmap(struct fb_cmap_user *cmap, struct fb_info *info)
>> rc = -ENODEV;
>> goto out;
>> }
>> - if (cmap->start < 0 || (!info->fbops->fb_setcolreg &&
>> - !info->fbops->fb_setcmap)) {
>> - rc = -EINVAL;
>> - goto out1;
>> - }
>> +
>> rc = fb_set_cmap(&umap, info);
>> -out1:
>> unlock_fb_info(info);
>> out:
>> fb_dealloc_cmap(&umap);
>>
>
> Thanks, queued this for 3.12.
>
Thank you too.
> Tomi
>
>
--
Chen Gang
^ permalink raw reply
* Re: [PATCH] drivers: video: i740fb: add 'default' processing contents for 'switch'.
From: Tomi Valkeinen @ 2013-08-30 9:16 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <51ECF12D.8060903@asianux.com>
[-- Attachment #1: Type: text/plain, Size: 2757 bytes --]
On 30/08/13 11:44, Chen Gang wrote:
> On 08/30/2013 04:36 PM, Tomi Valkeinen wrote:
>> On 30/08/13 11:17, Chen Gang wrote:
>>> On 08/30/2013 03:21 PM, Tomi Valkeinen wrote:
>>
>>>> I don't think you should use BUG there. BUG should be used when there's
>>>> not really a good way to continue. Here you could have just a WARN, and
>>>> return some default FIFO watermark value.
>>>>
>>>
>>> i740_calc_fifo() is a static function, so we can check its caller's
>>> information to find the suitable fixing ways (for extern function, we
>>> almost can not do like this).
>>>
>>> it has only one caller i740fb_decode_var(), which has already let 'bpp'
>>> within the values (8, 15, 16, 24, 32). So if another values occurs, it
>>> must be a BUG (e.g. the stack may override under ia32).
>>
>> My point was that there should almost never be need for BUG in a normal
>> driver. BUG means that the whole kernel will probably halt. Even if an
>> fb driver encounters a problem that should never happen, it should maybe
>> give a WARN, and continue or fail in a controlled manner.
>>
>
> e.g when the stack is override under ia32, it is better to stop continue
> as soon as possible to try to avoid the kernel continue blindly, that
> may let the coredump/KDB analyzers' work much easier.
>
> Hmm... when driver cause issue, it has effect with the whole kernel
> (kernel may die soon), so BUG() is used under the whole kernel wide
> (include normal drivers).
You want i740_calc_fifo() to check the bpp parameter and issue a BUG if
it's not a valid bpp-value, because in the current driver
i740_calc_fifo() is never called with a non-valid bpp, and thus a wrong
bpp indicates a stack corruption?
How about the freq parameter? In the current driver freq can never be
higher than 1000000. If it is, it's stack corruption. Maybe there should
be a BUG for that case also?
As I see it, you're just checking a single arbitrary value in an
arbitrary place in the driver, and protecting against stack corruption
there. Why not check all the values in all the functions of the driver
as well, looking for stack corruptions?
And the bigger issue is that you're only talking about the current
driver. The driver could be changed tomorrow, maybe calling
i740_calc_fifo() from some other place, where a wrong bpp could just
possibly happen. In that case it wouldn't be a stack corruption, but a
"normal" driver bug.
So, in my opinion:
- Normally we should presume the the stack is not corrupted, or
otherwise we'll end up with lots of checks all over.
- Even if i740_calc_fifo() is a static function, and we can analyze the
_current_ situation, we don't know how the driver will evolve in the future.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 6/7] video: xilinxfb: replace devm_request_and_ioremap by devm_ioremap_resource
From: Tomi Valkeinen @ 2013-08-30 9:42 UTC (permalink / raw)
To: Julia Lawall
Cc: Jean-Christophe Plagniol-Villard, kernel-janitors, linux-fbdev,
linux-kernel
In-Reply-To: <1376911241-27720-7-git-send-email-Julia.Lawall@lip6.fr>
[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]
On 19/08/13 14:20, Julia Lawall wrote:
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> Use devm_ioremap_resource instead of devm_request_and_ioremap.
>
> This was done using the semantic patch
> scripts/coccinelle/api/devm_ioremap_resource.cocci
>
> The initialization of drvdata->regs_phys was manually moved lower, to take
> advantage of the NULL test on res performed by devm_ioremap_resource.
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
>
> ---
> drivers/video/xilinxfb.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
> index 6629b29..84c664e 100644
> --- a/drivers/video/xilinxfb.c
> +++ b/drivers/video/xilinxfb.c
> @@ -259,12 +259,12 @@ static int xilinxfb_assign(struct platform_device *pdev,
> struct resource *res;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - drvdata->regs_phys = res->start;
> - drvdata->regs = devm_request_and_ioremap(&pdev->dev, res);
> - if (!drvdata->regs) {
> - rc = -EADDRNOTAVAIL;
> + drvdata->regs = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(drvdata->regs)) {
> + rc = PTR_ERR(drvdata->regs);
> goto err_region;
> }
> + drvdata->regs_phys = res->start;
> }
>
> /* Allocate the framebuffer memory */
Thanks, queued for 3.12.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] drivers: video: i740fb: add 'default' processing contents for 'switch'.
From: Chen Gang @ 2013-08-30 9:45 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <51ECF12D.8060903@asianux.com>
On 08/30/2013 05:16 PM, Tomi Valkeinen wrote:
> On 30/08/13 11:44, Chen Gang wrote:
>> On 08/30/2013 04:36 PM, Tomi Valkeinen wrote:
>>> On 30/08/13 11:17, Chen Gang wrote:
>>>> On 08/30/2013 03:21 PM, Tomi Valkeinen wrote:
>>>
>>>>> I don't think you should use BUG there. BUG should be used when there's
>>>>> not really a good way to continue. Here you could have just a WARN, and
>>>>> return some default FIFO watermark value.
>>>>>
>>>>
>>>> i740_calc_fifo() is a static function, so we can check its caller's
>>>> information to find the suitable fixing ways (for extern function, we
>>>> almost can not do like this).
>>>>
>>>> it has only one caller i740fb_decode_var(), which has already let 'bpp'
>>>> within the values (8, 15, 16, 24, 32). So if another values occurs, it
>>>> must be a BUG (e.g. the stack may override under ia32).
>>>
>>> My point was that there should almost never be need for BUG in a normal
>>> driver. BUG means that the whole kernel will probably halt. Even if an
>>> fb driver encounters a problem that should never happen, it should maybe
>>> give a WARN, and continue or fail in a controlled manner.
>>>
>>
>> e.g when the stack is override under ia32, it is better to stop continue
>> as soon as possible to try to avoid the kernel continue blindly, that
>> may let the coredump/KDB analyzers' work much easier.
>>
>> Hmm... when driver cause issue, it has effect with the whole kernel
>> (kernel may die soon), so BUG() is used under the whole kernel wide
>> (include normal drivers).
>
> You want i740_calc_fifo() to check the bpp parameter and issue a BUG if
> it's not a valid bpp-value, because in the current driver
> i740_calc_fifo() is never called with a non-valid bpp, and thus a wrong
> bpp indicates a stack corruption?
>
Yes, it is just an e.g. (may also has another samples)
> How about the freq parameter? In the current driver freq can never be
> higher than 1000000. If it is, it's stack corruption. Maybe there should
> be a BUG for that case also?
>
So I said:
"Hmm... it really has quite a few same cases in kernel wide like our
case, but at least they do not report warnings (this does not like our
case), so let just fix our case to satisfy the compiler. :-) "
> As I see it, you're just checking a single arbitrary value in an
> arbitrary place in the driver, and protecting against stack corruption
> there. Why not check all the values in all the functions of the driver
> as well, looking for stack corruptions?
>
BUG() can not protect issues, it can try to protect the kernel continue
blindly after kernel has issue.
> And the bigger issue is that you're only talking about the current
> driver. The driver could be changed tomorrow, maybe calling
> i740_calc_fifo() from some other place, where a wrong bpp could just
> possibly happen. In that case it wouldn't be a stack corruption, but a
> "normal" driver bug.
>
Yeah, BUG() is for bugs in kernel wide, ('stack corruption' is just one
of sample).
And BUG() only report the direct cause, not report the root cause, so
when one sub system report BUG, it does not mean this sub system must
has this BUG.
> So, in my opinion:
>
> - Normally we should presume the the stack is not corrupted, or
> otherwise we'll end up with lots of checks all over.
>
It seems the above reply "Hmm... it really has quite a few same cases
..." is suitable for discussing with your opinion.
> - Even if i740_calc_fifo() is a static function, and we can analyze the
> _current_ situation, we don't know how the driver will evolve in the future.
>
For normal static function (not callback function) it can be in control
within inside (ourselves), don't like extern function, it is out of
control with inside.
So we can assume something in the future.
> Tomi
>
>
Thanks.
--
Chen Gang
^ permalink raw reply
* Re: [RFC 00/22] OMAPDSS: DT support
From: Tomi Valkeinen @ 2013-08-30 9:47 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Laurent Pinchart, Nishanth Menon, Felipe Balbi, Santosh Shilimkar
In-Reply-To: <20130813075449.GS7656@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1413 bytes --]
On 13/08/13 10:54, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [130809 01:46]:
>>
>> So as is evident, I have things in my mind that should be improved. Maybe
>> the most important question for short term future is:
>>
>> Can we add DSS DT bindings for OMAP4 as unstable bindings? It would give us
>> some proper testing of the related code, and would also allow us to remove
>> the related hacks (which don't even work quite right). However, I have no
>> idea yet when the unstable DSS bindings would turn stable.
>>
>> If we shouldn't add the bindings as unstable, when should the bindings be
>> added? Wait until CDF is in the mainline, and use that?
>
> I don't think we should add any temporary bindings as it's going to be
> a pain to support those in the long run. I suggest you initially just
> stick to established bindings for the basic hardware IO address and
> interrupts etc, then those should still be valid with the generic panel
> bindings later on.
I don't understand what does it matter if the bindings are temporary, or
basic established bindings. In both cases the DT data needs to be
changed when the CDF is taken into use.
Well, one difference is that the temporary bindings would give us
working display, but having only basic bindings would not. So I don't
see any reason to add only the basic bindings. Or how would it work?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] drivers: video: i740fb: add 'default' processing contents for 'switch'.
From: Tomi Valkeinen @ 2013-08-30 10:19 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <51ECF12D.8060903@asianux.com>
[-- Attachment #1: Type: text/plain, Size: 1892 bytes --]
On 30/08/13 12:45, Chen Gang wrote:
> On 08/30/2013 05:16 PM, Tomi Valkeinen wrote:
>> So, in my opinion:
>>
>> - Normally we should presume the the stack is not corrupted, or
>> otherwise we'll end up with lots of checks all over.
>>
>
> It seems the above reply "Hmm... it really has quite a few same cases
> ..." is suitable for discussing with your opinion.
Well, if other drivers do silly things, it's no reason to do it here also.
>
>> - Even if i740_calc_fifo() is a static function, and we can analyze the
>> _current_ situation, we don't know how the driver will evolve in the future.
>>
>
> For normal static function (not callback function) it can be in control
> within inside (ourselves), don't like extern function, it is out of
> control with inside.
>
> So we can assume something in the future.
We can assume that only if we presume that the future changes are
bug-free. But more often than not there are bugs in the kernel drivers.
Now, say, if such a bug is introduced, and somebody is running the
kernel in a remote server, the driver will call BUG(). This will cause
the server to halt. The user won't see what happened, the connections
are just lost and the error is not written to a hard disk.
If, instead, the driver would do WARN, and continue or fail in a
controlled manner, the user can find out about the issue easily. Even if
there is a stack corruption, it's most likely the driver in question
that has it, and thus not really fatal.
Sure, there's the possibility that there's a bigger memory corruption,
which would go unnoticed by, say, the filesystem layer, resulting in a
corrupted filesystem. And we would catch this corruption by checking the
bpp variable. But, really, I find that very unlikely scenario.
Here's some old discussion about BUG:
http://yarchive.net/comp/linux/BUG.html
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] drivers: video: i740fb: add 'default' processing contents for 'switch'.
From: Chen Gang @ 2013-08-30 10:41 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <51ECF12D.8060903@asianux.com>
On 08/30/2013 06:19 PM, Tomi Valkeinen wrote:
> On 30/08/13 12:45, Chen Gang wrote:
>> On 08/30/2013 05:16 PM, Tomi Valkeinen wrote:
>
>>> So, in my opinion:
>>>
>>> - Normally we should presume the the stack is not corrupted, or
>>> otherwise we'll end up with lots of checks all over.
>>>
>>
>> It seems the above reply "Hmm... it really has quite a few same cases
>> ..." is suitable for discussing with your opinion.
>
> Well, if other drivers do silly things, it's no reason to do it here also.
>
Hmm... I can understand. What I have done is only just "satisfy the
compiler".
>>
>>> - Even if i740_calc_fifo() is a static function, and we can analyze the
>>> _current_ situation, we don't know how the driver will evolve in the future.
>>>
>>
>> For normal static function (not callback function) it can be in control
>> within inside (ourselves), don't like extern function, it is out of
>> control with inside.
>>
>> So we can assume something in the future.
>
> We can assume that only if we presume that the future changes are
> bug-free. But more often than not there are bugs in the kernel drivers.
>
Yeah.
> Now, say, if such a bug is introduced, and somebody is running the
> kernel in a remote server, the driver will call BUG(). This will cause
> the server to halt. The user won't see what happened, the connections
> are just lost and the error is not written to a hard disk.
>
For our case, it we don't call BUG(), the kernel will continue blindly,
and in most cases, at last it will die too (or zombie, or some other
critical issues).
So BUG() is only for trying to protect the kernel continue blindly.
> If, instead, the driver would do WARN, and continue or fail in a
> controlled manner, the user can find out about the issue easily. Even if
> there is a stack corruption, it's most likely the driver in question
> that has it, and thus not really fatal.
>
Hmm, in my opinion, four our case, it is fatal, need try to stop kernel
as soon as possible (don't let it continue blindly).
> Sure, there's the possibility that there's a bigger memory corruption,
> which would go unnoticed by, say, the filesystem layer, resulting in a
> corrupted filesystem. And we would catch this corruption by checking the
> bpp variable. But, really, I find that very unlikely scenario.
>
Yeah. In fact the reason why I focus on 'bpp' is because of "satisfying
the compiler" (not let it report warning).
> Here's some old discussion about BUG:
>
> http://yarchive.net/comp/linux/BUG.html
>
Yeah, if it is not a real bug (can handle it), we should not use BUG(),
but when we are sure it is a kernel bug, and the kernel will continue
blindly, we need use BUG() to stop it.
Just like the Linus Torvalds said in the link which you provide:
"Rule of thumb: BUG() is only good for something that never happens and
that we really have no other option for (ie state is so corrupt that
continuing is deadly)".
In fact, for our case, when "default" happens: it is just match the
contents above.
> Tomi
>
>
Thanks.
--
Chen Gang
^ permalink raw reply
* Re: [PATCH] drivers: video: i740fb: add 'default' processing contents for 'switch'.
From: Tomi Valkeinen @ 2013-08-30 10:52 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <51ECF12D.8060903@asianux.com>
[-- Attachment #1: Type: text/plain, Size: 956 bytes --]
On 30/08/13 13:41, Chen Gang wrote:
> On 08/30/2013 06:19 PM, Tomi Valkeinen wrote:
>> Here's some old discussion about BUG:
>>
>> http://yarchive.net/comp/linux/BUG.html
>>
>
> Yeah, if it is not a real bug (can handle it), we should not use BUG(),
> but when we are sure it is a kernel bug, and the kernel will continue
> blindly, we need use BUG() to stop it.
>
> Just like the Linus Torvalds said in the link which you provide:
>
> "Rule of thumb: BUG() is only good for something that never happens and
> that we really have no other option for (ie state is so corrupt that
> continuing is deadly)".
I guess this is where we disagree. I don't see having a corrupt bpp
value in a fb driver's internal function as "so corrupt that continuing
is deadly".
Anyway, if you insist on the BUG(), I'll leave this patch to
Jean-Christophe. I'm only taking small-ish patches that have no open
issues or disagreements.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
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