* [PATCH for 3.8+] drivers/video/ep93xx-fb.c: fix missing declaration of devm_ioremap()
From: Hauke Mehrtens @ 2013-03-21 14:38 UTC (permalink / raw)
To: linux-arm-kernel
This fixes the following compile error:
drivers/video/ep93xx-fb.c: In function 'ep93xxfb_probe':
drivers/video/ep93xx-fb.c:532:2: error: implicit declaration of function 'devm_ioremap' [-Werror=implicit-function-declaration]
drivers/video/ep93xx-fb.c:532:17: warning: assignment makes pointer from integer without a cast [enabled by default]
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Cc: stable@vger.kernel.org
---
This patch should go into kernel 3.8, 3.9 and 3.10.
drivers/video/ep93xx-fb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/ep93xx-fb.c b/drivers/video/ep93xx-fb.c
index 3f2519d..e06cd5d 100644
--- a/drivers/video/ep93xx-fb.c
+++ b/drivers/video/ep93xx-fb.c
@@ -23,6 +23,7 @@
#include <linux/slab.h>
#include <linux/clk.h>
#include <linux/fb.h>
+#include <linux/io.h>
#include <linux/platform_data/video-ep93xx.h>
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe()
From: Fabio Porcedda @ 2013-03-21 13:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201303201146.07987.arnd@arndb.de>
On Wed, Mar 20, 2013 at 12:46 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 20 March 2013, Fabio Porcedda wrote:
>>
>> On Wed, Mar 20, 2013 at 11:20 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Wednesday 20 March 2013, Fabio Porcedda wrote:
>> >> I think we can check inside the deferred_probe_work_func()
>> >> if the dev->probe function pointer is equal to platform_drv_probe_fail().
>> >
>> > I think it's too late by then, because that would only warn if we try to probe
>> > it again, but when platform_driver_probe() does not succeed immediately, it
>>
>> Maybe you mean "does succeed immediately" ?
>
> I mean in this code (simplified for the sake of discussion)
>
> int __init_or_module platform_driver_probe(struct platform_driver *drv,
> int (*probe)(struct platform_device *))
> {
> int retval, code;
>
> drv->probe = probe;
> retval = code = platform_driver_register(drv);
>
> drv->probe = NULL;
> if (code = 0 && list_empty(&drv->driver.p->klist_devices.k_list))
> retval = -ENODEV;
> drv->driver.probe = platform_drv_probe_fail;
>
> if (code != retval)
> platform_driver_unregister(drv);
> return retval;
> }
>
> we assume that all devices are bound to drivers during the call to
> platform_driver_register, and if the device list is empty afterwards,
> we unregister the driver and will never get to the deferred probing
> stage.
Thanks for the explanation, I understand now that is not that simple.
I was hoping it was easier.
Regards
--
Fabio Porcedda
^ permalink raw reply
* Re: [PATCH v2 3/8] drivers: char: use module_platform_driver_probe()
From: Herbert Xu @ 2013-03-21 10:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHkwnC_AJpeVw2o8oJn+zMvSg1Lbmm1aXRYxCmtDYhkJG9nvig@mail.gmail.com>
On Thu, Mar 21, 2013 at 11:15:26AM +0100, Fabio Porcedda wrote:
> On Thu, Mar 21, 2013 at 10:55 AM, Herbert Xu
> <herbert@gondor.apana.org.au> wrote:
> > On Thu, Mar 14, 2013 at 06:09:33PM +0100, Fabio Porcedda wrote:
> >> This patch converts the drivers to use the
> >> module_platform_driver_probe() macro which makes the code smaller and
> >> a bit simpler.
> >>
> >> Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
> >> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >> Cc: Matt Mackall <mpm@selenic.com>
> >> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> >> Cc: Fabio Estevam <fabio.estevam@freescale.com>
> >> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> >
> > Patch applied.
>
> The patch is already in
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git.
> Are you speaking about that?
OK, I'll remove it from my tree.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2 3/8] drivers: char: use module_platform_driver_probe()
From: Fabio Porcedda @ 2013-03-21 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130321095542.GH26931@gondor.apana.org.au>
On Thu, Mar 21, 2013 at 10:55 AM, Herbert Xu
<herbert@gondor.apana.org.au> wrote:
> On Thu, Mar 14, 2013 at 06:09:33PM +0100, Fabio Porcedda wrote:
>> This patch converts the drivers to use the
>> module_platform_driver_probe() macro which makes the code smaller and
>> a bit simpler.
>>
>> Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Cc: Matt Mackall <mpm@selenic.com>
>> Cc: Herbert Xu <herbert@gondor.apana.org.au>
>> Cc: Fabio Estevam <fabio.estevam@freescale.com>
>> Cc: Sascha Hauer <s.hauer@pengutronix.de>
>
> Patch applied.
The patch is already in
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git.
Are you speaking about that?
Best regards
--
Fabio Porcedda
^ permalink raw reply
* Re: [PATCH v2 3/8] drivers: char: use module_platform_driver_probe()
From: Herbert Xu @ 2013-03-21 9:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1363280978-24051-4-git-send-email-fabio.porcedda@gmail.com>
On Thu, Mar 14, 2013 at 06:09:33PM +0100, Fabio Porcedda wrote:
> This patch converts the drivers to use the
> module_platform_driver_probe() macro which makes the code smaller and
> a bit simpler.
>
> Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Matt Mackall <mpm@selenic.com>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: Fabio Estevam <fabio.estevam@freescale.com>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
Patch applied.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 08/14] OMAPDSS: DSS: add new clock calculation code
From: Tomi Valkeinen @ 2013-03-21 8:13 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <514AA556.4040300@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1093 bytes --]
On 2013-03-21 08:14, Archit Taneja wrote:
> On Wednesday 20 March 2013 08:58 PM, Tomi Valkeinen wrote:
>> On 2013-03-20 17:17, Archit Taneja wrote:
>>> On Friday 08 March 2013 05:22 PM, Tomi Valkeinen wrote:
>>>> + if (dss.dpll4_m4_ck == NULL) {
>>>> + /* XXX can we change the clock on omap2? */
>>>
>>> We can change dss_fclk1 on omap2, and the cclock2420_data.c and
>>> cclock2430_data.c have clksel structs which allow a set of dividers. The
>>> dividers are not continuous though, 1 to 12 and 16 are allowed. So we
>>> might need to change the code here a bit, if we want to change the clock
>>> in the first place.
>>
>> Ok, good to know. Note that the comment is copied from the old code. I
>> think I tried changing the clock on N800 with clk_set_rate long ago, but
>> I didn't get it to work. Things might have changed, but, well, I don't
>> think we should spend time on omap2 code. I'm sure we'll get a patch if
>> somebody needs it =).
>
> We could change the comment to a TODO for now.
Yep, not a bad idea. I'll make the change.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH 08/14] OMAPDSS: DSS: add new clock calculation code
From: Archit Taneja @ 2013-03-21 6:26 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <5149D5A7.204@ti.com>
On Wednesday 20 March 2013 08:58 PM, Tomi Valkeinen wrote:
> On 2013-03-20 17:17, Archit Taneja wrote:
>> On Friday 08 March 2013 05:22 PM, Tomi Valkeinen wrote:
>>> Add new way to iterate over DSS clock divisors. dss_div_calc() provides
>>> a generic way to go over all the divisors, within given clock range.
>>> dss_div_calc() will call a callback function for each divider set,
>>> making the function reusable for all use cases.
>>>
>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>> ---
>>> drivers/video/omap2/dss/dss.c | 36
>>> ++++++++++++++++++++++++++++++++++++
>>> drivers/video/omap2/dss/dss.h | 3 +++
>>> 2 files changed, 39 insertions(+)
>>>
>>> diff --git a/drivers/video/omap2/dss/dss.c
>>> b/drivers/video/omap2/dss/dss.c
>>> index 054c2a2..21a3dc8 100644
>>> --- a/drivers/video/omap2/dss/dss.c
>>> +++ b/drivers/video/omap2/dss/dss.c
>>> @@ -473,6 +473,42 @@ int dss_calc_clock_rates(struct dss_clock_info
>>> *cinfo)
>>> return 0;
>>> }
>>>
>>> +bool dss_div_calc(unsigned long fck_min, dss_div_calc_func func, void
>>> *data)
>>> +{
>>> + int fckd, fckd_start, fckd_stop;
>>> + unsigned long fck;
>>> + unsigned long fck_hw_max;
>>> + unsigned long fckd_hw_max;
>>> + unsigned long prate;
>>> +
>>> + if (dss.dpll4_m4_ck = NULL) {
>>> + /* XXX can we change the clock on omap2? */
>>
>> We can change dss_fclk1 on omap2, and the cclock2420_data.c and
>> cclock2430_data.c have clksel structs which allow a set of dividers. The
>> dividers are not continuous though, 1 to 12 and 16 are allowed. So we
>> might need to change the code here a bit, if we want to change the clock
>> in the first place.
>
> Ok, good to know. Note that the comment is copied from the old code. I
> think I tried changing the clock on N800 with clk_set_rate long ago, but
> I didn't get it to work. Things might have changed, but, well, I don't
> think we should spend time on omap2 code. I'm sure we'll get a patch if
> somebody needs it =).
We could change the comment to a TODO for now.
Archit
^ permalink raw reply
* Re: [PATCH v2] mfd: as3711: add OF support
From: Guennadi Liakhovetski @ 2013-03-20 19:40 UTC (permalink / raw)
To: Mark Brown
Cc: linux-kernel, Magnus Damm, Simon Horman, devicetree-discuss,
Samuel Ortiz, Liam Girdwood, Richard Purdie, Andrew Morton,
linux-fbdev
In-Reply-To: <20130302041547.GJ6610@opensource.wolfsonmicro.com>
Hi all
On Sat, 2 Mar 2013, Mark Brown wrote:
> On Mon, Feb 18, 2013 at 10:57:44AM +0100, Guennadi Liakhovetski wrote:
> > Add device-tree bindings to the AS3711 regulator and backlight drivers.
>
> Reviwed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This patch has been submitted more than a month ago and only has got one
reviewed-be (thanks) and no comments otherwise. The patch touches multiple
subsystems, so, it is a bit difficult to decide via which tree it should
be pushed. Since the least trivial and largest portion of the patch is
backlight-related, maybe Samuel could add his ack and then Andrew could
pull it via his tree?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: Temporary fbdev maintainership for 3.8 merge window
From: Timur Tabi @ 2013-03-20 15:47 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:
> Hi Florian, all,
>
> 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.
What about for 3.9? Do you know who is handling fbdev patches? It
seems Florian is still MIA, and a patch that I had posted two months
ago has missed the merge window.
^ permalink raw reply
* Re: [PATCH 08/14] OMAPDSS: DSS: add new clock calculation code
From: Archit Taneja @ 2013-03-20 15:29 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1362743569-10289-9-git-send-email-tomi.valkeinen@ti.com>
On Friday 08 March 2013 05:22 PM, Tomi Valkeinen wrote:
> Add new way to iterate over DSS clock divisors. dss_div_calc() provides
> a generic way to go over all the divisors, within given clock range.
> dss_div_calc() will call a callback function for each divider set,
> making the function reusable for all use cases.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/dss/dss.c | 36 ++++++++++++++++++++++++++++++++++++
> drivers/video/omap2/dss/dss.h | 3 +++
> 2 files changed, 39 insertions(+)
>
> diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
> index 054c2a2..21a3dc8 100644
> --- a/drivers/video/omap2/dss/dss.c
> +++ b/drivers/video/omap2/dss/dss.c
> @@ -473,6 +473,42 @@ int dss_calc_clock_rates(struct dss_clock_info *cinfo)
> return 0;
> }
>
> +bool dss_div_calc(unsigned long fck_min, dss_div_calc_func func, void *data)
> +{
> + int fckd, fckd_start, fckd_stop;
> + unsigned long fck;
> + unsigned long fck_hw_max;
> + unsigned long fckd_hw_max;
> + unsigned long prate;
> +
> + if (dss.dpll4_m4_ck = NULL) {
> + /* XXX can we change the clock on omap2? */
We can change dss_fclk1 on omap2, and the cclock2420_data.c and
cclock2430_data.c have clksel structs which allow a set of dividers. The
dividers are not continuous though, 1 to 12 and 16 are allowed. So we
might need to change the code here a bit, if we want to change the clock
in the first place.
Archit
> + fck = clk_get_rate(dss.dss_clk);
> + fckd = 1;
> +
> + return func(fckd, fck, data);
> + }
> +
> + fck_hw_max = dss_feat_get_param_max(FEAT_PARAM_DSS_FCK);
> + fckd_hw_max = dss.feat->fck_div_max;
> +
> + prate = dss_get_dpll4_rate() * dss.feat->dss_fck_multiplier;
> +
> + fck_min = fck_min ? fck_min : 1;
> +
> + fckd_start = min(prate / fck_min, fckd_hw_max);
> + fckd_stop = max(DIV_ROUND_UP(prate, fck_hw_max), 1ul);
> +
> + for (fckd = fckd_start; fckd >= fckd_stop; --fckd) {
> + fck = prate / fckd;
> +
> + if (func(fckd, fck, data))
> + return true;
> + }
> +
> + return false;
> +}
> +
> int dss_set_clock_div(struct dss_clock_info *cinfo)
> {
> if (dss.dpll4_m4_ck) {
> diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
> index 0ff41dd..4180302 100644
> --- a/drivers/video/omap2/dss/dss.h
> +++ b/drivers/video/omap2/dss/dss.h
> @@ -271,6 +271,9 @@ int dss_set_clock_div(struct dss_clock_info *cinfo);
> int dss_calc_clock_div(unsigned long req_pck, struct dss_clock_info *dss_cinfo,
> struct dispc_clock_info *dispc_cinfo);
>
> +typedef bool (*dss_div_calc_func)(int fckd, unsigned long fck, void *data);
> +bool dss_div_calc(unsigned long fck_min, dss_div_calc_func func, void *data);
> +
> /* SDI */
> int sdi_init_platform_driver(void) __init;
> void sdi_uninit_platform_driver(void) __exit;
>
^ permalink raw reply
* Re: [PATCH 08/14] OMAPDSS: DSS: add new clock calculation code
From: Tomi Valkeinen @ 2013-03-20 15:28 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <5149D30F.2010801@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]
On 2013-03-20 17:17, Archit Taneja wrote:
> On Friday 08 March 2013 05:22 PM, Tomi Valkeinen wrote:
>> Add new way to iterate over DSS clock divisors. dss_div_calc() provides
>> a generic way to go over all the divisors, within given clock range.
>> dss_div_calc() will call a callback function for each divider set,
>> making the function reusable for all use cases.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> ---
>> drivers/video/omap2/dss/dss.c | 36
>> ++++++++++++++++++++++++++++++++++++
>> drivers/video/omap2/dss/dss.h | 3 +++
>> 2 files changed, 39 insertions(+)
>>
>> diff --git a/drivers/video/omap2/dss/dss.c
>> b/drivers/video/omap2/dss/dss.c
>> index 054c2a2..21a3dc8 100644
>> --- a/drivers/video/omap2/dss/dss.c
>> +++ b/drivers/video/omap2/dss/dss.c
>> @@ -473,6 +473,42 @@ int dss_calc_clock_rates(struct dss_clock_info
>> *cinfo)
>> return 0;
>> }
>>
>> +bool dss_div_calc(unsigned long fck_min, dss_div_calc_func func, void
>> *data)
>> +{
>> + int fckd, fckd_start, fckd_stop;
>> + unsigned long fck;
>> + unsigned long fck_hw_max;
>> + unsigned long fckd_hw_max;
>> + unsigned long prate;
>> +
>> + if (dss.dpll4_m4_ck == NULL) {
>> + /* XXX can we change the clock on omap2? */
>
> We can change dss_fclk1 on omap2, and the cclock2420_data.c and
> cclock2430_data.c have clksel structs which allow a set of dividers. The
> dividers are not continuous though, 1 to 12 and 16 are allowed. So we
> might need to change the code here a bit, if we want to change the clock
> in the first place.
Ok, good to know. Note that the comment is copied from the old code. I
think I tried changing the clock on N800 with clk_set_rate long ago, but
I didn't get it to work. Things might have changed, but, well, I don't
think we should spend time on omap2 code. I'm sure we'll get a patch if
somebody needs it =).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe()
From: Arnd Bergmann @ 2013-03-20 11:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHkwnC-8FH0nyJ+eT=+7doP+fSdZjNYUW4zzs_r6e9wt3Yt4Fg@mail.gmail.com>
On Wednesday 20 March 2013, Fabio Porcedda wrote:
>
> On Wed, Mar 20, 2013 at 11:20 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Wednesday 20 March 2013, Fabio Porcedda wrote:
> >> I think we can check inside the deferred_probe_work_func()
> >> if the dev->probe function pointer is equal to platform_drv_probe_fail().
> >
> > I think it's too late by then, because that would only warn if we try to probe
> > it again, but when platform_driver_probe() does not succeed immediately, it
>
> Maybe you mean "does succeed immediately" ?
I mean in this code (simplified for the sake of discussion)
int __init_or_module platform_driver_probe(struct platform_driver *drv,
int (*probe)(struct platform_device *))
{
int retval, code;
drv->probe = probe;
retval = code = platform_driver_register(drv);
drv->probe = NULL;
if (code = 0 && list_empty(&drv->driver.p->klist_devices.k_list))
retval = -ENODEV;
drv->driver.probe = platform_drv_probe_fail;
if (code != retval)
platform_driver_unregister(drv);
return retval;
}
we assume that all devices are bound to drivers during the call to
platform_driver_register, and if the device list is empty afterwards,
we unregister the driver and will never get to the deferred probing
stage.
Arnd
^ permalink raw reply
* Re: [PATCH 03/14] OMAPDSS: DSI: simplify dsi configuration
From: Tomi Valkeinen @ 2013-03-20 11:44 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <51499C73.3060802@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1782 bytes --]
On 2013-03-20 13:24, Archit Taneja wrote:
> On Friday 08 March 2013 05:22 PM, Tomi Valkeinen wrote:
>> We have a bunch of dsi functions that are used to do the basic
>> configuration for DSI. To simplify things, and to make sure we have all
>> the necessary information, create a single dsi config function, which
>> does the basic configuration.
>
> I had split these funcs in the manner so that they could be converted
> into generic output ops or something equivalent to what we anticipated
> CDF to represent encoders. Hence, we may have to split this into smaller
> funcs again later :p
Well, it was from the CDF discussions that this change arose. Everybody
wanted a simpler way than n+1 functions.
And I think it makes sense. It makes it possible to manage the
configuration as one "whole", instead of small bits that may have
interdependencies. E.g the size of the output affects video mode
calculations, so one had to make the calls in certain order. Now we have
all the needed information in one piece.
We could, perhaps, have common parts between different video busses, but
I'm not sure if configuration is one of those common parts.
> Also, set_size and set_timings were 2 different ops for command and
> video mode panels respectively. omapdss_dsi_set_size() also came in use
> when we supported rotation in Taal. We have an equivalent func for rfbi.
Yep. I felt it's a bit confusing, so I just combined them. Even for
command mode some timing information is good (well, pixel clock), to
calculate proper DSI bus speed.
I think this also works in case of panel rotation. From DSS's point of
view (and that's what we're talking about when setting the timings)
there's no rotation. It's the panel's internal thing.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH 05/14] OMAPDSS: DSI: add enum omap_dss_dsi_trans_mode
From: Archit Taneja @ 2013-03-20 11:42 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1362743569-10289-6-git-send-email-tomi.valkeinen@ti.com>
On Friday 08 March 2013 05:22 PM, Tomi Valkeinen wrote:
> Instead of managing DSI sync ends with booleans, add an enum for the DSI
> transfer mode. This is much cleaner way to handle the DSI syncs.
This sort of DSI protocol specific enums should definitely get into the
CDF encoder drivers, maybe even in include/video/mipi_display.h for the
time CDF is being worked upon.
Archit
^ permalink raw reply
* Re: [PATCH 03/14] OMAPDSS: DSI: simplify dsi configuration
From: Archit Taneja @ 2013-03-20 11:36 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1362743569-10289-4-git-send-email-tomi.valkeinen@ti.com>
On Friday 08 March 2013 05:22 PM, Tomi Valkeinen wrote:
> We have a bunch of dsi functions that are used to do the basic
> configuration for DSI. To simplify things, and to make sure we have all
> the necessary information, create a single dsi config function, which
> does the basic configuration.
I had split these funcs in the manner so that they could be converted
into generic output ops or something equivalent to what we anticipated
CDF to represent encoders. Hence, we may have to split this into smaller
funcs again later :p
Also, set_size and set_timings were 2 different ops for command and
video mode panels respectively. omapdss_dsi_set_size() also came in use
when we supported rotation in Taal. We have an equivalent func for rfbi.
Archit
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/displays/panel-taal.c | 16 ++++---
> drivers/video/omap2/dss/dsi.c | 74 ++++-------------------------
> include/video/omapdss.h | 23 ++++-----
> 3 files changed, 31 insertions(+), 82 deletions(-)
>
> diff --git a/drivers/video/omap2/displays/panel-taal.c b/drivers/video/omap2/displays/panel-taal.c
> index bc4c95e..eb86cba 100644
> --- a/drivers/video/omap2/displays/panel-taal.c
> +++ b/drivers/video/omap2/displays/panel-taal.c
> @@ -919,6 +919,13 @@ static int taal_power_on(struct omap_dss_device *dssdev)
> struct taal_data *td = dev_get_drvdata(&dssdev->dev);
> u8 id1, id2, id3;
> int r;
> + struct omap_dss_dsi_config dsi_config = {
> + .mode = OMAP_DSS_DSI_CMD_MODE,
> + .pixel_format = OMAP_DSS_DSI_FMT_RGB888,
> + .timings = &dssdev->panel.timings,
> + .hs_clk = 216000000,
> + .lp_clk = 10000000,
> + };
>
> r = omapdss_dsi_configure_pins(dssdev, &td->pin_config);
> if (r) {
> @@ -926,14 +933,9 @@ static int taal_power_on(struct omap_dss_device *dssdev)
> goto err0;
> };
>
> - omapdss_dsi_set_size(dssdev, dssdev->panel.timings.x_res,
> - dssdev->panel.timings.y_res);
> - omapdss_dsi_set_pixel_format(dssdev, OMAP_DSS_DSI_FMT_RGB888);
> - omapdss_dsi_set_operation_mode(dssdev, OMAP_DSS_DSI_CMD_MODE);
> -
> - r = omapdss_dsi_set_clocks(dssdev, 216000000, 10000000);
> + r = omapdss_dsi_set_config(dssdev, &dsi_config);
> if (r) {
> - dev_err(&dssdev->dev, "failed to set HS and LP clocks\n");
> + dev_err(&dssdev->dev, "failed to configure DSI\n");
> goto err0;
> }
>
> diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
> index 5f5b475..901b721 100644
> --- a/drivers/video/omap2/dss/dsi.c
> +++ b/drivers/video/omap2/dss/dsi.c
> @@ -4278,7 +4278,7 @@ int omapdss_dsi_configure_pins(struct omap_dss_device *dssdev,
> }
> EXPORT_SYMBOL(omapdss_dsi_configure_pins);
>
> -int omapdss_dsi_set_clocks(struct omap_dss_device *dssdev,
> +static int dsi_set_clocks(struct omap_dss_device *dssdev,
> unsigned long ddr_clk, unsigned long lp_clk)
> {
> struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
> @@ -4293,8 +4293,6 @@ int omapdss_dsi_set_clocks(struct omap_dss_device *dssdev,
>
> DSSDBG("Setting DSI clocks: ddr_clk %lu, lp_clk %lu", ddr_clk, lp_clk);
>
> - mutex_lock(&dsi->lock);
> -
> /* Calculate PLL output clock */
> r = dsi_pll_calc_ddrfreq(dsidev, ddr_clk * 4, &cinfo);
> if (r)
> @@ -4336,13 +4334,10 @@ int omapdss_dsi_set_clocks(struct omap_dss_device *dssdev,
> OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DSI :
> OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DSI;
>
> - mutex_unlock(&dsi->lock);
> return 0;
> err:
> - mutex_unlock(&dsi->lock);
> return r;
> }
> -EXPORT_SYMBOL(omapdss_dsi_set_clocks);
>
> int dsi_enable_video_output(struct omap_dss_device *dssdev, int channel)
> {
> @@ -4884,75 +4879,26 @@ int omapdss_dsi_enable_te(struct omap_dss_device *dssdev, bool enable)
> }
> EXPORT_SYMBOL(omapdss_dsi_enable_te);
>
> -void omapdss_dsi_set_timings(struct omap_dss_device *dssdev,
> - struct omap_video_timings *timings)
> +int omapdss_dsi_set_config(struct omap_dss_device *dssdev,
> + const struct omap_dss_dsi_config *config)
> {
> struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
> struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
>
> mutex_lock(&dsi->lock);
>
> - dsi->timings = *timings;
> -
> - mutex_unlock(&dsi->lock);
> -}
> -EXPORT_SYMBOL(omapdss_dsi_set_timings);
> -
> -void omapdss_dsi_set_size(struct omap_dss_device *dssdev, u16 w, u16 h)
> -{
> - struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
> - struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
> -
> - mutex_lock(&dsi->lock);
> + dsi->timings = *config->timings;
> + dsi->vm_timings = *config->vm_timings;
> + dsi->pix_fmt = config->pixel_format;
> + dsi->mode = config->mode;
>
> - dsi->timings.x_res = w;
> - dsi->timings.y_res = h;
> + dsi_set_clocks(dssdev, config->hs_clk, config->lp_clk);
>
> mutex_unlock(&dsi->lock);
> -}
> -EXPORT_SYMBOL(omapdss_dsi_set_size);
>
> -void omapdss_dsi_set_pixel_format(struct omap_dss_device *dssdev,
> - enum omap_dss_dsi_pixel_format fmt)
> -{
> - struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
> - struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
> -
> - mutex_lock(&dsi->lock);
> -
> - dsi->pix_fmt = fmt;
> -
> - mutex_unlock(&dsi->lock);
> -}
> -EXPORT_SYMBOL(omapdss_dsi_set_pixel_format);
> -
> -void omapdss_dsi_set_operation_mode(struct omap_dss_device *dssdev,
> - enum omap_dss_dsi_mode mode)
> -{
> - struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
> - struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
> -
> - mutex_lock(&dsi->lock);
> -
> - dsi->mode = mode;
> -
> - mutex_unlock(&dsi->lock);
> -}
> -EXPORT_SYMBOL(omapdss_dsi_set_operation_mode);
> -
> -void omapdss_dsi_set_videomode_timings(struct omap_dss_device *dssdev,
> - struct omap_dss_dsi_videomode_timings *timings)
> -{
> - struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
> - struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
> -
> - mutex_lock(&dsi->lock);
> -
> - dsi->vm_timings = *timings;
> -
> - mutex_unlock(&dsi->lock);
> + return 0;
> }
> -EXPORT_SYMBOL(omapdss_dsi_set_videomode_timings);
> +EXPORT_SYMBOL(omapdss_dsi_set_config);
>
> /*
> * Return a hardcoded channel for the DSI output. This should work for
> diff --git a/include/video/omapdss.h b/include/video/omapdss.h
> index 9057e21..4a52197 100644
> --- a/include/video/omapdss.h
> +++ b/include/video/omapdss.h
> @@ -282,6 +282,16 @@ struct omap_dss_dsi_videomode_timings {
> int window_sync;
> };
>
> +struct omap_dss_dsi_config {
> + enum omap_dss_dsi_mode mode;
> + enum omap_dss_dsi_pixel_format pixel_format;
> + const struct omap_video_timings *timings;
> + const struct omap_dss_dsi_videomode_timings *vm_timings;
> +
> + unsigned long hs_clk;
> + unsigned long lp_clk;
> +};
> +
> void dsi_bus_lock(struct omap_dss_device *dssdev);
> void dsi_bus_unlock(struct omap_dss_device *dssdev);
> int dsi_vc_dcs_write(struct omap_dss_device *dssdev, int channel, u8 *data,
> @@ -805,15 +815,8 @@ int dispc_ovl_setup(enum omap_plane plane, const struct omap_overlay_info *oi,
> void omapdss_dsi_vc_enable_hs(struct omap_dss_device *dssdev, int channel,
> bool enable);
> int omapdss_dsi_enable_te(struct omap_dss_device *dssdev, bool enable);
> -void omapdss_dsi_set_timings(struct omap_dss_device *dssdev,
> - struct omap_video_timings *timings);
> -void omapdss_dsi_set_size(struct omap_dss_device *dssdev, u16 w, u16 h);
> -void omapdss_dsi_set_pixel_format(struct omap_dss_device *dssdev,
> - enum omap_dss_dsi_pixel_format fmt);
> -void omapdss_dsi_set_operation_mode(struct omap_dss_device *dssdev,
> - enum omap_dss_dsi_mode mode);
> -void omapdss_dsi_set_videomode_timings(struct omap_dss_device *dssdev,
> - struct omap_dss_dsi_videomode_timings *timings);
> +int omapdss_dsi_set_config(struct omap_dss_device *dssdev,
> + const struct omap_dss_dsi_config *config);
>
> int omap_dsi_update(struct omap_dss_device *dssdev, int channel,
> void (*callback)(int, void *), void *data);
> @@ -822,8 +825,6 @@ int omap_dsi_set_vc_id(struct omap_dss_device *dssdev, int channel, int vc_id);
> void omap_dsi_release_vc(struct omap_dss_device *dssdev, int channel);
> int omapdss_dsi_configure_pins(struct omap_dss_device *dssdev,
> const struct omap_dsi_pin_config *pin_cfg);
> -int omapdss_dsi_set_clocks(struct omap_dss_device *dssdev,
> - unsigned long ddr_clk, unsigned long lp_clk);
>
> int omapdss_dsi_display_enable(struct omap_dss_device *dssdev);
> void omapdss_dsi_display_disable(struct omap_dss_device *dssdev,
>
^ permalink raw reply
* Re: [PATCH 01/14] OMAPDSS: DISPC: store core clk rate
From: Tomi Valkeinen @ 2013-03-20 11:36 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <514998B1.8040907@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]
On 2013-03-20 13:08, Archit Taneja wrote:
> Hi,
>
> On Friday 08 March 2013 05:22 PM, Tomi Valkeinen wrote:
>> Store dispc core clock rate so that it's available for calculations even
>> if the HW is disabled.
>
> I think the core_clk_rate variable should change when we change the lcd
> clock source through dss_select_lcd_clk_source() for omap3.
>
> If we have the following sequence:
>
> ...
> dispc_mgr_set_lcd_divisor();
> dss_select_lcd_clk_source();
> ...
>
> The value of core_clock variable would be based on the previous clock
> source, and not the current one.
>
> This situation doesn't occur currently as the 'apply' framework delays
> all dispc writes to the point when we enable the manager. So the
> sequence above cannot occur. But maybe we should keep this in mind when
> we move more things to omapdrm, where 'apply' isn't in use.
Hmm. Good point.
I don't think this has to do with apply system. The clock source is set
by the output drivers, and the output drivers also calculate the
divisors, and call the functions to set the divisors. Both DPI and DSI
drivers first set the clock source, and then call the
dss_mgr_set_lcd_config() which sets the divisors (causing the recalc).
Whether using the apply or not, I think it should work correctly. But
it's clearly something that is a bit fragile.
*cough*commonclockframework*cough*.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH 01/14] OMAPDSS: DISPC: store core clk rate
From: Archit Taneja @ 2013-03-20 11:20 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1362743569-10289-2-git-send-email-tomi.valkeinen@ti.com>
Hi,
On Friday 08 March 2013 05:22 PM, Tomi Valkeinen wrote:
> Store dispc core clock rate so that it's available for calculations even
> if the HW is disabled.
I think the core_clk_rate variable should change when we change the lcd
clock source through dss_select_lcd_clk_source() for omap3.
If we have the following sequence:
...
dispc_mgr_set_lcd_divisor();
dss_select_lcd_clk_source();
...
The value of core_clock variable would be based on the previous clock
source, and not the current one.
This situation doesn't occur currently as the 'apply' framework delays
all dispc writes to the point when we enable the manager. So the
sequence above cannot occur. But maybe we should keep this in mind when
we move more things to omapdrm, where 'apply' isn't in use.
Archit
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/dss/dispc.c | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
> index 05ff2b9..f564955 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -97,6 +97,8 @@ static struct {
>
> int irq;
>
> + unsigned long core_clk_rate;
> +
> u32 fifo_size[DISPC_MAX_NR_FIFOS];
> /* maps which plane is using a fifo. fifo-id -> plane-id */
> int fifo_assignment[DISPC_MAX_NR_FIFOS];
> @@ -2951,6 +2953,10 @@ static void dispc_mgr_set_lcd_divisor(enum omap_channel channel, u16 lck_div,
>
> dispc_write_reg(DISPC_DIVISORo(channel),
> FLD_VAL(lck_div, 23, 16) | FLD_VAL(pck_div, 7, 0));
> +
> + if (dss_has_feature(FEAT_CORE_CLK_DIV) = false &&
> + channel = OMAP_DSS_CHANNEL_LCD)
> + dispc.core_clk_rate = dispc_fclk_rate() / lck_div;
> }
>
> static void dispc_mgr_get_lcd_divisor(enum omap_channel channel, int *lck_div,
> @@ -3056,15 +3062,7 @@ unsigned long dispc_mgr_pclk_rate(enum omap_channel channel)
>
> unsigned long dispc_core_clk_rate(void)
> {
> - int lcd;
> - unsigned long fclk = dispc_fclk_rate();
> -
> - if (dss_has_feature(FEAT_CORE_CLK_DIV))
> - lcd = REG_GET(DISPC_DIVISOR, 23, 16);
> - else
> - lcd = REG_GET(DISPC_DIVISORo(OMAP_DSS_CHANNEL_LCD), 23, 16);
> -
> - return fclk / lcd;
> + return dispc.core_clk_rate;
> }
>
> static unsigned long dispc_plane_pclk_rate(enum omap_plane plane)
> @@ -3451,6 +3449,8 @@ static void _omap_dispc_initial_config(void)
> l = FLD_MOD(l, 1, 0, 0);
> l = FLD_MOD(l, 1, 23, 16);
> dispc_write_reg(DISPC_DIVISOR, l);
> +
> + dispc.core_clk_rate = dispc_fclk_rate();
> }
>
> /* FUNCGATED */
>
^ permalink raw reply
* Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe()
From: Fabio Porcedda @ 2013-03-20 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201303201020.14654.arnd@arndb.de>
On Wed, Mar 20, 2013 at 11:20 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 20 March 2013, Fabio Porcedda wrote:
>> I think we can check inside the deferred_probe_work_func()
>> if the dev->probe function pointer is equal to platform_drv_probe_fail().
>
> I think it's too late by then, because that would only warn if we try to probe
> it again, but when platform_driver_probe() does not succeed immediately, it
Maybe you mean "does succeed immediately" ?
> unregisters the driver again, so we never get there.
--
Fabio Porcedda
^ permalink raw reply
* Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe()
From: Arnd Bergmann @ 2013-03-20 10:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHkwnC-3_dDM3JO8y3yeNFz7=fpP=MtZ9D-3cMH8rNF9C1NZBA@mail.gmail.com>
On Wednesday 20 March 2013, Fabio Porcedda wrote:
> I think we can check inside the deferred_probe_work_func()
> if the dev->probe function pointer is equal to platform_drv_probe_fail().
I think it's too late by then, because that would only warn if we try to probe
it again, but when platform_driver_probe() does not succeed immediately, it
unregisters the driver again, so we never get there.
Arnd
^ permalink raw reply
* Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe()
From: Fabio Porcedda @ 2013-03-20 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201303191759.27762.arnd@arndb.de>
On Tue, Mar 19, 2013 at 6:59 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 19 March 2013, Fabio Porcedda wrote:
>> On Tue, Mar 19, 2013 at 5:48 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Tuesday 19 March 2013, Geert Uytterhoeven wrote:
>> >> Hmm, so we may have drivers that (now) work perfectly fine with
>> >> module_platform_driver_probe()/platform_driver_probe(), but will start
>> >> failing suddenly in the future?
>> >
>> > They will fail if someone changes the initialization order. That would
>> > already break drivers before deferred probing support (and was the reason
>> > we added feature in the first place), but now we can be much more liberal
>> > with the order in which drivers are initialized, except when they are
>> > using platform_driver_probe()
>> >
>> >> I guess we need a big fat WARN_ON(-EPROBE_DEFER) in
>> >> platform_driver_probe() to catch these?
>> >
>> > Yes, very good idea.
>>
>> If it's fine, I'll send a patch for that.
>
> That would be cool, yes. I looked at it earlier (after sending my email above)
> and couldn't find an easy way to do it though, because platform_drv_probe
> does not know whether it is called from platform_driver_probe or not.
>
> Maybe using something other than platform_driver_register would work here.
>
> Arnd
I think we can check inside the deferred_probe_work_func()
if the dev->probe function pointer is equal to platform_drv_probe_fail().
Regards
--
Fabio Porcedda
^ permalink raw reply
* Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe()
From: Arnd Bergmann @ 2013-03-19 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHkwnC9FL9W07=n6bWvcwiE058zcBZwqUwtRB-VVNpU0gv0mNw@mail.gmail.com>
On Tuesday 19 March 2013, Fabio Porcedda wrote:
> On Tue, Mar 19, 2013 at 5:48 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tuesday 19 March 2013, Geert Uytterhoeven wrote:
> >> Hmm, so we may have drivers that (now) work perfectly fine with
> >> module_platform_driver_probe()/platform_driver_probe(), but will start
> >> failing suddenly in the future?
> >
> > They will fail if someone changes the initialization order. That would
> > already break drivers before deferred probing support (and was the reason
> > we added feature in the first place), but now we can be much more liberal
> > with the order in which drivers are initialized, except when they are
> > using platform_driver_probe()
> >
> >> I guess we need a big fat WARN_ON(-EPROBE_DEFER) in
> >> platform_driver_probe() to catch these?
> >
> > Yes, very good idea.
>
> If it's fine, I'll send a patch for that.
That would be cool, yes. I looked at it earlier (after sending my email above)
and couldn't find an easy way to do it though, because platform_drv_probe
does not know whether it is called from platform_driver_probe or not.
Maybe using something other than platform_driver_register would work here.
Arnd
^ permalink raw reply
* Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe()
From: Fabio Porcedda @ 2013-03-19 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201303191648.31527.arnd@arndb.de>
On Tue, Mar 19, 2013 at 5:48 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 19 March 2013, Geert Uytterhoeven wrote:
>> Hmm, so we may have drivers that (now) work perfectly fine with
>> module_platform_driver_probe()/platform_driver_probe(), but will start
>> failing suddenly in the future?
>
> They will fail if someone changes the initialization order. That would
> already break drivers before deferred probing support (and was the reason
> we added feature in the first place), but now we can be much more liberal
> with the order in which drivers are initialized, except when they are
> using platform_driver_probe()
>
>> I guess we need a big fat WARN_ON(-EPROBE_DEFER) in
>> platform_driver_probe() to catch these?
>
> Yes, very good idea.
>
> Arnd
If it's fine, I'll send a patch for that.
Regards
--
Fabio Porcedda
^ permalink raw reply
* Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe()
From: Arnd Bergmann @ 2013-03-19 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdVS56HRDSvr7XCpVEjEWnGti+V=J_m4qQzEid=23ON_fQ@mail.gmail.com>
On Tuesday 19 March 2013, Geert Uytterhoeven wrote:
> Hmm, so we may have drivers that (now) work perfectly fine with
> module_platform_driver_probe()/platform_driver_probe(), but will start
> failing suddenly in the future?
They will fail if someone changes the initialization order. That would
already break drivers before deferred probing support (and was the reason
we added feature in the first place), but now we can be much more liberal
with the order in which drivers are initialized, except when they are
using platform_driver_probe()
> I guess we need a big fat WARN_ON(-EPROBE_DEFER) in
> platform_driver_probe() to catch these?
Yes, very good idea.
Arnd
^ permalink raw reply
* Re: [PATCH] ARM: OMAP: remove "config FB_OMAP_CONSISTENT_DMA_SIZE"
From: Tomi Valkeinen @ 2013-03-19 13:26 UTC (permalink / raw)
To: Paul Bolle
Cc: Florian Tobias Schandinat, linux-fbdev, linux-omap, linux-kernel
In-Reply-To: <1363687677.1390.6.camel@x61.thuisdomein>
[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]
On 2013-03-19 12:07, Paul Bolle wrote:
> The only user of Kconfig symbol FB_OMAP_CONSISTENT_DMA_SIZE got removed
> in v3.8, with commit 6ba54ab4a49bbad736b0254aa6bdf0cb83013815 ("ARM:
> OMAP: Remove omap_init_consistent_dma_size()"). Remove this symbol too.
>
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> ---
> Eyeball tested only.
>
> drivers/video/omap/Kconfig | 11 -----------
> 1 file changed, 11 deletions(-)
>
> diff --git a/drivers/video/omap/Kconfig b/drivers/video/omap/Kconfig
> index e512581..0bc3a93 100644
> --- a/drivers/video/omap/Kconfig
> +++ b/drivers/video/omap/Kconfig
> @@ -39,17 +39,6 @@ config FB_OMAP_LCD_MIPID
> the Mobile Industry Processor Interface DBI-C/DCS
> specification. (Supported LCDs: Philips LPH8923, Sharp LS041Y3)
>
> -config FB_OMAP_CONSISTENT_DMA_SIZE
> - int "Consistent DMA memory size (MB)"
> - depends on FB_OMAP
> - range 1 14
> - default 2
> - help
> - Increase the DMA consistent memory size according to your video
> - memory needs, for example if you want to use multiple planes.
> - The size must be 2MB aligned.
> - If unsure say 1.
> -
> config FB_OMAP_DMA_TUNE
> bool "Set DMA SDRAM access priority high"
> depends on FB_OMAP
>
Thanks, I'll add this to omapdss tree.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH v2] fbdev: sh_mobile_lcdc: fixup B side hsync adjust settings
From: Laurent Pinchart @ 2013-03-19 12:38 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <87txoqmo3p.wl%kuninori.morimoto.gx@renesas.com>
Hi Simon,
On Tuesday 19 March 2013 13:19:52 Simon Horman wrote:
> On Tue, Mar 05, 2013 at 04:45:46PM +0100, Laurent Pinchart wrote:
> > On Monday 04 March 2013 21:07:10 Kuninori Morimoto wrote:
> > > The lcdc B side horizon output is shifted
> > > if sh_mobile_lcdc_pan() was called.
> > > This patch fixup this issue.
> > > It is tested on R8A7740 Armadillo800eva HDMI output.
> > > Special thanks to Fukushima-san, and Sano-san
> > >
> > > Reported-by: Osamu Fukushima <osamu.fukushima.wr@renesas.com>
> > > Signed-off-by: Hideyuki Sano <hideyuki.sano.dn@renesas.com>
> > > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> >
> > Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> Laurent, can you handle getting this merged?
> If not, please let me know who to prod.
We have no fbdev maintainer anymore. Can this be pushed through your tree ?
--
Regards,
Laurent Pinchart
^ 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