| Message ID | CAAfyv36MaVqrmQxpqDu-ciO9GNJK3pJkFZohEvd1BOLOWWEOhw@mail.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
* Belisko Marek <marek.belisko@gmail.com> [131210 14:13]: > On Tue, Nov 12, 2013 at 12:31 AM, Tony Lindgren <tony@atomide.com> wrote: > > > > It would be best to set it up as omap-ctrl.c driver under drivers > > somewhere with few functions exported for DSS and MMC drivers. > > I create small dummy driver based on phy-omap-control which can be > used but before sending patch (with more updates) I would like to get > some feedback if my direction is correct. Cool thanks. Yeah what you have can easily be combined with the patches Balaji has posted to make HSMMC use drivers/mfd/syscon.c via regmap for the SCM register access. Maybe take a look at the work in progress patches in thread: [PATCH v4 0/7] mmc: omap_hsmmc: pbias dt and cleanup And also see my comments regarding using the SCM GENERAL register area as base for the syscon.c driver. That should work for your driver too, right? And then you can access the SYSCON1 register that way from your consumer driver ;) Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Tony, On Tue, Dec 10, 2013 at 11:46 PM, Tony Lindgren <tony@atomide.com> wrote: > * Belisko Marek <marek.belisko@gmail.com> [131210 14:13]: >> On Tue, Nov 12, 2013 at 12:31 AM, Tony Lindgren <tony@atomide.com> wrote: >> > >> > It would be best to set it up as omap-ctrl.c driver under drivers >> > somewhere with few functions exported for DSS and MMC drivers. >> >> I create small dummy driver based on phy-omap-control which can be >> used but before sending patch (with more updates) I would like to get >> some feedback if my direction is correct. > > Cool thanks. Yeah what you have can easily be combined with the patches > Balaji has posted to make HSMMC use drivers/mfd/syscon.c via regmap > for the SCM register access. Maybe take a look at the work in progress > patches in thread: > > [PATCH v4 0/7] mmc: omap_hsmmc: pbias dt and cleanup > > And also see my comments regarding using the SCM GENERAL register area > as base for the syscon.c driver. That should work for your driver too, > right? And then you can access the SYSCON1 register that way from your > consumer driver ;) If I understand correclty I can use syscon driver (it will have in range also devconf1 register) ad get rid of my custom driver and then get regmap from syscon and update bits that I need for venc, right? > > Regards, > > Tony BR, marek
On Thu, Dec 12, 2013 at 09:31:02AM +0100, Belisko Marek wrote: > Hi Tony, > > On Tue, Dec 10, 2013 at 11:46 PM, Tony Lindgren <tony@atomide.com> wrote: > > * Belisko Marek <marek.belisko@gmail.com> [131210 14:13]: > >> On Tue, Nov 12, 2013 at 12:31 AM, Tony Lindgren <tony@atomide.com> wrote: > >> > > >> > It would be best to set it up as omap-ctrl.c driver under drivers > >> > somewhere with few functions exported for DSS and MMC drivers. > >> > >> I create small dummy driver based on phy-omap-control which can be > >> used but before sending patch (with more updates) I would like to get > >> some feedback if my direction is correct. > > > > Cool thanks. Yeah what you have can easily be combined with the patches > > Balaji has posted to make HSMMC use drivers/mfd/syscon.c via regmap > > for the SCM register access. Maybe take a look at the work in progress > > patches in thread: > > > > [PATCH v4 0/7] mmc: omap_hsmmc: pbias dt and cleanup > > > > And also see my comments regarding using the SCM GENERAL register area > > as base for the syscon.c driver. That should work for your driver too, > > right? And then you can access the SYSCON1 register that way from your > > consumer driver ;) > > If I understand correclty I can use syscon driver (it will have in > range also devconf1 register) ad get rid of my custom driver > and then get regmap from syscon and update bits that I need for venc, right? Yeah something like that. Or since the sysconf1 register is shared, it might be best to still provide specific functions to access it if we cannot map just specific bits of it separately for drivers using regmap. But anyways this should for most part remove the need for a custom driver(s) unless the register is a regulator or a clock. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/misc/omap-ctrl.c b/drivers/misc/omap-ctrl.c new file mode 100644 index 0000000..ca2e576 --- /dev/null +++ b/drivers/misc/omap-ctrl.c @@ -0,0 +1,84 @@ +/* + * omap-ctrl.c - The part of omap control module. + * + * Copyright (C) 2013 Goldelico GmbH + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * Author: Marek Belisko <marek@goldelico.com> + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ + +#include <linux/module.h> +#include <linux/platform_device.h> +#include <linux/io.h> + +static u32 __iomem *devconf1; + +void omap_ctrl_tvoutbypass(int on) +{ + int val = readl(devconf1); + + if (on) + val |= BIT(18); + else + val &= ~BIT(18); + + writel(val, devconf1); +} +EXPORT_SYMBOL_GPL(omap_ctrl_tvoutbypass); + + +void omap_ctrl_acen(int on) +{ + int val = readl(devconf1); + + if (on) + val |= BIT(11); + else + val &= ~BIT(11); + + writel(val, devconf1); +} +EXPORT_SYMBOL_GPL(omap_ctrl_acen); + + +static int omap_ctrl_probe(struct platform_device *pdev) +{ + struct resource *res; + + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, + "devconf1"); + devconf1 = devm_ioremap_resource( + &pdev->dev, res); + if (IS_ERR(devconf1)) + return PTR_ERR(devconf1); + + return 0; +} + +struct platform_driver omap_ctrl_driver = { + .probe = omap_ctrl_probe, + .driver = { + .name = "omap-ctrl", + .owner = THIS_MODULE, + }, +}; + +static int __init omap_ctrl_init(void) +{ + return platform_driver_register(&omap_ctrl_driver); +} +subsys_initcall(omap_ctrl_init); + +static void __exit omap_ctrl_exit(void) +{ + platform_driver_unregister(&omap_ctrl_driver); +}