* Re: [PATCH] fbdev: mxsfb: Add support for mx6sl and mx6sx
From: Fabio Estevam @ 2014-11-06 13:00 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1414243727-23447-1-git-send-email-festevam@gmail.com>
Hi Tomi,
On Sat, Oct 25, 2014 at 11:28 AM, Fabio Estevam <festevam@gmail.com> wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> mx6sl and mx6sx share the same LCD controller as mx23 and mx28.
>
> Add support for it.
>
> The basic difference is the number of clocks that are required:
>
> - mx23/mx28: only one clock
> - mx6sl: two clocks
> - mx6sx: three clocks
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> Changes since RFC:
> - Simplified the clock handling as suggested by Tomi
If you are happy with this one, could we get it into 3.19? Thanks
^ permalink raw reply
* Re: [PATCH] fbdev: mxsfb: Add support for mx6sl and mx6sx
From: Tomi Valkeinen @ 2014-11-06 14:14 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1414243727-23447-1-git-send-email-festevam@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 703 bytes --]
On 25/10/14 16:28, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> mx6sl and mx6sx share the same LCD controller as mx23 and mx28.
>
> Add support for it.
>
> The basic difference is the number of clocks that are required:
>
> - mx23/mx28: only one clock
> - mx6sl: two clocks
> - mx6sx: three clocks
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> Changes since RFC:
> - Simplified the clock handling as suggested by Tomi
>
> drivers/video/fbdev/Kconfig | 2 +-
> drivers/video/fbdev/mxsfb.c | 19 +++++++++++++++++++
> 2 files changed, 20 insertions(+), 1 deletion(-)
Looks fine to me, queued for 3.19.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v4 0/5] simplefb: add clock handling code
From: Tomi Valkeinen @ 2014-11-06 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <54534523.8080801@ti.com>
[-- Attachment #1: Type: text/plain, Size: 766 bytes --]
On 31/10/14 10:15, Tomi Valkeinen wrote:
> Hi Hans,
>
> On 22/10/14 19:45, Hans de Goede wrote:
>
>> -We will add a clocks property to the simplefb devicetree bindings, so
>> that u-boot setup framebuffers passed to the kernel (for early console
>> support) can properly list the clocks used, and simplefb can claim them to
>> avoid them getting turned off, thereby breaking the early console
>
> Perhaps this has been discussed earlier, but I started to wonder if
> managing clocks is enough.
>
> What about regulators (to power the LCD), gpios (to keep the LCD
> enabled) and pinctrl (for video signals)? I guess any those could be
> reset by the kernel if no driver uses them.
Hans, ping. Have these been already discussed?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] m501fb: don't return zero on failure path in sm501fb_probe()
From: Tomi Valkeinen @ 2014-11-06 14:22 UTC (permalink / raw)
To: Alexey Khoroshilov
Cc: Jean-Christophe Plagniol-Villard, linux-fbdev, linux-kernel,
ldv-project
In-Reply-To: <1414795247-14686-1-git-send-email-khoroshilov@ispras.ru>
[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]
On 01/11/14 00:40, Alexey Khoroshilov wrote:
> If no framebuffers found, sm501fb_probe() breaks off initialization,
> deallocates sm501fb_info, but returns zero. As a result, use after free
> can happen in sm501fb_remove().
>
> The patch adds -ENODEV as a return value in this case.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
> ---
> drivers/video/fbdev/sm501fb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/fbdev/sm501fb.c b/drivers/video/fbdev/sm501fb.c
> index 9e74e8fbe074..8b98b011fc04 100644
> --- a/drivers/video/fbdev/sm501fb.c
> +++ b/drivers/video/fbdev/sm501fb.c
> @@ -1988,6 +1988,7 @@ static int sm501fb_probe(struct platform_device *pdev)
> if (info->fb[HEAD_PANEL] == NULL &&
> info->fb[HEAD_CRT] == NULL) {
> dev_err(dev, "no framebuffers found\n");
> + ret = -ENODEV;
> goto err_alloc;
> }
>
>
Thanks, queued for 3.19.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH v4 0/5] simplefb: add clock handling code
From: Hans de Goede @ 2014-11-06 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <545B8338.8060908@ti.com>
Hi,
On 11/06/2014 03:18 PM, Tomi Valkeinen wrote:
> On 31/10/14 10:15, Tomi Valkeinen wrote:
>> Hi Hans,
>>
>> On 22/10/14 19:45, Hans de Goede wrote:
>>
>>> -We will add a clocks property to the simplefb devicetree bindings, so
>>> that u-boot setup framebuffers passed to the kernel (for early console
>>> support) can properly list the clocks used, and simplefb can claim them to
>>> avoid them getting turned off, thereby breaking the early console
>>
>> Perhaps this has been discussed earlier, but I started to wonder if
>> managing clocks is enough.
>>
>> What about regulators (to power the LCD), gpios (to keep the LCD
>> enabled) and pinctrl (for video signals)? I guess any those could be
>> reset by the kernel if no driver uses them.
>
> Hans, ping. Have these been already discussed?
Yes, and I already responded to your original mail on this on Oct. 31th,
for some reason my mail client drops you from the CC, when I do a reply-to-all
to one of your mails (I've added you manually this time).
My replies did go to simple-fb@vger.kernel.org .I'll forward my 2 mails on this
to you.
Regards,
Hans
^ permalink raw reply
* Your mailbox has Exceeded the quota limit
From: System Administrator @ 2014-11-06 17:23 UTC (permalink / raw)
To: linux-fbdev
Dear user,
Your mailbox has Exceeded the quota limit set by the administrator, you will not be able to send or receive mailuntil you revalidates your account.
Please click the link below or copy paste to your browser to validate your mailbox.
http://www.urlme.co/quota-service
Failure to do this will result limited access to your mailbox and failure to update your account within 48-hours, of this update notification, your account will be closed permanently.
Thanks
System Administrator.
^ permalink raw reply
* Re: [PATCH 2/2] backlight: pwm: clean up pwm requested using legacy API
From: Vladimir Zapolskiy @ 2014-11-06 22:10 UTC (permalink / raw)
To: Greg KH, Thierry Reding
Cc: linux-fbdev, linux-pwm, Jingoo Han, Bryan Wu, Lee Jones,
Dmitry Eremin-Solenikov
In-Reply-To: <20141011142156.GC11456@kroah.com>
Hello Greg, Thierry,
On 11.10.2014 17:21, Greg KH wrote:
> On Sat, Oct 11, 2014 at 04:46:26PM +0300, Vladimir Zapolskiy wrote:
>> If PWM device is requested by means of legacy API pwm_request(), its
>> resources are not freed on module unbind, which may cause an oops on
>> access, e.g. by reading /sys/kernel/debug/pwm.
>>
>> Reported-by: Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com>
>> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
>> ---
>> drivers/video/backlight/pwm_bl.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>
> <formletter>
>
> This is not the correct way to submit patches for inclusion in the
> stable kernel tree. Please read Documentation/stable_kernel_rules.txt
> for how to do this properly.
>
> </formletter>
> --
could you please review the change? I believe it would be nice to have
oops fix in v3.18.
--
With best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH 2/2] backlight: pwm: clean up pwm requested using legacy API
From: Greg KH @ 2014-11-06 22:54 UTC (permalink / raw)
To: Vladimir Zapolskiy
Cc: Thierry Reding, linux-fbdev, linux-pwm, Jingoo Han, Bryan Wu,
Lee Jones, Dmitry Eremin-Solenikov
In-Reply-To: <545BF1D1.30304@mentor.com>
On Fri, Nov 07, 2014 at 12:10:25AM +0200, Vladimir Zapolskiy wrote:
> Hello Greg, Thierry,
>
> On 11.10.2014 17:21, Greg KH wrote:
> > On Sat, Oct 11, 2014 at 04:46:26PM +0300, Vladimir Zapolskiy wrote:
> >> If PWM device is requested by means of legacy API pwm_request(), its
> >> resources are not freed on module unbind, which may cause an oops on
> >> access, e.g. by reading /sys/kernel/debug/pwm.
> >>
> >> Reported-by: Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com>
> >> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> >> ---
> >> drivers/video/backlight/pwm_bl.c | 4 ++++
> >> 1 file changed, 4 insertions(+)
> >
> > <formletter>
> >
> > This is not the correct way to submit patches for inclusion in the
> > stable kernel tree. Please read Documentation/stable_kernel_rules.txt
> > for how to do this properly.
> >
> > </formletter>
> > --
>
> could you please review the change? I believe it would be nice to have
> oops fix in v3.18.
drivers/video/ is not under my control, so there's nothing I can do
here, sorry...
^ permalink raw reply
* Re: [PATCH 2/2] backlight: pwm: clean up pwm requested using legacy API
From: Lee Jones @ 2014-11-07 11:50 UTC (permalink / raw)
To: Greg KH
Cc: Vladimir Zapolskiy, Thierry Reding, linux-fbdev, linux-pwm,
Jingoo Han, Bryan Wu, Dmitry Eremin-Solenikov
In-Reply-To: <20141106225420.GA2770@kroah.com>
On Thu, 06 Nov 2014, Greg KH wrote:
> On Fri, Nov 07, 2014 at 12:10:25AM +0200, Vladimir Zapolskiy wrote:
> > Hello Greg, Thierry,
> >
> > On 11.10.2014 17:21, Greg KH wrote:
> > > On Sat, Oct 11, 2014 at 04:46:26PM +0300, Vladimir Zapolskiy wrote:
> > >> If PWM device is requested by means of legacy API pwm_request(), its
> > >> resources are not freed on module unbind, which may cause an oops on
> > >> access, e.g. by reading /sys/kernel/debug/pwm.
> > >>
> > >> Reported-by: Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com>
> > >> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> > >> ---
> > >> drivers/video/backlight/pwm_bl.c | 4 ++++
> > >> 1 file changed, 4 insertions(+)
> > >
> > > <formletter>
> > >
> > > This is not the correct way to submit patches for inclusion in the
> > > stable kernel tree. Please read Documentation/stable_kernel_rules.txt
> > > for how to do this properly.
> > >
> > > </formletter>
> > > --
> >
> > could you please review the change? I believe it would be nice to have
> > oops fix in v3.18.
>
> drivers/video/ is not under my control, so there's nothing I can do
> here, sorry...
I can apply this with Thierry's Ack.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 2/2] backlight: pwm: clean up pwm requested using legacy API
From: Thierry Reding @ 2014-11-07 13:47 UTC (permalink / raw)
To: Vladimir Zapolskiy
Cc: linux-fbdev, linux-pwm, Jingoo Han, Bryan Wu, Lee Jones, stable
In-Reply-To: <1413035186-11771-3-git-send-email-vladimir_zapolskiy@mentor.com>
[-- Attachment #1: Type: text/plain, Size: 652 bytes --]
On Sat, Oct 11, 2014 at 04:46:26PM +0300, Vladimir Zapolskiy wrote:
> If PWM device is requested by means of legacy API pwm_request(), its
> resources are not freed on module unbind, which may cause an oops on
> access, e.g. by reading /sys/kernel/debug/pwm.
>
> Reported-by: Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com>
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> ---
> drivers/video/backlight/pwm_bl.c | 4 ++++
> 1 file changed, 4 insertions(+)
Hopefully this can soon go away when all users of the legacy API have
been converted. Until then:
Acked-by: Thierry Reding <thierry.reding@gmail.com>
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] backlight: pwm: don't call legacy pwm request for device defined in dt
From: Thierry Reding @ 2014-11-07 13:48 UTC (permalink / raw)
To: Vladimir Zapolskiy
Cc: linux-fbdev, linux-pwm, Jingoo Han, Bryan Wu, Lee Jones
In-Reply-To: <1413035186-11771-2-git-send-email-vladimir_zapolskiy@mentor.com>
[-- Attachment #1: Type: text/plain, Size: 947 bytes --]
On Sat, Oct 11, 2014 at 04:46:25PM +0300, Vladimir Zapolskiy wrote:
> Platform PWM backlight data provided by board's device tree should be
> complete enough to successfully request a pwm device using pwm_get() API.
>
> Based on initial implementation done by Dmitry Eremin-Solenikov.
>
> Reported-by: Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com>
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: Bryan Wu <cooloney@gmail.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> ---
> drivers/video/backlight/pwm_bl.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
I don't really understand what this is supposed to do. The commit
message doesn't make a very good job of explaining it either.
Can you describe in more detail what problem this fixes and why it
should be merged?
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] backlight: pwm: don't call legacy pwm request for device defined in dt
From: Vladimir Zapolskiy @ 2014-11-07 14:19 UTC (permalink / raw)
To: Thierry Reding; +Cc: linux-fbdev, linux-pwm, Jingoo Han, Bryan Wu, Lee Jones
In-Reply-To: <20141107134848.GB31950@ulmo>
Hi Thierry,
On 07.11.2014 15:48, Thierry Reding wrote:
> On Sat, Oct 11, 2014 at 04:46:25PM +0300, Vladimir Zapolskiy wrote:
>> Platform PWM backlight data provided by board's device tree should be
>> complete enough to successfully request a pwm device using pwm_get() API.
>>
>> Based on initial implementation done by Dmitry Eremin-Solenikov.
>>
>> Reported-by: Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com>
>> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
>> Cc: Thierry Reding <thierry.reding@gmail.com>
>> Cc: Jingoo Han <jg1.han@samsung.com>
>> Cc: Bryan Wu <cooloney@gmail.com>
>> Cc: Lee Jones <lee.jones@linaro.org>
>> ---
>> drivers/video/backlight/pwm_bl.c | 14 +++++++-------
>> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> I don't really understand what this is supposed to do. The commit
> message doesn't make a very good job of explaining it either.
>
> Can you describe in more detail what problem this fixes and why it
> should be merged?
thank you for review.
As it is shown by the code this particular change rejects fallback to
legacy PWM device request (which itself in turn is fixed in the next
commit) for boards with supplied DTS, "pwm-backlight" compatible node
and unregistered corresponding PWM device in that node.
I don't know if there is a good enough reason to register PWM backlight
device connected to some quite arbitrary PWM device, if no PWM device
information is given in the "pwm-backlight" compatible node, so I think
it makes sense to change the default policy.
--
With best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH 1/2] backlight: pwm: don't call legacy pwm request for device defined in dt
From: Vladimir Zapolskiy @ 2014-11-07 14:57 UTC (permalink / raw)
To: Thierry Reding; +Cc: linux-fbdev, linux-pwm, Jingoo Han, Bryan Wu, Lee Jones
In-Reply-To: <545CD4DC.4030409@mentor.com>
Thierry,
On 07.11.2014 16:19, Vladimir Zapolskiy wrote:
> Hi Thierry,
>
> On 07.11.2014 15:48, Thierry Reding wrote:
>> On Sat, Oct 11, 2014 at 04:46:25PM +0300, Vladimir Zapolskiy wrote:
>>> Platform PWM backlight data provided by board's device tree should be
>>> complete enough to successfully request a pwm device using pwm_get() API.
>>>
>>> Based on initial implementation done by Dmitry Eremin-Solenikov.
>>>
>>> Reported-by: Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com>
>>> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
>>> Cc: Thierry Reding <thierry.reding@gmail.com>
>>> Cc: Jingoo Han <jg1.han@samsung.com>
>>> Cc: Bryan Wu <cooloney@gmail.com>
>>> Cc: Lee Jones <lee.jones@linaro.org>
>>> ---
>>> drivers/video/backlight/pwm_bl.c | 14 +++++++-------
>>> 1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> I don't really understand what this is supposed to do. The commit
>> message doesn't make a very good job of explaining it either.
>>
>> Can you describe in more detail what problem this fixes and why it
>> should be merged?
>
> thank you for review.
>
> As it is shown by the code this particular change rejects fallback to
> legacy PWM device request (which itself in turn is fixed in the next
> commit) for boards with supplied DTS, "pwm-backlight" compatible node
> and unregistered corresponding PWM device in that node.
>
> I don't know if there is a good enough reason to register PWM backlight
> device connected to some quite arbitrary PWM device, if no PWM device
> information is given in the "pwm-backlight" compatible node, so I think
> it makes sense to change the default policy.
>
also please note that
Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
quite fairly describes "pwms" as a required property, but right now this
statement from the documentation is wrong, it is possible to register
pwm-backlight device driver (using notorious pwm_request() legacy API)
connected to some unspecified pwm device.
I don't think that the current registration policy is correct, that's
why I propose to fix the logic instead of making a documentation update.
--
With best wishes,
Vladimir
^ permalink raw reply
* Loan Empowerment
From: ALLIANCE WEST FINANCE. @ 2014-11-10 8:07 UTC (permalink / raw)
To: linux-fbdev
hallo,
Willkommen in der Kreditvergabe Firma Allianz Westen Finanz gestalten wir geschäftliche oder persönliche Darlehen in Höhe von 10.000 € und mehr als 100 Mio. € auf einem erschwinglichen Zinssatz von 2% pro Jahr? reagieren freundlich heute zu leihen.
Grüße,
Mr. Freeman Paulson
Allianz Westen Financial.
Tel: +447937438531
Tel: +447937438531
---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
^ permalink raw reply
* Re: [PATCH 2/2] backlight: pwm: clean up pwm requested using legacy API
From: Lee Jones @ 2014-11-10 10:01 UTC (permalink / raw)
To: Vladimir Zapolskiy
Cc: linux-fbdev, linux-pwm, Thierry Reding, Jingoo Han, Bryan Wu,
stable
In-Reply-To: <1413035186-11771-3-git-send-email-vladimir_zapolskiy@mentor.com>
On Sat, 11 Oct 2014, Vladimir Zapolskiy wrote:
> If PWM device is requested by means of legacy API pwm_request(), its
> resources are not freed on module unbind, which may cause an oops on
> access, e.g. by reading /sys/kernel/debug/pwm.
>
> Reported-by: Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com>
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> ---
> drivers/video/backlight/pwm_bl.c | 4 ++++
> 1 file changed, 4 insertions(+)
Applied with Thierry's Ack.
> diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> index dd7aaf7..40770dd 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -34,6 +34,7 @@ struct pwm_bl_data {
> struct regulator *power_supply;
> struct gpio_desc *enable_gpio;
> unsigned int scale;
> + bool legacy;
> int (*notify)(struct device *,
> int brightness);
> void (*notify_after)(struct device *,
> @@ -274,6 +275,7 @@ static int pwm_backlight_probe(struct platform_device *pdev)
> pb->pwm = devm_pwm_get(&pdev->dev, NULL);
> if (IS_ERR(pb->pwm) && !pdev->dev.of_node) {
> dev_err(&pdev->dev, "unable to request PWM, trying legacy API\n");
> + pb->legacy = true;
> pb->pwm = pwm_request(data->pwm_id, "pwm-backlight");
> }
>
> @@ -339,6 +341,8 @@ static int pwm_backlight_remove(struct platform_device *pdev)
>
> if (pb->exit)
> pb->exit(&pdev->dev);
> + if (pb->legacy)
> + pwm_free(pb->pwm);
>
> return 0;
> }
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 3/4] arm: dts: omap3-gta04: Add handling for tv output
From: Tony Lindgren @ 2014-11-10 23:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1415051968-4878-4-git-send-email-marek@goldelico.com>
* Marek Belisko <marek@goldelico.com> [141103 14:01]:
> Add handling for gta04 tv out chain:
> venc -> opa362 -> svideo
>
> Signed-off-by: Marek Belisko <marek@goldelico.com>
> ---
> arch/arm/boot/dts/omap3-gta04.dtsi | 48 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
Applying this patch into omap-for-v3.19/dt thanks.
Tony
^ permalink raw reply
* Re: [PATCH 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register
From: Tony Lindgren @ 2014-11-10 23:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1415051968-4878-5-git-send-email-marek@goldelico.com>
* Marek Belisko <marek@goldelico.com> [141103 14:01]:
> gta04 board need for tvout enabled 2 bits in devconf1 register (tvbypass and acbias).
> Add single pinmux entry and enable it.
>
> Signed-off-by: Marek Belisko <marek@goldelico.com>
> ---
> arch/arm/boot/dts/omap3-gta04.dtsi | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
> index e4d05f0..a456d37 100644
> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> @@ -118,6 +118,17 @@
> };
> };
> };
> +
> + /* pinmux for devconf1 */
> + control_devconf1: pinmux@480022d8 {
> + compatible = "pinctrl-single";
> + reg = <0x480022d8 4>; /* single register */
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-single,bit-per-mux;
> + pinctrl-single,register-width = <32>;
> + pinctrl-single,function-mask = <0xfc0bd5>;
> + };
> };
>
The pinctrl-single entry should be in omap3.dtsi as the mux register is there
for all the omap3 devices, can you please update the patch for that?
Regards,
Tony
> &omap3_pmx_core {
> @@ -497,3 +508,14 @@
> };
> };
> };
> +
> +&control_devconf1 {
> + pinctrl-name = "default";
> + pinctrl-0 = < &tv_acbias_pins>;
> +
> + tv_acbias_pins: pinmux_tv_acbias_pins {
> + pinctrl-single,bits = <
> + 0 0x40800 0x40800
> + >;
> + };
> +};
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH 3/4] arm: dts: omap3-gta04: Add handling for tv output
From: Tomi Valkeinen @ 2014-11-11 7:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20141110233050.GC31454@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 570 bytes --]
Tony,
On 11/11/14 01:30, Tony Lindgren wrote:
> * Marek Belisko <marek@goldelico.com> [141103 14:01]:
>> Add handling for gta04 tv out chain:
>> venc -> opa362 -> svideo
>>
>> Signed-off-by: Marek Belisko <marek@goldelico.com>
>> ---
>> arch/arm/boot/dts/omap3-gta04.dtsi | 48 ++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 48 insertions(+)
>
> Applying this patch into omap-for-v3.19/dt thanks.
There are changes needed for this series, so don't apply yet.
I'll try to find the time to do a review and send comments soon.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 02/15] GPIO: port LoCoMo gpio support from old driver
From: Dmitry Eremin-Solenikov @ 2014-11-11 13:16 UTC (permalink / raw)
To: Mark Brown
Cc: Linus Walleij, linux-arm-kernel@lists.infradead.org,
linux-gpio@vger.kernel.org, Linux Input,
linux-leds@vger.kernel.org, linux-spi@vger.kernel.org,
linux-fbdev@vger.kernel.org, alsa-devel@alsa-project.org,
Andrea Adami, Russell King, Daniel Mack, Haojian Zhuang,
Robert Jarzmik, Alexandre Courbot, Dmitry Torokhov, Bryan Wu,
Richard Purdie, Samuel Ortiz, Lee Jones
In-Reply-To: <20141106060335.GR8509@sirena.org.uk>
2014-11-06 9:03 GMT+03:00 Mark Brown <broonie@kernel.org>:
> On Thu, Nov 06, 2014 at 01:33:24AM +0400, Dmitry Eremin-Solenikov wrote:
>> 2014-11-03 16:43 GMT+03:00 Linus Walleij <linus.walleij@linaro.org>:
>
>> > Yes that's the point: if you use regmap mmio you get the RMW-locking
>> > for free, with the regmap implementation.
>
>> Just to be more concrete. Currently locomo_gpio_ack_irq() function uses
>> one lock and one unlock for doing 3 consecutive RMW I I convert locomo
>> to regmap, will that be 3 lock/unlock calls or still one? (Or maybe I'm
>> trying to be over-protective here and adding more lock/unlock cycles
>> won't matter that much?)
>
> You'll get three lock/unlocks, we could add an interface for bulk
> updates under one lock if it's important though.
>
>> Next question: if I have to export regmap to several subdrivers, is it better
>> to have one big regmap or to have one-map-per-driver approach?
>
> One regmap for the physical register map which is shared between all the
> users.
Mark, Linus,
Just to better understand your suggestions: do you want me to convert
to regmap only gpio driver or do you suggest to convert all LoCoMo drivers?
That is doable, of course, but the amount of changes is overwhelming.
Also I'm concerned about the performance impact from going through
regmap layers.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 02/15] GPIO: port LoCoMo gpio support from old driver
From: Mark Brown @ 2014-11-11 13:23 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov
Cc: Linus Walleij,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux Input,
linux-leds-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org, Andrea Adami,
Russell King, Daniel Mack, Haojian Zhuang, Robert Jarzmik,
Alexandre Courbot, Dmitry Torokhov, Bryan Wu, Richard Purdie,
Samuel Ortiz, Lee Jones
In-Reply-To: <CALT56yPr42FV66USngocw=eWPt81d5R2MJxmzBnv02HOMmXAkA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 397 bytes --]
On Tue, Nov 11, 2014 at 05:16:38PM +0400, Dmitry Eremin-Solenikov wrote:
> Just to better understand your suggestions: do you want me to convert
> to regmap only gpio driver or do you suggest to convert all LoCoMo drivers?
> That is doable, of course, but the amount of changes is overwhelming.
> Also I'm concerned about the performance impact from going through
> regmap layers.
I don't care.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] arm: dts: omap3-gta04: Add handling for tv output
From: Tony Lindgren @ 2014-11-11 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5461BDC6.7090308@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [141110 23:44]:
> Tony,
>
> On 11/11/14 01:30, Tony Lindgren wrote:
> > * Marek Belisko <marek@goldelico.com> [141103 14:01]:
> >> Add handling for gta04 tv out chain:
> >> venc -> opa362 -> svideo
> >>
> >> Signed-off-by: Marek Belisko <marek@goldelico.com>
> >> ---
> >> arch/arm/boot/dts/omap3-gta04.dtsi | 48 ++++++++++++++++++++++++++++++++++++++
> >> 1 file changed, 48 insertions(+)
> >
> > Applying this patch into omap-for-v3.19/dt thanks.
>
> There are changes needed for this series, so don't apply yet.
>
> I'll try to find the time to do a review and send comments soon.
I've already pushed out the omap-for-v3.19/dt branch with
this patch buried in it. I'd rather not start redoing the
branch if the $subject patch is mostly correct and usable
with changes to the driver patches.
However, if the $subject patch needs to be redone for
the driver changes, let me know and I'll redo the branch.
Regards,
Tony
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Grant Likely @ 2014-11-11 16:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <542E56AB.40208@redhat.com>
On Fri, 03 Oct 2014 09:56:27 +0200
, Hans de Goede <hdegoede@redhat.com>
wrote:
> On 10/03/2014 01:31 AM, Julian Calaby wrote:
> > On Fri, Oct 3, 2014 at 1:14 AM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> >> Because you are creating two different device tree nodes describing a
> >> single piece of hardware and that's not suppose to happen in a device
> >> tree. The accurate description of the hardware is being perverted to
> >> solve a software problem.
> >>
> >> One node describes the hardware in a format to make simplefb happy.
> >> Another node describes the same hardware in a format to make the
> >> device specific driver happy.
> >
> > Stupid question: What about mangling an existing device node to be
> > simplefb compatible, and writing simplefb to be binding agnostic?
>
> That will not work, with simplefb a single node represents the currently
> active video output. While in real hardware that may involve multiple
> blocks, e.g on sunxi for hdmi out this involves the compositor (which
> generates video data from 1 or more layers) which feeds into the
> lcd-controller (which in this case is only used to generate hsync + vsync)
> signals really, which feeds into the hdmi encoder, all 3 of which are
> separate hardware blocks with their own clocks, etc.
The answer here should be, 'whoever does the DMA'.
Julian's suggestion is actually the sanest approach, and there is
precedence for doing exactly that in DT, both for serial devices
(of_serial.c) and framebuffers (offb.c).
g.
^ permalink raw reply
* Re: [PATCH v4 1/5] simplefb: Add simplefb MAINTAINERS entry
From: Grant Likely @ 2014-11-11 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1413996311-4287-2-git-send-email-hdegoede@redhat.com>
On Wed, 22 Oct 2014 18:45:07 +0200
, Hans de Goede <hdegoede@redhat.com>
wrote:
> During the discussion about adding clock handling code to simplefb, it became
> clear that simplefb currently does not have an active maintainer.
>
> I've discussed this with Stephen Warren <swarren@wwwdotorg.org>, the original
> author of simplefb, and with his permisson I'm picking up maintainership of
> simplefb.
>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Acked-by: Stephen Warren <swarren@wwwdotorg.org>
> Reviewed-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Grant Likely <grant.likely@linaro.org>
> ---
> MAINTAINERS | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 73d1aef..6e92e73 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8416,6 +8416,14 @@ F: drivers/media/usb/siano/
> F: drivers/media/usb/siano/
> F: drivers/media/mmc/siano/
>
> +SIMPLEFB FB DRIVER
> +M: Hans de Goede <hdegoede@redhat.com>
> +L: linux-fbdev@vger.kernel.org
> +S: Maintained
> +F: Documentation/devicetree/bindings/video/simple-framebuffer.txt
> +F: drivers/video/fbdev/simplefb.c
> +F: include/linux/platform_data/simplefb.h
> +
> SH_VEU V4L2 MEM2MEM DRIVER
> L: linux-media@vger.kernel.org
> S: Orphan
> --
> 2.1.0
>
^ permalink raw reply
* Re: [PATCH v4 3/5] simplefb: formalize pseudo palette handling
From: Grant Likely @ 2014-11-11 16:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1413996311-4287-4-git-send-email-hdegoede@redhat.com>
On Wed, 22 Oct 2014 18:45:09 +0200
, Hans de Goede <hdegoede@redhat.com>
wrote:
> From: Luc Verhaegen <libv@skynet.be>
>
Patch description? Write a proper changelog before merging please.
Describe why the change is necessary and what was done. You need to give
future readers some information about this patch. Heck, you're listed in
MAINTAINERS, you should be *enforcing* proper changelogs.
The code looks fine though.
Acked-by: Grant Likely <grant.likely@linaro.org>
> Signed-off-by: Luc Verhaegen <libv@skynet.be>
> Acked-by: Stephen Warren <swarren@nvidia.com>
> [hdegoede@redhat.com: drop unnecessary void * cast]
> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Reviewed-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
> ---
> drivers/video/fbdev/simplefb.c | 15 ++++++++++++---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
> index 210f3a0..ec112c1 100644
> --- a/drivers/video/fbdev/simplefb.c
> +++ b/drivers/video/fbdev/simplefb.c
> @@ -41,6 +41,8 @@ static struct fb_var_screeninfo simplefb_var = {
> .vmode = FB_VMODE_NONINTERLACED,
> };
>
> +#define PSEUDO_PALETTE_SIZE 16
> +
> static int simplefb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
> u_int transp, struct fb_info *info)
> {
> @@ -50,7 +52,7 @@ static int simplefb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
> u32 cb = blue >> (16 - info->var.blue.length);
> u32 value;
>
> - if (regno >= 16)
> + if (regno >= PSEUDO_PALETTE_SIZE)
> return -EINVAL;
>
> value = (cr << info->var.red.offset) |
> @@ -163,11 +165,16 @@ static int simplefb_parse_pd(struct platform_device *pdev,
> return 0;
> }
>
> +struct simplefb_par {
> + u32 palette[PSEUDO_PALETTE_SIZE];
> +};
> +
> static int simplefb_probe(struct platform_device *pdev)
> {
> int ret;
> struct simplefb_params params;
> struct fb_info *info;
> + struct simplefb_par *par;
> struct resource *mem;
>
> if (fb_get_options("simplefb", NULL))
> @@ -188,11 +195,13 @@ static int simplefb_probe(struct platform_device *pdev)
> return -EINVAL;
> }
>
> - info = framebuffer_alloc(sizeof(u32) * 16, &pdev->dev);
> + info = framebuffer_alloc(sizeof(struct simplefb_par), &pdev->dev);
> if (!info)
> return -ENOMEM;
> platform_set_drvdata(pdev, info);
>
> + par = info->par;
> +
> info->fix = simplefb_fix;
> info->fix.smem_start = mem->start;
> info->fix.smem_len = resource_size(mem);
> @@ -225,7 +234,7 @@ static int simplefb_probe(struct platform_device *pdev)
> framebuffer_release(info);
> return -ENODEV;
> }
> - info->pseudo_palette = (void *)(info + 1);
> + info->pseudo_palette = par->palette;
>
> dev_info(&pdev->dev, "framebuffer at 0x%lx, 0x%x bytes, mapped to 0x%p\n",
> info->fix.smem_start, info->fix.smem_len,
> --
> 2.1.0
>
^ permalink raw reply
* Re: [PATCH v4 2/5] dt-bindings: Add a clocks property to the simple-framebuffer binding
From: Grant Likely @ 2014-11-11 21:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1413996311-4287-3-git-send-email-hdegoede@redhat.com>
On Wed, 22 Oct 2014 18:45:08 +0200
, Hans de Goede <hdegoede@redhat.com>
wrote:
> A simple-framebuffer node represents a framebuffer setup by the firmware /
> bootloader. Such a framebuffer may have a number of clocks in use, add a
> property to communicate this to the OS.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> Reviewed-by: Mike Turquette <mturquette@linaro.org>
> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Reviewed-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>
> --
> Changes in v2:
> -Added Reviewed-by: Mike Turquette <mturquette@linaro.org>
> Changes in v3:
> -Updated description to make clear simplefb deals with more then just memory
> ---
> Documentation/devicetree/bindings/video/simple-framebuffer.txt | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> index 70c26f3..172ad5f 100644
> --- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> @@ -1,8 +1,8 @@
> Simple Framebuffer
>
> -A simple frame-buffer describes a raw memory region that may be rendered to,
> -with the assumption that the display hardware has already been set up to scan
> -out from that buffer.
> +A simple frame-buffer describes a frame-buffer setup by firmware or
> +the bootloader, with the assumption that the display hardware has already
> +been set up to scan out from the memory pointed to by the reg property.
>
> Required properties:
> - compatible: "simple-framebuffer"
> @@ -14,6 +14,9 @@ Required properties:
> - r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b).
> - a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
>
> +Optional properties:
> +- clocks : List of clocks used by the framebuffer
Please change to the following:
- clocks : List of clocks used by the framebuffer. Clocks listed here
are expected to already be configured correctly. The OS must
ensure these clocks are not modified or disabled while the
simple framebuffer remains active.
g.
^ 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