* Re: [PATCH v2 1/3] devicetree/bindings: add reset-gpios and vcc-supply for panel-dpi
From: Rob Herring @ 2015-12-30 14:44 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Uwe Kleine-König, Tomi Valkeinen,
Jean-Christophe Plagniol-Villard, Linux Fbdev development list,
linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Sascha Hauer,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAMuHMdUJPUeyhtM3=S4dOgevpnyd0TgkJy7QchPewO4KOxsWvA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Dec 30, 2015 at 4:29 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Tue, Dec 29, 2015 at 9:54 PM, Rob Herring <robh@kernel.org> wrote:
>> On Sun, Dec 20, 2015 at 12:13:20PM +0100, Uwe Kleine-König wrote:
>>> Some displays have a reset input and/or need a regulator to function
>>> properly. Allow to specify them for panel-dpi devices.
>>>
>>> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>>> ---
>>> Documentation/devicetree/bindings/display/panel/panel-dpi.txt | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
>>> index 216c894d4f99..b52ac52757df 100644
>>> --- a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
>>> +++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
>>> @@ -7,6 +7,8 @@ Required properties:
>>> Optional properties:
>>> - label: a symbolic name for the panel
>>> - enable-gpios: panel enable gpio
>>> +- reset-gpios: GPIO to control the RESET pin
>>
>> The problem with this in a generic binding is what if the panel has
>> ordering requirements like enable gpio has to be inactive when reset
>> is deasserted?
>>
>>> +- vcc-supply: phandle of regulator that will be used to enable power to the display
>>
>> What if there are 2 supplies?
>
> So it should be "vcc-supplies". Most properties containing phandles use plural
> naming, even if Linux supports a single phandle only (e.g. "power-domains").
> You also may want to add an optional "vcc-supply-names" property to
> differentiate.
True, but the regulator binding is an exception and we don't do that
with it. The prefix is the name and other supplies are not going to be
called Vcc.
Rob
^ permalink raw reply
* Re: [PATCH v4 09/24] regulator: pwm: use pwm_get/set_default_xxx() helpers where appropriate
From: Boris Brezillon @ 2015-12-30 11:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20151202113720.0a6517b1@bbrezillon>
Hi Thierry,
I'm trying to get these "atomic PWM config" and "initial PWM state
retrieval" stuff in for at least 3 releases. I can understand that some
things have to be discussed and reworked in order to be good enough for
mainline, but that's not what I'm seeing here.
You and Mark raised some concerns about the usage of the
pwm_{get,set}_default_xxx() helpers which I tried to address by
proposing something else. I asked you to comment on it a few weeks ago,
but you never did.
You also told me that you would search for an alternative solution, but
never came back to me.
So I think it's now time to take a decision, whether you want to take
this series with some minor reworks (changing function names to clarify
what is a default and current PWM state), or decide that you expect
something else (but in that case I'd like you to explain what you want).
And by the way, the behavior you're complaining about is already
currently in place: even if the pwm_get_period() function does not
contain the 'default' word in its name, what's actually returned is the
default (or reference) period (the one retrieved from the DT or the PWM
lookup table) not the period currently in use on the PWM device (the
same goes for other helpers).
Can we please settle on something for 4.6 so that I can repost a series
when 4.5-rc1 is out?
Thanks,
Boris
On Wed, 2 Dec 2015 11:37:20 +0100
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> Hi,
>
> On Mon, 16 Nov 2015 18:42:38 +0000
> Mark Brown <broonie@kernel.org> wrote:
>
> > On Mon, Nov 16, 2015 at 01:23:59PM +0100, Boris Brezillon wrote:
> > > Mark Brown <broonie@kernel.org> wrote:
> > > > On Mon, Nov 16, 2015 at 09:56:32AM +0100, Boris Brezillon wrote:
> >
> > > > > - pwm_reg_period = pwm_get_period(drvdata->pwm);
> > > > > + pwm_reg_period = pwm_get_default_period(drvdata->pwm);
> >
> > > > It's not clear to me that we're not looking for the current period here
> > > > or in the other use. Won't configuring based on a period other than the
> > > > one that has been set give the wrong answer?
> >
> > > Hm, maybe that's naming problem. What I call the 'default' period here
> > > is actually the period configured in your board file (using a PWM lookup
> > > table) or your DT. This value represent the period requested by the PWM
> > > user not a default value specified by the PWM chip driver.
> >
> > > The reason we're not using the 'current' period value is because it may
> > > have been set by the bootloader, and may be inappropriate for our use
> > > case (ie. the period may be to small to represent the different
> > > voltages).
> >
> > > ITOH, we're using the current period value when calculating the current
> > > voltage, because we want to get the correct voltage value, and the PWM
> > > device may still use the configuration set by the bootloader (not the
> > > default one specified in your board or DT files).
> >
> > > I hope this clarifies the differences between the current and default
> > > period, and why we should use the default value here.
> >
> > To be honest I'm still a bit confused here. When do we actually apply
> > the default setting and why do we keep on having to constantly override
> > it rather than doing this once at boot? It feels wrong to be using it
> > every time we set anything. I'd expect it to be something we only need
> > to do at probe time or which would automatically be handled by the PWM
> > framework (but that'd have issues changing the state and potentially
> > breaking things if done in an uncoordiated fashion).
>
> Thierry, I didn't hear from you after the long discussion we had on IRC
> a few weeks ago.
> The conclusion of this discussion was that using
> pwm_get_default_period() was not acceptable (even after renaming it
> differently, like pwm_get_reference_period()), because it was
> disturbing to get the default/reference period each time we wanted to
> configure the PWM differently.
> Another suggestion was to automatically reconfigure the PWM duty_ns
> value based on the initial PWM state (retrieved through hardware
> readout) and the default period value (specified in the PWM lookup table
> or the DT). But this implied supporting hardware readout in all PWM
> drivers, which prevents a smooth migration to this new approach.
>
> I also proposed to provide helpers to hide the duty cycle to active
> time calculation in the PWM core, so that PWM users just have to choose
> their scale (percent, or any other custom scale) and set their duty
> cycle based on this scale instead of specifying an active/on time in
> nanosecond. You didn't seem to like this idea, but I gave it a try
> (see here [1]), and think it might be worth looking at it.
>
> The commit you should look at are [2], [3] and [4], and the idea is to
> clarify the notion of duty-cycle, which, according to wikipedia [5]
> (and a lot of other references) is supposed to be expressed in a
> relative unit (percent, or any other scale as said earlier).
> After renaming the pwm_set/get_duty_cycle() helpers into
> pwm_set/get_active_time() we can define a new pwm_set_duty_cycle()
> helper to let the PWM user configure its PWM device relatively to a
> chosen scale, without asking him to choose the PWM period (the
> conversion is done based on the default/reference period).
> The pwm_get_duty_cycle() is doing the reverse conversion: it returns the
> duty-cycle expressed relatively to the scale (here the current PWM
> period is used to handle the case where the PWM user hasn't configure
> the PWM yet, but want to retrieve the current duty-cycle extracted from
> hardware readout).
>
> Please let me know what you think of this approach, and if you're happy
> with it I'll rework my series accordingly.
>
> Best Regards,
>
> Boris
>
> [1]https://github.com/bbrezillon/linux-rk/commits/atomic-pwm-alt
> [2]https://github.com/bbrezillon/linux-rk/commit/d7d4d04e147d4ec349c59f70e141877661930c6d
> [3]https://github.com/bbrezillon/linux-rk/commit/66ce78f308f3eb1a9c536689352f208fd51c9030
> [4]https://github.com/bbrezillon/linux-rk/commit/07882a2dd21f0d17d83640ff55204cc7a7d4c8f7
> [5]https://en.wikipedia.org/wiki/Duty_cycle
>
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko
From: Tomi Valkeinen @ 2015-12-30 10:32 UTC (permalink / raw)
To: Sebastian Frias
Cc: linux-fbdev, Måns Rullgård, mason, LKML, dri-devel,
laurent.pinchart, Frans Klaver, Jean-Christophe Plagniol-Villard
In-Reply-To: <5683A48C.80203@laposte.net>
[-- Attachment #1: Type: text/plain, Size: 2678 bytes --]
On 30/12/15 11:31, Sebastian Frias wrote:
> Hi,
>
> On 12/30/2015 09:06 AM, Tomi Valkeinen wrote:
>>
>> Also note that I don't want new fbdev drivers into the mainline kernel.
>> You should implement a DRM based driver instead.
>>
>
> Thanks, is there a porting guide to go from fbdev to DRM?
I don't think you should "port" the driver from fbdev to DRM, as the
frameworks are just so different. You should implement the driver from
scratch. Of course, the bits of code that actually touch the hardware
can possibly be copied directly.
Kernel docs contain documentation about DRM, but I don't know if there's
really a "how to write a DRM driver" style documentation. There's an
active mailing list and irc channel, though.
> Does DRM provides a "fbdev" backward compatible API? Would that be
> feasible?
DRM provides an fbdev "emulation". I think it's mainly aimed at
providing fb console, but many fbdev applications should work fine on
top of it.
> I did not find much about that.
>
> Currently our stack is something like:
>
> Qt -> eglfs -> Mali -> fbdev -> mem -> output
> (HW) (HW)
>
> We don't control the eglfs/Mali (GPU) part.
> From what I could see, Mali uses DRM with X11 which we do not need
> (note: I'm not a Mali expert and just took a quick look at the code so I
> may be wrong), which could be a problem.
I'm not familiar with Mali, so I have no idea.
> If "implement a DRM driver" is a lot of work, it would end up as a
> business decision and probably would not happen.
True. It's, of course, up to you. If the fbdev driver works fine for you
and provides all the features, and you're happy with it, and there's no
requirement to get the driver to the mainline Linux, there's not much
point in going for a DRM driver.
> Would you say there are good solid arguments to shake our current stack
> (other than for dusting it off)?
Fbdev is the legacy framework, hopefully deprecated at some point, and
DRM is the current display framework. So DRM has much more features, is
actively developed, has a community that may help you with your issues, etc.
From purely technical point of view, it depends on the hardware in
question. If the HW supports hardware overlays and multiple outputs, DRM
supports those fully, whereas fbdev does not.
I'm not that familiar with the 3D side, but I think that can be
implemented properly with DRM, whereas on fbdev supporting 3D is always
more or less a hack.
> By the way, does DRM improves 2D acceleration support over fbdev?
I don't know enough about 2D acceleration to answer that.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] devicetree/bindings: add reset-gpios and vcc-supply for panel-dpi
From: Geert Uytterhoeven @ 2015-12-30 10:29 UTC (permalink / raw)
To: Rob Herring
Cc: Uwe Kleine-König, Tomi Valkeinen,
Jean-Christophe Plagniol-Villard, Linux Fbdev development list,
linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Sascha Hauer,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20151229205458.GA31241@rob-hp-laptop>
On Tue, Dec 29, 2015 at 9:54 PM, Rob Herring <robh@kernel.org> wrote:
> On Sun, Dec 20, 2015 at 12:13:20PM +0100, Uwe Kleine-König wrote:
>> Some displays have a reset input and/or need a regulator to function
>> properly. Allow to specify them for panel-dpi devices.
>>
>> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>> ---
>> Documentation/devicetree/bindings/display/panel/panel-dpi.txt | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
>> index 216c894d4f99..b52ac52757df 100644
>> --- a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
>> +++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
>> @@ -7,6 +7,8 @@ Required properties:
>> Optional properties:
>> - label: a symbolic name for the panel
>> - enable-gpios: panel enable gpio
>> +- reset-gpios: GPIO to control the RESET pin
>
> The problem with this in a generic binding is what if the panel has
> ordering requirements like enable gpio has to be inactive when reset
> is deasserted?
>
>> +- vcc-supply: phandle of regulator that will be used to enable power to the display
>
> What if there are 2 supplies?
So it should be "vcc-supplies". Most properties containing phandles use plural
naming, even if Linux supports a single phandle only (e.g. "power-domains").
You also may want to add an optional "vcc-supply-names" property to
differentiate.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko
From: Sebastian Frias @ 2015-12-30 9:31 UTC (permalink / raw)
To: Tomi Valkeinen, laurent.pinchart, David Airlie
Cc: Frans Klaver, Jean-Christophe Plagniol-Villard, linux-fbdev, LKML,
mason, Måns Rullgård, dri-devel
In-Reply-To: <5683908C.5040001@ti.com>
Hi,
On 12/30/2015 09:06 AM, Tomi Valkeinen wrote:
>
> Also note that I don't want new fbdev drivers into the mainline kernel.
> You should implement a DRM based driver instead.
>
Thanks, is there a porting guide to go from fbdev to DRM?
Does DRM provides a "fbdev" backward compatible API? Would that be feasible?
I did not find much about that.
Currently our stack is something like:
Qt -> eglfs -> Mali -> fbdev -> mem -> output
(HW) (HW)
We don't control the eglfs/Mali (GPU) part.
From what I could see, Mali uses DRM with X11 which we do not need
(note: I'm not a Mali expert and just took a quick look at the code so I
may be wrong), which could be a problem.
If "implement a DRM driver" is a lot of work, it would end up as a
business decision and probably would not happen.
Would you say there are good solid arguments to shake our current stack
(other than for dusting it off)?
By the way, does DRM improves 2D acceleration support over fbdev?
Thanks,
Sebastian
^ permalink raw reply
* Re: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko
From: Tomi Valkeinen @ 2015-12-30 8:06 UTC (permalink / raw)
To: Sebastian Frias, Frans Klaver
Cc: Jean-Christophe Plagniol-Villard, linux-fbdev, LKML, mason,
Måns Rullgård
In-Reply-To: <5682BA0B.9060001@laposte.net>
[-- Attachment #1: Type: text/plain, Size: 977 bytes --]
Hi,
On 29/12/15 18:51, Sebastian Frias wrote:
> On 12/29/2015 03:16 PM, Frans Klaver wrote:
>> On Tue, Dec 29, 2015 at 3:06 PM, Sebastian Frias <sf84@laposte.net>
>> wrote:
>>> Right now we don't know if the driver will be upstreamed.
>>> Let me rephrase my question:
>>>
>>> - how would you recommend enabling FB_CFB_FILLRECT, FB_CFB_COPYAREA and
>>> FB_CFB_IMAGEBLIT for a driver that is not included in the kernel's tree?
>>>
>>> If that is not possible, I guess we will have to keep a forked tree
>>> until
>>> the driver is upstreamed, but we would like to avoid that, hence the
>>> question.
>>
>> I guess you'll have to keep on doing that indeed. I'm not aware of any
>> location where out-of-tree drivers are considered. You should try
>> again when you have some actual code to upstream.
>>
>
> Ok, thanks.
Also note that I don't want new fbdev drivers into the mainline kernel.
You should implement a DRM based driver instead.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] devicetree/bindings: add reset-gpios and vcc-supply for panel-dpi
From: Rob Herring @ 2015-12-29 20:54 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Tomi Valkeinen, Jean-Christophe Plagniol-Villard,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1450610002-10531-2-git-send-email-u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Sun, Dec 20, 2015 at 12:13:20PM +0100, Uwe Kleine-König wrote:
> Some displays have a reset input and/or need a regulator to function
> properly. Allow to specify them for panel-dpi devices.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Documentation/devicetree/bindings/display/panel/panel-dpi.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
> index 216c894d4f99..b52ac52757df 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
> +++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
> @@ -7,6 +7,8 @@ Required properties:
> Optional properties:
> - label: a symbolic name for the panel
> - enable-gpios: panel enable gpio
> +- reset-gpios: GPIO to control the RESET pin
The problem with this in a generic binding is what if the panel has
ordering requirements like enable gpio has to be inactive when reset
is deasserted?
> +- vcc-supply: phandle of regulator that will be used to enable power to the display
What if there are 2 supplies?
While there are limits to what can be described here, I'm okay with
allowing these, so:
Acked-by: Rob Herring <robh@kernel.org>
Rob
^ permalink raw reply
* Re: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko
From: Sebastian Frias @ 2015-12-29 16:51 UTC (permalink / raw)
To: Frans Klaver
Cc: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev,
LKML, mason, Måns Rullgård
In-Reply-To: <CAH6sp9OvJB+OPDPMWkEyNADcwO19N2=8U-5q49GrCmQTYObb_A@mail.gmail.com>
On 12/29/2015 03:16 PM, Frans Klaver wrote:
> On Tue, Dec 29, 2015 at 3:06 PM, Sebastian Frias <sf84@laposte.net> wrote:
>> Right now we don't know if the driver will be upstreamed.
>> Let me rephrase my question:
>>
>> - how would you recommend enabling FB_CFB_FILLRECT, FB_CFB_COPYAREA and
>> FB_CFB_IMAGEBLIT for a driver that is not included in the kernel's tree?
>>
>> If that is not possible, I guess we will have to keep a forked tree until
>> the driver is upstreamed, but we would like to avoid that, hence the
>> question.
>
> I guess you'll have to keep on doing that indeed. I'm not aware of any
> location where out-of-tree drivers are considered. You should try
> again when you have some actual code to upstream.
>
Ok, thanks.
^ permalink raw reply
* Re: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko
From: Frans Klaver @ 2015-12-29 14:16 UTC (permalink / raw)
To: Sebastian Frias
Cc: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev,
LKML, mason, Måns Rullgård
In-Reply-To: <5682936E.2040904@laposte.net>
On Tue, Dec 29, 2015 at 3:06 PM, Sebastian Frias <sf84@laposte.net> wrote:
> On 12/29/2015 02:49 PM, Frans Klaver wrote:
>>
>> On Tue, Dec 29, 2015 at 2:15 PM, Sebastian Frias <sf84@laposte.net> wrote:
>>>
>>> Hi,
>>>
>>> We are wondering what is the recommended way of adding support for a
>>> framebuffer driver on the Linux kernel.
>>> Below you can find a patch with a proposed solution.
>>
>>
>> That's not really a solution to add a driver to the kernel. You'd have
>> to include some actual driver code as well.
>
>
> We are not attempting to upstream the driver yet, that's why its code is not
> included.
>
> The patch is an attempt to allow the user to enable Framebuffer support by
> providing an option for the user and then setting FB_CFB_FILLRECT,
> FB_CFB_COPYAREA and FB_CFB_IMAGEBLIT to yes.
>
> It does the job, but we feel (and you have sort of confirmed it) that it may
> not be a good idea to do it that way.
>
>>
>>
>>> Our frambuffer driver source code is provided separately, but right now
>>> it
>>> requires "cfb_fillrect", "cfb_copyarea" and "cfb_imageblit" to be
>>> provided
>>> by the kernel.
>>>
>>> Our current kernel fork (based on 3.4) hardcodes FB_CFB_FILLRECT,
>>> FB_CFB_COPYAREA and FB_CFB_IMAGEBLIT to yes.
>>> Since we are in the process of migrating to 4.x and upstreaming changes
>>> along the way, we would like to know if the patch below is the way to go
>>> with it or if you have suggestions to improve it.
>>
>>
>> Is the below patch really a patch you intend to upstream, or are you
>> just wondering about what your Kconfig entry should look like when you
>> upstream your driver?
>
>
> Right now we don't know if the driver will be upstreamed.
> Let me rephrase my question:
>
> - how would you recommend enabling FB_CFB_FILLRECT, FB_CFB_COPYAREA and
> FB_CFB_IMAGEBLIT for a driver that is not included in the kernel's tree?
>
> If that is not possible, I guess we will have to keep a forked tree until
> the driver is upstreamed, but we would like to avoid that, hence the
> question.
I guess you'll have to keep on doing that indeed. I'm not aware of any
location where out-of-tree drivers are considered. You should try
again when you have some actual code to upstream.
Cheers,
Frans
^ permalink raw reply
* Re: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko
From: Sebastian Frias @ 2015-12-29 14:06 UTC (permalink / raw)
To: Frans Klaver
Cc: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev,
LKML, mason, Måns Rullgård
In-Reply-To: <CAH6sp9NrvapSMnPq5aagUFG2upf6-H9QJL1bkhMSscDL21Q-EQ@mail.gmail.com>
On 12/29/2015 02:49 PM, Frans Klaver wrote:
> On Tue, Dec 29, 2015 at 2:15 PM, Sebastian Frias <sf84@laposte.net> wrote:
>> Hi,
>>
>> We are wondering what is the recommended way of adding support for a
>> framebuffer driver on the Linux kernel.
>> Below you can find a patch with a proposed solution.
>
> That's not really a solution to add a driver to the kernel. You'd have
> to include some actual driver code as well.
We are not attempting to upstream the driver yet, that's why its code is
not included.
The patch is an attempt to allow the user to enable Framebuffer support
by providing an option for the user and then setting FB_CFB_FILLRECT,
FB_CFB_COPYAREA and FB_CFB_IMAGEBLIT to yes.
It does the job, but we feel (and you have sort of confirmed it) that it
may not be a good idea to do it that way.
>
>
>> Our frambuffer driver source code is provided separately, but right now it
>> requires "cfb_fillrect", "cfb_copyarea" and "cfb_imageblit" to be provided
>> by the kernel.
>>
>> Our current kernel fork (based on 3.4) hardcodes FB_CFB_FILLRECT,
>> FB_CFB_COPYAREA and FB_CFB_IMAGEBLIT to yes.
>> Since we are in the process of migrating to 4.x and upstreaming changes
>> along the way, we would like to know if the patch below is the way to go
>> with it or if you have suggestions to improve it.
>
> Is the below patch really a patch you intend to upstream, or are you
> just wondering about what your Kconfig entry should look like when you
> upstream your driver?
Right now we don't know if the driver will be upstreamed.
Let me rephrase my question:
- how would you recommend enabling FB_CFB_FILLRECT, FB_CFB_COPYAREA and
FB_CFB_IMAGEBLIT for a driver that is not included in the kernel's tree?
If that is not possible, I guess we will have to keep a forked tree
until the driver is upstreamed, but we would like to avoid that, hence
the question.
>
>
>> Subject: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko
>>
>> Signed-off-by: Sebastian Frias <sf84@laposte.net>
>> ---
>> drivers/video/fbdev/Kconfig | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
>> index e6d16d6..46c4ab2 100644
>> --- a/drivers/video/fbdev/Kconfig
>> +++ b/drivers/video/fbdev/Kconfig
>> @@ -615,6 +615,16 @@ config FB_BF537_LQ035
>> To compile this driver as a module, choose M here: the
>> module will be called bf537-lq035.
>>
>> +config FB_TANGO
>> + bool "Sigma Designs FrameBuffer support"
>> + depends on FB && ARCH_TANGO
>> + select FB_CFB_FILLRECT
>> + select FB_CFB_COPYAREA
>> + select FB_CFB_IMAGEBLIT
>> + help
>> + You need to enable this if you intend to use Sigma
>> + Designs' smp8xxxfb.ko driver.
>> +
>> config FB_BFIN_7393
>> tristate "Blackfin ADV7393 Video encoder"
>> depends on FB && BLACKFIN
>
> Frans
>
^ permalink raw reply
* Re: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko
From: Frans Klaver @ 2015-12-29 13:49 UTC (permalink / raw)
To: Sebastian Frias
Cc: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev,
LKML, mason, Måns Rullgård
In-Reply-To: <56828767.4050302@laposte.net>
On Tue, Dec 29, 2015 at 2:15 PM, Sebastian Frias <sf84@laposte.net> wrote:
> Hi,
>
> We are wondering what is the recommended way of adding support for a
> framebuffer driver on the Linux kernel.
> Below you can find a patch with a proposed solution.
That's not really a solution to add a driver to the kernel. You'd have
to include some actual driver code as well.
> Our frambuffer driver source code is provided separately, but right now it
> requires "cfb_fillrect", "cfb_copyarea" and "cfb_imageblit" to be provided
> by the kernel.
>
> Our current kernel fork (based on 3.4) hardcodes FB_CFB_FILLRECT,
> FB_CFB_COPYAREA and FB_CFB_IMAGEBLIT to yes.
> Since we are in the process of migrating to 4.x and upstreaming changes
> along the way, we would like to know if the patch below is the way to go
> with it or if you have suggestions to improve it.
Is the below patch really a patch you intend to upstream, or are you
just wondering about what your Kconfig entry should look like when you
upstream your driver?
> Subject: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko
>
> Signed-off-by: Sebastian Frias <sf84@laposte.net>
> ---
> drivers/video/fbdev/Kconfig | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index e6d16d6..46c4ab2 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -615,6 +615,16 @@ config FB_BF537_LQ035
> To compile this driver as a module, choose M here: the
> module will be called bf537-lq035.
>
> +config FB_TANGO
> + bool "Sigma Designs FrameBuffer support"
> + depends on FB && ARCH_TANGO
> + select FB_CFB_FILLRECT
> + select FB_CFB_COPYAREA
> + select FB_CFB_IMAGEBLIT
> + help
> + You need to enable this if you intend to use Sigma
> + Designs' smp8xxxfb.ko driver.
> +
> config FB_BFIN_7393
> tristate "Blackfin ADV7393 Video encoder"
> depends on FB && BLACKFIN
Frans
^ permalink raw reply
* [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko
From: Sebastian Frias @ 2015-12-29 13:15 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen
Cc: linux-fbdev, LKML, mason, Måns Rullgård
Hi,
We are wondering what is the recommended way of adding support for a
framebuffer driver on the Linux kernel.
Below you can find a patch with a proposed solution.
Our frambuffer driver source code is provided separately, but right now
it requires "cfb_fillrect", "cfb_copyarea" and "cfb_imageblit" to be
provided by the kernel.
Our current kernel fork (based on 3.4) hardcodes FB_CFB_FILLRECT,
FB_CFB_COPYAREA and FB_CFB_IMAGEBLIT to yes.
Since we are in the process of migrating to 4.x and upstreaming changes
along the way, we would like to know if the patch below is the way to go
with it or if you have suggestions to improve it.
Thanks in advance,
Sebastian
-- >8 --
Subject: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko
Signed-off-by: Sebastian Frias <sf84@laposte.net>
---
drivers/video/fbdev/Kconfig | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index e6d16d6..46c4ab2 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -615,6 +615,16 @@ config FB_BF537_LQ035
To compile this driver as a module, choose M here: the
module will be called bf537-lq035.
+config FB_TANGO
+ bool "Sigma Designs FrameBuffer support"
+ depends on FB && ARCH_TANGO
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ help
+ You need to enable this if you intend to use Sigma
+ Designs' smp8xxxfb.ko driver.
+
config FB_BFIN_7393
tristate "Blackfin ADV7393 Video encoder"
depends on FB && BLACKFIN
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 3/7] omapfb: fix error return code
From: Tomi Valkeinen @ 2015-12-29 9:06 UTC (permalink / raw)
To: Julia Lawall
Cc: kernel-janitors, Jean-Christophe Plagniol-Villard, linux-omap,
linux-fbdev, linux-kernel
In-Reply-To: <1451143726-28195-4-git-send-email-Julia.Lawall@lip6.fr>
[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]
On 26/12/15 17:28, Julia Lawall wrote:
> Return a negative error code on failure.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @@
> identifier ret; expression e1,e2;
> @@
> (
> if (\(ret < 0\|ret != 0\))
> { ... return ret; }
> |
> ret = 0
> )
> ... when != ret = e1
> when != &ret
> *if(...)
> {
> ... when != ret = e2
> when forall
> return ret;
> }
> // </smpl>
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
>
> ---
> drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c | 12 +++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c b/drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c
> index 677e254..fc4cfa9 100644
> --- a/drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c
> +++ b/drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c
> @@ -241,22 +241,28 @@ static int tpd_probe(struct platform_device *pdev)
>
> gpio = devm_gpiod_get_index_optional(&pdev->dev, NULL, 0,
> GPIOD_OUT_LOW);
> - if (IS_ERR(gpio))
> + if (IS_ERR(gpio)) {
> + r = PTR_ERR(gpio);
> goto err_gpio;
> + }
>
> ddata->ct_cp_hpd_gpio = gpio;
>
> gpio = devm_gpiod_get_index_optional(&pdev->dev, NULL, 1,
> GPIOD_OUT_LOW);
> - if (IS_ERR(gpio))
> + if (IS_ERR(gpio)) {
> + r = PTR_ERR(gpio);
> goto err_gpio;
> + }
>
> ddata->ls_oe_gpio = gpio;
>
> gpio = devm_gpiod_get_index(&pdev->dev, NULL, 2,
> GPIOD_IN);
> - if (IS_ERR(gpio))
> + if (IS_ERR(gpio)) {
> + r = PTR_ERR(gpio);
> goto err_gpio;
> + }
>
> ddata->hpd_gpio = gpio;
Thanks. Looks like recent changes to the driver break the error
handling. I'll just drop those patches from my for-next branch, and let
the author fix the patches.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2] ARM: OMAPFB: panel-sony-acx565akm: fix missing mutex unlocks
From: Tomi Valkeinen @ 2015-12-29 7:46 UTC (permalink / raw)
To: Ivaylo Dimitrov
Cc: plagnioj, pali.rohar, pavel, linux-omap, linux-fbdev,
linux-kernel, Ivaylo Dimitrov, Aaro Koskinen
In-Reply-To: <567D44B3.6090309@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 833 bytes --]
On 25/12/15 15:29, Ivaylo Dimitrov wrote:
>
> Hi Tomi,
>
> On 13.01.2014 12:20, Tomi Valkeinen wrote:
>> On 2014-01-11 11:39, Ivaylo Dimitrov wrote:
>>
>>> The patch does not apply cleanly on top of rc7, however I applied it by
>>> hand. So far it seems it fixes the issue brought by
>>> c37dd677988ca50bc8bc60ab5ab053720583c168, though I didn't test if
>>> mutex_lock/mutex_unlock are complementary in every code path (at least
>>> not explicitly, I guess maemo is doing it for us anyway :) ).
>>
>> Ok, thanks.
>>
>>> So, shall I send a patch incorporating your code changes, or you will do
>>> it?
>>
>> I can handle it.
>>
>> Tomi
>>
>>
>
> I still don't see those fixes in mainline, shall I send a patch?
Oh, I'm sorry, I must have forgotten about that. Please, send a new patch.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Assalam o Alaikum
From: Zahra Robert @ 2015-12-29 2:02 UTC (permalink / raw)
To: jakonyvtar
Cordial greeting message from Eva Zahra, I am seeking for your help,I will
be very glad if you do assist me to relocate a sum of (US$4 Million
Dollars)into your Bank account in your country for the benefit of both of
us i want to use this money for investment. I will give you more details
as you reply Yours Eva Zahra Robert
^ permalink raw reply
* Charity/Donation
From: Jeff Skoll @ 2015-12-29 1:16 UTC (permalink / raw)
To: linux-fbdev
Hi,
My name is Jeffrey Skoll, a philanthropist and the founder of one of the largest private foundations in the world. I believe strongly in ‘giving while living.’ I had one idea that never changed in my mind — that you should use your wealth to help people and I have decided to secretly give USD2.498 Million to a randomly selected individual. On receipt of this email, you should count yourself as the individual. Kindly get back to me at your earliest convenience, so I know your email address is valid.
Visit the web page to know more about me: http://www.theglobeandmail.com/news/national/meet-the-canadian-billionaire-whos-giving-it-all-away/article4209888/ or you can read an article of me on Wikipedia.
Regards,
Jeffrey Skoll.
^ permalink raw reply
* Charity Donation
From: Jeff Skoll @ 2015-12-29 0:30 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <auto-000005204373@mailadmin.uni-kassel.de>
Hi,
My name is Jeffrey Skoll, a philanthropist and the founder of one of the largest private foundations in the world. I believe strongly in ‘giving while living.’ I had one idea that never changed in my mind — that you should use your wealth to help people and I have decided to secretly give USD2.498 Million to a randomly selected individual. On receipt of this email, you should count yourself as the individual. Kindly get back to me at your earliest convenience, so I know your email address is valid.
Visit the web page to know more about me: http://www.theglobeandmail.com/news/national/meet-the-canadian-billionaire-whos-giving-it-all-away/article4209888/ or you can read an article of me on Wikipedia.
Regards,
Jeffrey Skoll.
^ permalink raw reply
* Charity Donation
From: Jeff Skoll @ 2015-12-28 21:10 UTC (permalink / raw)
To: linux-fbdev
Hi,
My name is Jeffrey Skoll, a philanthropist and the founder of one of the largest private foundations in the world. I believe strongly in ‘giving while living.’ I had one idea that never changed in my mind — that you should use your wealth to help people and I have decided to secretly give USD2.498 Million to a randomly selected individual. On receipt of this email, you should count yourself as the individual. Kindly get back to me at your earliest convenience, so I know your email address is valid.
Visit the web page to know more about me: http://www.theglobeandmail.com/news/national/meet-the-canadian-billionaire-whos-giving-it-all-away/article4209888/ or you can read an article of me on Wikipedia.
Regards,
Jeffrey Skoll.
^ permalink raw reply
* Out-of-date git repo in MAINTAINERS?
From: Jakub Wilk @ 2015-12-28 17:14 UTC (permalink / raw)
To: linux-fbdev
The MAINTAINERS file reads:
FRAMEBUFFER LAYER
...
T: git git://git.kernel.org/pub/scm/linux/kernel/git/plagnioj/linux-fbdev.git
But this repo hasn't seen any commits since 2013...
--
Jakub Wilk
^ permalink raw reply
* [PATCH] Documentation/fb: Fix typos
From: Jakub Wilk @ 2015-12-28 12:57 UTC (permalink / raw)
To: linux-fbdev
Signed-off-by: Jakub Wilk <jwilk@jwilk.net>
---
Documentation/fb/fbcon.txt | 2 +-
Documentation/fb/sh7760fb.txt | 2 +-
Documentation/fb/sm712fb.txt | 2 +-
Documentation/fb/sstfb.txt | 2 +-
Documentation/fb/udlfb.txt | 6 +++---
5 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/fb/fbcon.txt b/Documentation/fb/fbcon.txt
index 4a9739a..5bc41ca 100644
--- a/Documentation/fb/fbcon.txt
+++ b/Documentation/fb/fbcon.txt
@@ -144,7 +144,7 @@ C. Boot options
Support is compiled in your kernel.
NOTE: This is purely console rotation. Any other applications that
- use the framebuffer will remain at their 'normal'orientation.
+ use the framebuffer will remain at their 'normal' orientation.
Actually, the underlying fb driver is totally ignorant of console
rotation.
diff --git a/Documentation/fb/sh7760fb.txt b/Documentation/fb/sh7760fb.txt
index b994c3b..280c849 100644
--- a/Documentation/fb/sh7760fb.txt
+++ b/Documentation/fb/sh7760fb.txt
@@ -20,7 +20,7 @@ Caveats:
a) if you're using 15/16bit color modes at >= 640x480 px resolutions,
b) during PCMCIA (or any other slow bus) activity.
-* Rotation works only 90degress clockwise, and only if horizontal
+* Rotation works only 90 degrees clockwise, and only if horizontal
resolution is <= 320 pixels.
files: drivers/video/sh7760fb.c
diff --git a/Documentation/fb/sm712fb.txt b/Documentation/fb/sm712fb.txt
index c388442..438a2bf 100644
--- a/Documentation/fb/sm712fb.txt
+++ b/Documentation/fb/sm712fb.txt
@@ -27,5 +27,5 @@ Missing Features
========
(alias TODO list)
- * 2D acceleratrion
+ * 2D acceleration
* dual-head support
diff --git a/Documentation/fb/sstfb.txt b/Documentation/fb/sstfb.txt
index 13db107..8cd3547 100644
--- a/Documentation/fb/sstfb.txt
+++ b/Documentation/fb/sstfb.txt
@@ -116,7 +116,7 @@ Tools
These tools are mostly for debugging purposes, but you can
find some of these interesting :
- - con2fb , maps a tty to a fbramebuffer .
+ - con2fb , maps a tty to a framebuffer .
con2fb /dev/fb1 /dev/tty5
- sst_dbg_vgapass , changes vga passthrou. You have to recompile the
driver with SST_DEBUG and SST_DEBUG_IOCTL set to 1
diff --git a/Documentation/fb/udlfb.txt b/Documentation/fb/udlfb.txt
index 57d2f29..c985cb6 100644
--- a/Documentation/fb/udlfb.txt
+++ b/Documentation/fb/udlfb.txt
@@ -9,7 +9,7 @@ pairing that with a hardware framebuffer (16MB) on the other end of the
USB wire. That hardware framebuffer is able to drive the VGA, DVI, or HDMI
monitor with no CPU involvement until a pixel has to change.
-The CPU or other local resource does all the rendering; optinally compares the
+The CPU or other local resource does all the rendering; optionally compares the
result with a local shadow of the remote hardware framebuffer to identify
the minimal set of pixels that have changed; and compresses and sends those
pixels line-by-line via USB bulk transfers.
@@ -66,10 +66,10 @@ means that from a hardware and fbdev software perspective, everything is good.
At that point, a /dev/fb? interface will be present for user-mode applications
to open and begin writing to the framebuffer of the DisplayLink device using
standard fbdev calls. Note that if mmap() is used, by default the user mode
-application must send down damage notifcations to trigger repaints of the
+application must send down damage notifications to trigger repaints of the
changed regions. Alternatively, udlfb can be recompiled with experimental
defio support enabled, to support a page-fault based detection mechanism
-that can work without explicit notifcation.
+that can work without explicit notification.
The most common client of udlfb is xf86-video-displaylink or a modified
xf86-video-fbdev X server. These servers have no real DisplayLink specific
--
2.6.4
^ permalink raw reply related
* [PATCH 3/7] omapfb: fix error return code
From: Julia Lawall @ 2015-12-26 15:28 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: kernel-janitors, Jean-Christophe Plagniol-Villard, linux-omap,
linux-fbdev, linux-kernel
In-Reply-To: <1451143726-28195-1-git-send-email-Julia.Lawall@lip6.fr>
Return a negative error code on failure.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret = 0
)
... when != ret = e1
when != &ret
*if(...)
{
... when != ret = e2
when forall
return ret;
}
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c | 12 +++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c b/drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c
index 677e254..fc4cfa9 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c
@@ -241,22 +241,28 @@ static int tpd_probe(struct platform_device *pdev)
gpio = devm_gpiod_get_index_optional(&pdev->dev, NULL, 0,
GPIOD_OUT_LOW);
- if (IS_ERR(gpio))
+ if (IS_ERR(gpio)) {
+ r = PTR_ERR(gpio);
goto err_gpio;
+ }
ddata->ct_cp_hpd_gpio = gpio;
gpio = devm_gpiod_get_index_optional(&pdev->dev, NULL, 1,
GPIOD_OUT_LOW);
- if (IS_ERR(gpio))
+ if (IS_ERR(gpio)) {
+ r = PTR_ERR(gpio);
goto err_gpio;
+ }
ddata->ls_oe_gpio = gpio;
gpio = devm_gpiod_get_index(&pdev->dev, NULL, 2,
GPIOD_IN);
- if (IS_ERR(gpio))
+ if (IS_ERR(gpio)) {
+ r = PTR_ERR(gpio);
goto err_gpio;
+ }
ddata->hpd_gpio = gpio;
^ permalink raw reply related
* [PATCH 0/7] fix error return code
From: Julia Lawall @ 2015-12-26 15:28 UTC (permalink / raw)
To: linux-arm-kernel
The complate semantic patch that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@ok exists@
identifier f,ret,i;
expression e;
constant c;
@@
// identify a function that returns a negative return value at least once.
f(...) {
... when any
(
return -c@i;
|
ret = -c@i;
... when != ret = e
return ret;
|
if (ret < 0) { ... return ret; }
)
... when any
}
@r exists@
identifier ret,ok.f,fn;
expression e1,e2,e3,e4,e5,e6,x;
statement S,S1;
position p1,p2,p3;
@@
// identify a case where the return variable is set to a non-negative value
// and then returned in error-handling code
f(...) {
... when any
(
if@p1 (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret@p1 = 0
)
... when != \(ret = e1\|ret++\|ret--\|ret+á\|ret-á\)
when != &ret
when any
(
if (<+... ret = e5 ...+>) S1
|
if (<+... &ret ...+>) S1
|
if@p2(<+...x = fn(...)...+>)
{
... when != ret = e6
when forall
return@p3 ret;
}
|
break;
|
x = fn(...)
... when != \(ret = e4\|ret++\|ret--\|ret+ä\|ret-ä\)
when != &ret
(
if (<+... ret = e3 ...+>) S
|
if (<+... &ret ...+>) S
|
if@p2(<+...\(x != 0\|x < 0\|x = NULL\|IS_ERR(x)\)...+>)
{
... when != ret = e2
when forall
return@p3 ret;
}
)
)
... when any
}
@printer depends on r@
position p;
identifier ok.f,pr;
constant char [] c;
@@
f(...) { <...pr@p(...,c,...)...> }
@bad0 exists@
identifier r.ret,ok.f,g != {ERR_PTR,IS_ERR};
position p != printer.p;
@@
f(...) { ... when any
g@p(...,ret,...)
... when any
}
@bad depends on !bad0 exists@
position r.p1,r.p2;
statement S1,S2;
identifier r.ret;
expression e1;
@@
// ignore the above if there is some path where the variable is set to
// something else
(
if@p1 (\(ret < 0\|ret != 0\)) S1
|
ret@p1 = 0
)
... when any
\(ret = e1\|ret++\|ret--\|ret+á\|ret-á\|&ret\)
... when any
if@p2(...) S2
@bad1 depends on !bad0 && !bad exists@
position r.p2;
statement S2;
identifier r.ret;
expression e1;
constant c;
@@
ret = -c
... when != \(ret = e1\|ret++\|ret--\|ret+á\|ret-á\)
when != &ret
when any
if@p2(...) S2
@bad2 depends on !bad0 && !bad && !bad1 exists@
position r.p1,r.p2;
identifier r.ret;
expression e1;
statement S2;
constant c;
@@
// likewise ignore it if there has been an intervening return
ret@p1 = 0
... when != if (...) { ... ret = e1 ... return ret; }
when != if (...) { ... return -c; }
when any
if@p2(...) S2
@script:python depends on !bad0 && !bad && !bad1 && !bad2@
p1 << r.p1;
p2 << r.p2;
p3 << r.p3;
@@
cocci.print_main("",p1)
cocci.print_secs("",p2)
cocci.print_secs("",p3)
// </smpl>
---
drivers/block/rsxx/core.c | 1
drivers/block/umem.c | 5 +++-
drivers/cdrom/gdrom.c | 8 +++++-
drivers/net/ethernet/ti/cpsw.c | 8 +++++-
drivers/soc/ti/knav_qmss_queue.c | 1
drivers/soc/ti/wkup_m3_ipc.c | 1
drivers/usb/gadget/legacy/acm_ms.c | 4 ++-
drivers/usb/gadget/legacy/audio.c | 4 ++-
drivers/usb/gadget/legacy/cdc2.c | 4 ++-
drivers/usb/gadget/legacy/ether.c | 4 ++-
drivers/usb/gadget/legacy/hid.c | 4 ++-
drivers/usb/gadget/legacy/mass_storage.c | 4 ++-
drivers/usb/gadget/legacy/ncm.c | 4 ++-
drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c | 12 +++++++---
14 files changed, 49 insertions(+), 15 deletions(-)
^ permalink raw reply
* Re: [PATCH v2] ARM: OMAPFB: panel-sony-acx565akm: fix missing mutex unlocks
From: Ivaylo Dimitrov @ 2015-12-25 13:29 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: plagnioj, pali.rohar, pavel, linux-omap, linux-fbdev,
linux-kernel, Ivaylo Dimitrov, Aaro Koskinen
In-Reply-To: <52D3BE08.9040508@ti.com>
Hi Tomi,
On 13.01.2014 12:20, Tomi Valkeinen wrote:
> On 2014-01-11 11:39, Ivaylo Dimitrov wrote:
>
>> The patch does not apply cleanly on top of rc7, however I applied it by
>> hand. So far it seems it fixes the issue brought by
>> c37dd677988ca50bc8bc60ab5ab053720583c168, though I didn't test if
>> mutex_lock/mutex_unlock are complementary in every code path (at least
>> not explicitly, I guess maemo is doing it for us anyway :) ).
>
> Ok, thanks.
>
>> So, shall I send a patch incorporating your code changes, or you will do
>> it?
>
> I can handle it.
>
> Tomi
>
>
I still don't see those fixes in mainline, shall I send a patch?
Ivo
^ permalink raw reply
* Re: [PATCH 5/5] fbdev: omap2: panel-dpi: allow specification of a vcc regulator
From: Tomi Valkeinen @ 2015-12-23 8:32 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1449753107-11410-5-git-send-email-uwe@kleine-koenig.org>
[-- Attachment #1: Type: text/plain, Size: 1169 bytes --]
Hi,
On 19/12/15 22:41, Adam Ford wrote:
> Tomi,
>
> Do you have any thought on how to approach adding sleep/delay
> functions? I have a display that requires a small delay before and
> after the enable gpio toggle. I assume that some may require a delay
> after the regulator starts for it to be be ready. For now I have a
> temp hack that just inserts a blanket 300mS wait, but I'd rather have
> something mainstreamed in the device tree, but I don't want to walk
> over someone else's work either.
I don't think it makes sense to add explicit entries for these, as we'd
just end up with lots of entries in the DT files for "wait-before-vcc",
"wait-after-vcc", etc.
There was a patch series some time ago, trying to add generic power
up/down sequences defined in DT. I don't think that ever got merged, as
there wasn't a consensus on the DT side. I can't find the series right
now, as I don't remember the author or the subject...
I think that kind of generic sequence framework would make sense, and
getting it merged without the DT side should be easier. Then the drivers
could have built-in sequences for certain panels.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] backlight: adp8860: fix another uninitialized variable use
From: Jingoo Han @ 2015-12-22 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <565D6937.90503@analog.com>
On Tuesday, December 01, 2015 6:33 PM, Michael Hennerich wrote:
> On 11/30/2015 12:24 PM, Arnd Bergmann wrote:
> > A recent patch I did fixed two potential uses of uninitialized
> > variables in the adp8870 and adp8860 drivers. Unfortunately,
> > I missed another one:
> >
> > drivers/video/backlight/adp8860_bl.c: In function 'adp8860_bl_ambient_light_level_show':
> > drivers/video/backlight/adp8860_bl.c:570:11: warning: 'reg_val' may be used uninitialized in this
> function
> >
> > This does the same change as before in one additional function,
> > and also changes the check for the return value in a way that
> > avoids another false positive warning with a similar message.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Acked-by: Michael Hennerich <michael.hennerich@analog.com>
Acked-by: Jingoo Han <jingoohan1@gmail.com>
Best regards,
Jingoo Han
>
> > Fixes: 6be3a5a9cd91 ("backlight: adp88x0: Fix uninitialized variable use")
> > ---
> > Sorry for missing this third hunk the first time around.
> >
> > diff --git a/drivers/video/backlight/adp8860_bl.c b/drivers/video/backlight/adp8860_bl.c
> > index f0d4c0324580..510e559c060e 100644
> > --- a/drivers/video/backlight/adp8860_bl.c
> > +++ b/drivers/video/backlight/adp8860_bl.c
> > @@ -566,11 +566,13 @@ static ssize_t adp8860_bl_ambient_light_level_show(struct device *dev,
> >
> > mutex_lock(&data->lock);
> > error = adp8860_read(data->client, ADP8860_PH1LEVL, ®_val);
> > - ret_val = reg_val;
> > - error |= adp8860_read(data->client, ADP8860_PH1LEVH, ®_val);
> > + if (!error) {
> > + ret_val = reg_val;
> > + error = adp8860_read(data->client, ADP8860_PH1LEVH, ®_val);
> > + }
> > mutex_unlock(&data->lock);
> >
> > - if (error < 0)
> > + if (error)
> > return error;
> >
> > /* Return 13-bit conversion value for the first light sensor */
> >
>
>
> --
> Greetings,
> Michael
>
> --
> Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
> Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368;
> Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin,
> Margaret Seif
^ 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