* Re: [PATCH v2 1/4] mfd: add LM3533 lighting-power core driver
From: Samuel Ortiz @ 2012-05-11 13:32 UTC (permalink / raw)
To: Johan Hovold
Cc: Rob Landley, Richard Purdie, Jonathan Cameron, Greg Kroah-Hartman,
Florian Tobias Schandinat, Arnd Bergmann, Andrew Morton,
Mark Brown, linux-doc, linux-kernel, linux-iio, devel,
linux-fbdev
In-Reply-To: <20120510120742.GA29437@localhost>
Hi Johan,
On Thu, May 10, 2012 at 02:07:42PM +0200, Johan Hovold wrote:
> On Wed, May 09, 2012 at 04:42:18PM +0200, Samuel Ortiz wrote:
> > Hi Johan
> >
> > On Thu, May 03, 2012 at 12:26:36PM +0200, Johan Hovold wrote:
> > > Add support for National Semiconductor / TI LM3533 lighting power chips.
> > >
> > > This is the core driver which provides register access over I2C and
> > > registers the ambient-light-sensor, LED and backlight sub-drivers.
> > >
> > > Signed-off-by: Johan Hovold <jhovold@gmail.com>
> > > ---
> > >
> > > v2:
> > > - add sysfs-ABI documentation
> > > - merge i2c implementation with core
> > > - use regmap and kill custom debugfs interface
> > >
> > >
> > > .../ABI/testing/sysfs-bus-i2c-devices-lm3533 | 38 +
> > > drivers/mfd/Kconfig | 13 +
> > > drivers/mfd/Makefile | 1 +
> > > drivers/mfd/lm3533-core.c | 717 ++++++++++++++++++++
> > > drivers/mfd/lm3533-ctrlbank.c | 134 ++++
> > > include/linux/mfd/lm3533.h | 89 +++
> > > 6 files changed, 992 insertions(+), 0 deletions(-)
> > > create mode 100644 Documentation/ABI/testing/sysfs-bus-i2c-devices-lm3533
> > > create mode 100644 drivers/mfd/lm3533-core.c
> > > create mode 100644 drivers/mfd/lm3533-ctrlbank.c
> > > create mode 100644 include/linux/mfd/lm3533.h
> > Patch applied to my for-next branch, thanks.
>
> I've been travelling for a few days and didn't have time to submit a
> discussed change to move two attributes to the platform data before I
> left.
>
> Could you please apply the following two patches on top of this one?
All of your 4 pending patches have been applied, thanks.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* Re: ASoC: wm9712: Microphone doesn't work: Mux handling broken?
From: Christoph Fritz @ 2012-05-12 0:15 UTC (permalink / raw)
To: Mark Brown
Cc: alsa-devel, Hans J. Koch, Sascha Hauer, Liam Girdwood,
linux-fbdev
In-Reply-To: <20120508102947.GA8226@lovely.krouter>
> > Framebuffer driver mx3fb configured for a 800x600 display:
> >
> > soc-audio soc-audio: ASoC machine PhyCORE-ac97-audio should use snd_soc_register_card()
> > asoc: platform pcm constructor failed
> > asoc: can't create pcm HiFi :-12
> > asoc: failed to instantiate card PhyCORE-ac97-audio: -12
>
> When I do decrease from 800x600 to 800x594, wm9712 works.
>
> Any ideas?
It seems to be a dma problem and not directly related to wm9712.
But the not working microphone input still bothers me. I suppose this
is related to not beeing able to change some muxes:
$ amixer sset "Mic Select Source" 'Mic 2'
Simple mixer control 'Mic Select Source',0
Capabilities: enum
Items: 'Mic 1' 'Differential' 'Mic 2' 'Stereo'
Item0: 'Mic 1'
$ amixer sset "Differential Source" 'Line'
Simple mixer control 'Differential Source',0
Capabilities: enum
Items: 'Mic' 'Line'
Item0: 'Mic'
They refuse to change their Item0 because they are defined as
SND_SOC_DAPM_MUX without a correlating path->name so that
snd_soc_dapm_mux_update_power() (in sound/soc/soc-dapmc) doesn't
change anything.
It works in 2.6.33, but current kernel has different mux handling and
it seems that no one since cared that much about microphone support.
Mark, can you confirm this, purpose a fix or even come up with
a patch?
Thanks,
-- Christoph
^ permalink raw reply
* Re: ASoC: wm9712: Microphone doesn't work: Mux handling broken?
From: Mark Brown @ 2012-05-12 11:51 UTC (permalink / raw)
To: Christoph Fritz
Cc: alsa-devel, Hans J. Koch, Sascha Hauer, Liam Girdwood,
linux-fbdev
In-Reply-To: <20120512001556.GA26105@mars>
[-- Attachment #1: Type: text/plain, Size: 1187 bytes --]
On Sat, May 12, 2012 at 02:15:56AM +0200, Christoph Fritz wrote:
> They refuse to change their Item0 because they are defined as
> SND_SOC_DAPM_MUX without a correlating path->name so that
> snd_soc_dapm_mux_update_power() (in sound/soc/soc-dapmc) doesn't
> change anything.
A route into a mux without a path name (other than a supply) just isn't
meaningful and I'm surprised it ever worked.
> It works in 2.6.33, but current kernel has different mux handling and
> it seems that no one since cared that much about microphone support.
It's nothing to do with microphones really, it's more that AC'97 CODECs
are rarely used with modern kernels as the boards that use AC'97 are
mostly quite old and suffer performance issues with modern software
stacks so newer kernels haven't been getting much testing with them.
> Mark, can you confirm this, purpose a fix or even come up with
> a patch?
Just filling in the appropriate mux value in the relevant route should
do the trick. Looking at the code it looks like the widget isn't hooked
into the audio routing map at all so I'm a little surprised. I'm out of
the office at the minute and so can't readily set up a test system
myself.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* haalloo,
From: abi @ 2012-05-12 16:56 UTC (permalink / raw)
To: linux-fbdev
haalloo,
how are you doing,i hope you are fine,my name is miss abi okom i got your
contact and want us to be a good friend,
please try and write back to me so that i will give you my pictures and tell
you more about me,
^ permalink raw reply
* Re: ASoC: wm9712: Microphone doesn't work: Mux handling broken?
From: Christoph Fritz @ 2012-05-13 3:56 UTC (permalink / raw)
To: Mark Brown
Cc: alsa-devel, Hans J. Koch, Sascha Hauer, Liam Girdwood,
linux-fbdev
In-Reply-To: <20120512115130.GI1781@opensource.wolfsonmicro.com>
On Sat, May 12, 2012 at 12:51:31PM +0100, Mark Brown wrote:
> On Sat, May 12, 2012 at 02:15:56AM +0200, Christoph Fritz wrote:
>
> > They refuse to change their Item0 because they are defined as
> > SND_SOC_DAPM_MUX without a correlating path->name so that
> > snd_soc_dapm_mux_update_power() (in sound/soc/soc-dapmc) doesn't
> > change anything.
>
> A route into a mux without a path name (other than a supply) just isn't
> meaningful and I'm surprised it ever worked.
>
> > It works in 2.6.33, but current kernel has different mux handling and
> > it seems that no one since cared that much about microphone support.
>
> It's nothing to do with microphones really, it's more that AC'97 CODECs
> are rarely used with modern kernels as the boards that use AC'97 are
> mostly quite old and suffer performance issues with modern software
> stacks so newer kernels haven't been getting much testing with them.
>
> > Mark, can you confirm this, purpose a fix or even come up with
> > a patch?
>
> Just filling in the appropriate mux value in the relevant route should
> do the trick. Looking at the code it looks like the widget isn't hooked
> into the audio routing map at all so I'm a little surprised. I'm out of
> the office at the minute and so can't readily set up a test system
> myself.
Thanks Mark, I'm pretty interested in testing too :-)
-- Christoph
^ permalink raw reply
* Re: [PATCH] video/smscufx: fix line counting in fb_write
From: Florian Tobias Schandinat @ 2012-05-13 12:47 UTC (permalink / raw)
To: Alexander Holler; +Cc: linux-kernel, linux-fbdev
In-Reply-To: <4F92995B.6030805@ahsoftware.de>
Hi Alexander,
On 04/21/2012 11:26 AM, Alexander Holler wrote:
> Hello,
>
> as for the patch for udlfb, I forgot to mention that this is a candidate
> for all stable trees 3.2 and above.
>
> Btw., the address of the maintainer doesn't seem to be valid anymore.
it is better to cc me on patches to the framebuffer subsystem for such
cases. I don't have much free time so it's rare that I come around to
dig in the mailing list.
>
> Regards,
>
> Alexander
>
> Am 21.04.2012 00:11, schrieb Alexander Holler:
>> Line 0 and 1 were both written to line 0 (on the display) and all
>> subsequent
>> lines had an offset of -1. The result was that the last line on the
>> display
>> was never overwritten by writes to /dev/fbN.
>>
>> The origin of this bug seems to have been udlfb.
>>
>> Signed-off-by: Alexander Holler<holler@ahsoftware.de>
>
> Cc: stable@vger.kernel.org
Patch looks good to me but can be made simpler.
>
>> ---
>> drivers/video/smscufx.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/video/smscufx.c b/drivers/video/smscufx.c
>> index ccbfef5..1e1e2d2 100644
>> --- a/drivers/video/smscufx.c
>> +++ b/drivers/video/smscufx.c
>> @@ -904,7 +904,7 @@ static ssize_t ufx_ops_write(struct fb_info *info,
>> const char __user *buf,
>> result = fb_sys_write(info, buf, count, ppos);
>>
>> if (result> 0) {
>> - int start = max((int)(offset / info->fix.line_length) - 1, 0);
>> + int start = max((int)(offset / info->fix.line_length), 0);
the cast to int as well as the max is superfluous without the -1 as the
value can no longer be negative.
>> int lines = min((u32)((result / info->fix.line_length) + 1),
>> (u32)info->var.yres);
>>
>
Best regards,
Florian Tobias Schandinat
^ permalink raw reply
* Re: [PATCH] video/sis: Annotate SiS_DRAMType as __devinitconst
From: Florian Tobias Schandinat @ 2012-05-13 13:04 UTC (permalink / raw)
To: Peter Hüwe; +Cc: Thomas Winischhofer, linux-fbdev, linux-kernel
In-Reply-To: <201205102339.09295.PeterHuewe@gmx.de>
Hi Peter,
On 05/10/2012 09:39 PM, Peter Hüwe wrote:
> Am Donnerstag 10 Mai 2012, 02:19:18 schrieb Florian Tobias Schandinat:
>> Good that you did this one, it was more to be done than I expected. I
>> ignored the checkpatch errors as you didn't introduce them but maybe it
>> wouldn't be a bad idea to fix things up if you touch them. Applied.
>
> Oh sorry, usually I do checkpatch, but I missed it on this one somehow.
> If you want, I can do a checkpatch cleanup for the whole sis driver as
> compensation ;)
That's not necessary.
I just wanted to highlight that I prefer it if people fix the style
on-the-fly while working on things rather than sending me individual
patches for each line and not even fixing the complete line but only one
special aspect of it so that checkpatch complains about their style fixes.
btw. Special characters are allowed in sign-offs.
Best regards,
Florian Tobias Schandinat
^ permalink raw reply
* Re: [PULL for v3.5] SH Mobile LCDC overlay support
From: Florian Tobias Schandinat @ 2012-05-13 20:36 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <5022250.LOHRC1DPLO@avalon>
Hi Laurent,
On 04/24/2012 11:31 AM, Laurent Pinchart wrote:
> Hi Florian,
>
> Could you please pull the following patches that add overlay support for the
> SH Mobile LCDC ? They have been posted for review as part of a bigger series
> some time ago.
Well, besides that I dislike everyone inventing his/her own overlay API
and just not having time to propose something that fits everyone your
patch looks mostly okay. Two things:
"That's fine, but you need a Documentation/ABI entry for any new sysfs
file you create." [Greg K-H]
So as far as I understand Gregs statement and your code correct you
should add such thing.
I'm not convinced that you don't leak resources. Is the memory you
allocate with dma_alloc_coherent for the overlays really freed after
normal use and in error paths?
Best regards,
Florian Tobias Schandinat
>
> The following changes since commit d313a86d2efb2c5568832389663322e93e291c59:
>
> i.MX28: Shut down the LCD controller to avoid BootROM sampling bug
> (2012-04-21 21:53:12 +0000)
>
> are available in the git repository at:
> git://linuxtv.org/pinchartl/fbdev.git planes
>
> Laurent Pinchart (3):
> fbdev: sh_mobile_lcdc: Constify sh_mobile_lcdc_fix structure
> fbdev: sh_mobile_lcdc: Rename fb operation handlers with a common prefix
> fbdev: sh_mobile_lcdc: Implement overlays support
>
> drivers/video/sh_mobile_lcdcfb.c | 1004 +++++++++++++++++++++++++++++++++----
> include/video/sh_mobile_lcdc.h | 7 +
> 2 files changed, 915 insertions(+), 96 deletions(-)
>
^ permalink raw reply
* Re: [PATCH] drivers/video/intelfb/intelfbdrv.c: add missing agp_backend_release
From: Florian Tobias Schandinat @ 2012-05-13 20:50 UTC (permalink / raw)
To: Julia Lawall; +Cc: Maik Broemme, kernel-janitors, linux-fbdev, linux-kernel
In-Reply-To: <1334854553-30067-1-git-send-email-Julia.Lawall@lip6.fr>
On 04/19/2012 04:55 PM, Julia Lawall wrote:
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> Release bridge, as done on all other paths out of the function.
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Looks good to me, applied.
Thanks,
Florian Tobias Schandinat
>
> ---
> drivers/video/intelfb/intelfbdrv.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/video/intelfb/intelfbdrv.c b/drivers/video/intelfb/intelfbdrv.c
> index 02fd226..bdcbfba 100644
> --- a/drivers/video/intelfb/intelfbdrv.c
> +++ b/drivers/video/intelfb/intelfbdrv.c
> @@ -680,6 +680,7 @@ static int __devinit intelfb_pci_register(struct pci_dev *pdev,
> + dinfo->fb.size);
> if (!dinfo->aperture.virtual) {
> ERR_MSG("Cannot remap FB region.\n");
> + agp_backend_release(bridge);
> cleanup(dinfo);
> return -ENODEV;
> }
> @@ -689,6 +690,7 @@ static int __devinit intelfb_pci_register(struct pci_dev *pdev,
> INTEL_REG_SIZE);
> if (!dinfo->mmio_base) {
> ERR_MSG("Cannot remap MMIO region.\n");
> + agp_backend_release(bridge);
> cleanup(dinfo);
> return -ENODEV;
> }
>
>
^ permalink raw reply
* Re: [PATCH v2] video: exynos_dp: remove unnecessary header includes
From: Florian Tobias Schandinat @ 2012-05-13 20:51 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <004d01cd29be$b79eb8d0$26dc2a70$%han@samsung.com>
On 05/04/2012 06:25 AM, Jingoo Han wrote:
> Remove unnecessary headers from the file.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/exynos/exynos_dp_core.c | 2 --
> drivers/video/exynos/exynos_dp_reg.c | 2 --
> 2 files changed, 0 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
> index 6e9f3ce..ef4d1ab 100644
> --- a/drivers/video/exynos/exynos_dp_core.c
> +++ b/drivers/video/exynos/exynos_dp_core.c
> @@ -21,8 +21,6 @@
>
> #include <video/exynos_dp.h>
>
> -#include <plat/cpu.h>
> -
> #include "exynos_dp_core.h"
>
> static int exynos_dp_init_dp(struct exynos_dp_device *dp)
> diff --git a/drivers/video/exynos/exynos_dp_reg.c b/drivers/video/exynos/exynos_dp_reg.c
> index 3863726..99bafb8 100644
> --- a/drivers/video/exynos/exynos_dp_reg.c
> +++ b/drivers/video/exynos/exynos_dp_reg.c
> @@ -16,8 +16,6 @@
>
> #include <video/exynos_dp.h>
>
> -#include <plat/cpu.h>
> -
> #include "exynos_dp_core.h"
> #include "exynos_dp_reg.h"
>
^ permalink raw reply
* Re: [PATCH] video: s3c-fb: use pr_debug instead of printk
From: Florian Tobias Schandinat @ 2012-05-13 20:51 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <003701cd2be7$298eda40$7cac8ec0$%han@samsung.com>
On 05/07/2012 12:20 AM, Jingoo Han wrote:
> This patch uses pr_debug instead of printk to allow dynamic debugging.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/s3c-fb.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index ecb82bb..038546a 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -47,7 +47,7 @@
> #ifdef CONFIG_FB_S3C_DEBUG_REGWRITE
> #undef writel
> #define writel(v, r) do { \
> - printk(KERN_DEBUG "%s: %08x => %p\n", __func__, (unsigned int)v, r); \
> + pr_debug("%s: %08x => %p\n", __func__, (unsigned int)v, r); \
> __raw_writel(v, r); \
> } while (0)
> #endif /* FB_S3C_DEBUG_REGWRITE */
^ permalink raw reply
* Re: [PATCH] video: EXYNOS: changes mipi dsi regulator name from vdd10 to vdd11
From: Florian Tobias Schandinat @ 2012-05-13 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4FA71563.5050401@samsung.com>
On 05/07/2012 12:20 AM, Donghwa Lee wrote:
> MIPI DSI uses 1.1v regulator, so change its supply name.
>
> Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
> Signed-off-by: Inki Dae <inki.dae@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/exynos/exynos_mipi_dsi.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c
> index 95e33f0..2e779d3 100644
> --- a/drivers/video/exynos/exynos_mipi_dsi.c
> +++ b/drivers/video/exynos/exynos_mipi_dsi.c
> @@ -58,7 +58,7 @@ static struct mipi_dsim_platform_data *to_dsim_plat(struct platform_device
> }
>
> static struct regulator_bulk_data supplies[] = {
> - { .supply = "vdd10", },
> + { .supply = "vdd11", },
> { .supply = "vdd18", },
> };
>
^ permalink raw reply
* Re: [PATCH 0/4] fbdev: sh_mobile_hdmi: adds HDMI control register support
From: Florian Tobias Schandinat @ 2012-05-13 20:56 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <87lil3mi69.wl%kuninori.morimoto.gx@renesas.com>
Hi Morimoto-san,
On 05/08/2012 04:05 AM, Kuninori Morimoto wrote:
>
> Hi Florian
> Cc: Magnus, Guennadi, Simon
>
> These are sh_mobile_hdmi update patches to supporting
> HDMI control register on latest SuperH chip
>
> Kuninori Morimoto (4):
> fbdev: sh_mobile_hdmi: add hdmi_bit_set() function
> fbdev: sh_mobile_hdmi: add interrupt output option
> fbdev: sh_mobile_hdmi: 32bit register access support
> fbdev: sh_mobile_hdmi: add HDMI Control Register support
I applied these patches.
Thanks,
Florian Tobias Schandinat
>
> These patches add 32bit access support, and init control registers.
> These are tested on Armadillo800eva board
>
> Best regards
> ---
> Kuninori Morimoto
>
^ permalink raw reply
* Re: [PATCH 0/5] video: exynos mipi dsi: fixes some bugs and clean the codes
From: Florian Tobias Schandinat @ 2012-05-13 20:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4FAA0578.3060509@samsung.com>
On 05/09/2012 05:49 AM, Donghwa Lee wrote:
> These patches fix some bugs and clean the codes for exynos mipi dsi
> display driver.
>
> video: exynos mipi dsi: enable interrupt again after sw reset
> :I resend this patch by including this series.
> You can refer the original patch by below url.
> http://marc.info/?l=linux-fbdev&m\x133610770329570&w=2
> video: exynos mipi dsi: Do not use deprecated suspend/resume callbacks
> video: exynos mipi dsi: Avoid races in probe()
> video: exynos mipi dsi: Properly interpret the interrupt source flags
> video: exynos mipi dsi: support reverse panel type
I applied this series (2-5 as I applied the original of 1 earlier).
Thanks,
Florian Tobias Schandinat
>
> Thank you,
> Donghwa Lee
>
^ permalink raw reply
* Re: [PATCH] drivers/video: fsl-diu-fb: don't initialize the THRESHOLDS registers
From: Florian Tobias Schandinat @ 2012-05-13 21:00 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1336687048-16519-1-git-send-email-timur@freescale.com>
On 05/10/2012 09:57 PM, Timur Tabi wrote:
> The THRESHOLDS register configures thresholds for two interrupts, but
> these interrupts are not used in the DIU driver. An early version of the
> driver may have used the "lines before vsync" interrupt, which requires
> the LS_BF_VS of THRESHOLDS to be initialized.
>
> Unfortunately, the initialization of this register does not do a
> read-modify-write to set only LS_BF_VS. On the MPC8610, the value
> written is correct. On other chips, like the P1022, the value overwrites
> some reserved bits. This results in a performance drop on the P1022.
>
> Since the default value is acceptable as-is on all SOCs, we should just
> avoid touching this register.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/fsl-diu-fb.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
> index 6af3f16..458c006 100644
> --- a/drivers/video/fsl-diu-fb.c
> +++ b/drivers/video/fsl-diu-fb.c
> @@ -834,7 +834,6 @@ static void update_lcdc(struct fb_info *info)
> diu_ops.set_pixel_clock(var->pixclock);
>
> out_be32(&hw->syn_pol, 0); /* SYNC SIGNALS POLARITY */
> - out_be32(&hw->thresholds, 0x00037800); /* The Thresholds */
> out_be32(&hw->int_status, 0); /* INTERRUPT STATUS */
> out_be32(&hw->plut, 0x01F5F666);
>
^ permalink raw reply
* [PATCH] mbxfb: unbreak compilation with CONFIG_FB_MBX_DEBUG
From: tartler @ 2012-05-14 16:31 UTC (permalink / raw)
To: Florian Tobias Schandinat, Eric Miao, Arnd Bergmann, linux-fbdev,
linux-kernel
Cc: vamos-dev, Reinhard Tartler, Reinhard Tartler
From: Reinhard Tartler <siretart@tauware.de>
This patch adds missing function prototypes.
Signed-off-by: Reinhard Tartler <tartler@cs.fau.de>
---
drivers/video/mbx/mbxfb.c | 3 +++
1 file changed, 3 insertions(+)
This patch was found with tools developed in the VAMOS project:
http://www4.cs.fau.de/Research/VAMOS/
TBH, I'm not sure if this is the correct solution. However, I'd
appreciate if someone could confirm that this is a real bug.
diff --git a/drivers/video/mbx/mbxfb.c b/drivers/video/mbx/mbxfb.c
index 6ce3416..c2200ec 100644
--- a/drivers/video/mbx/mbxfb.c
+++ b/drivers/video/mbx/mbxfb.c
@@ -878,6 +878,9 @@ static int mbxfb_resume(struct platform_device *dev)
#ifndef CONFIG_FB_MBX_DEBUG
#define mbxfb_debugfs_init(x) do {} while(0)
#define mbxfb_debugfs_remove(x) do {} while(0)
+#else
+void mbxfb_debugfs_init(struct fb_info *fbi);
+void mbxfb_debugfs_remove(struct fb_info *fbi);
#endif
#define res_size(_r) (((_r)->end - (_r)->start) + 1)
--
1.7.9.5
^ permalink raw reply related
* [patch] fb: handle NULL pointers in framebuffer release
From: Dan Carpenter @ 2012-05-14 20:58 UTC (permalink / raw)
To: linux-fbdev
This function is called with a potential NULL pointer in
picolcd_init_framebuffer() and it causes a static checker warning. This
used to handle NULL pointers when the picolcd code was written, but a
couple months later we added the "info->apertures" dereference.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/video/fbsysfs.c b/drivers/video/fbsysfs.c
index 67afa9c..a55e366 100644
--- a/drivers/video/fbsysfs.c
+++ b/drivers/video/fbsysfs.c
@@ -80,6 +80,8 @@ EXPORT_SYMBOL(framebuffer_alloc);
*/
void framebuffer_release(struct fb_info *info)
{
+ if (!info)
+ return;
kfree(info->apertures);
kfree(info);
}
^ permalink raw reply related
* Re: [patch] fb: handle NULL pointers in framebuffer release
From: Marcin Slusarz @ 2012-05-14 21:29 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20120514205837.GE20836@elgon.mountain>
On Mon, May 14, 2012 at 11:58:37PM +0300, Dan Carpenter wrote:
> This function is called with a potential NULL pointer in
> picolcd_init_framebuffer() and it causes a static checker warning. This
> used to handle NULL pointers when the picolcd code was written, but a
> couple months later we added the "info->apertures" dereference.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Marcin Slusarz <marcin.slusarz@gmail.com>
> diff --git a/drivers/video/fbsysfs.c b/drivers/video/fbsysfs.c
> index 67afa9c..a55e366 100644
> --- a/drivers/video/fbsysfs.c
> +++ b/drivers/video/fbsysfs.c
> @@ -80,6 +80,8 @@ EXPORT_SYMBOL(framebuffer_alloc);
> */
> void framebuffer_release(struct fb_info *info)
> {
> + if (!info)
> + return;
> kfree(info->apertures);
> kfree(info);
> }
^ permalink raw reply
* [PATCH] OMAPDSS: DSI: Support command mode interleaving during video mode blanking periods
From: Archit Taneja @ 2012-05-15 6:14 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-fbdev, linux-omap, Archit Taneja
DSI supports interleaving of command mode packets during the HSA, HFP, HBP and
BLLP blanking intervals in a video mode stream. This is useful as a user may
want to read or change the configuration of a panel without stopping the video
stream.
On OMAP DSI, we can queue HS or LP command mode packets in the TX FIFO, and
the DSI HW takes care of interleaving this data during the one of the blanking
intervals. The DSI HW needs to be programmed with the maximum amount of data
that can be interleaved in a particular blanking period. A blanking period
cannot be used to send command mode data for it's complete duration, there is
some amount of time required for the DSI data and clock lanes to transition
to the desired LP or HS state.
Based on the state of the lanes at the beginning and end of the blanking period,
we have different scenarios, with each scenario having a different value of time
required to transition to HS or LP. Refer to the section 'Interleaving Mode' in
OMAP TRM for more info on the scenarios and the equations to calculate the time
required for HS or LP transitions.
We use the scenarios which takes the maximum time for HS or LP transition, this
gives us the minimum amount of time that can be used to interleave command mode
data. The amount of data that can be sent during this minimum time is calculated
for command mode packets both in LP and HS. These are written to the registers
DSI_VM_TIMING4 to DSI_VM_TIMING6.
The calculations don't take into account the time required of transmitting BTA
when doing a DSI read, or verifying if a DSI write went through correctly. Until
these latencies aren't considered, the behaviour of DSI is unpredictable when
a BTA is interleaved during a blanking period. Enhancement of these calculations
is a TODO item.
The calculations are derived from DSI parameter calculation tools written by
Sebastien Fagard <s-fagard@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
Note:
- Tested on Blaze tablet and OMAP5 SEVM
- Reference tree with testing intelrevaing of commands on blaze tablet:
git@gitorious.org:~boddob/linux-omap-dss2/archit-dss2-clone.git dsi_interleave
drivers/video/omap2/dss/dsi.c | 181 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 181 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 95bc996..53228c9 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -3763,6 +3763,186 @@ static void dsi_config_blanking_modes(struct omap_dss_device *dssdev)
dsi_write_reg(dsidev, DSI_CTRL, r);
}
+/*
+ * According to section 'HS Command Mode Interleaving' in OMAP TRM, Scenario 3
+ * results in maximum transition time for data and clock lanes to enter and
+ * exit HS mode. Hence, this is the scenario where the least amount of command
+ * mode data can be interleaved. We program the minimum amount of TXBYTECLKHS
+ * clock cycles that can be used to interleave command mode data in HS so that
+ * all scenarios are satisfied.
+ */
+static int dsi_compute_interleave_hs(int blank, bool ddr_alwon, int enter_hs,
+ int exit_hs, int exiths_clk, int ddr_pre, int ddr_post)
+{
+ int transition;
+
+ /*
+ * If DDR_CLK_ALWAYS_ON is set, we need to consider HS mode transition
+ * time of data lanes only, if it isn't set, we need to consider HS
+ * transition time of both data and clock lanes. HS transition time
+ * of Scenario 3 is considered.
+ */
+ if (ddr_alwon) {
+ transition = enter_hs + exit_hs + max(enter_hs, 2) + 1;
+ } else {
+ int trans1, trans2;
+ trans1 = ddr_pre + enter_hs + exit_hs + max(enter_hs, 2) + 1;
+ trans2 = ddr_pre + enter_hs + exiths_clk + ddr_post + ddr_pre +
+ enter_hs + 1;
+ transition = max(trans1, trans2);
+ }
+
+ return blank > transition ? blank - transition : 0;
+}
+
+/*
+ * According to section 'LP Command Mode Interleaving' in OMAP TRM, Scenario 1
+ * results in maximum transition time for data lanes to enter and exit LP mode.
+ * Hence, this is the scenario where the least amount of command mode data can
+ * be interleaved. We program the minimum amount of bytes that can be
+ * interleaved in LP so that all scenarios are satisfied.
+ */
+static int dsi_compute_interleave_lp(int blank, int enter_hs, int exit_hs,
+ int lp_clk_div, int tdsi_fclk)
+{
+ int trans_lp; /* time required for a LP transition, in TXBYTECLKHS */
+ int tlp_avail; /* time left for interleaving commands, in CLKIN4DDR */
+ int ttxclkesc; /* period of LP transmit escape clock, in CLKIN4DDR */
+ int thsbyte_clk = 16; /* Period of TXBYTECLKHS clock, in CLKIN4DDR */
+ int lp_inter; /* cmd mode data that can be interleaved, in bytes */
+
+ /* maximum LP transition time according to Scenario 1 */
+ trans_lp = exit_hs + max(enter_hs, 2) + 1;
+
+ /* CLKIN4DDR = 16 * TXBYTECLKHS */
+ tlp_avail = thsbyte_clk * (blank - trans_lp);
+
+ ttxclkesc = tdsi_fclk / lp_clk_div;
+
+ lp_inter = ((tlp_avail - 8 * thsbyte_clk - 5 * tdsi_fclk) / ttxclkesc -
+ 26) / 16;
+
+ return max(lp_inter, 0);
+}
+
+static void dsi_config_cmd_mode_interleaving(struct omap_dss_device *dssdev)
+{
+ struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
+ struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+ int blanking_mode;
+ int hfp_blanking_mode, hbp_blanking_mode, hsa_blanking_mode;
+ int hsa, hfp, hbp, width_bytes, bllp, lp_clk_div;
+ int ddr_clk_pre, ddr_clk_post, enter_hs_mode_lat, exit_hs_mode_lat;
+ int tclk_trail, ths_exit, exiths_clk;
+ bool ddr_alwon;
+ struct omap_video_timings *timings = &dssdev->panel.timings;
+ int bpp = dsi_get_pixel_size(dssdev->panel.dsi_pix_fmt);
+ int ndl = dsi->num_lanes_used - 1;
+ int dsi_fclk_hsdiv = dssdev->clocks.dsi.regm_dsi + 1;
+ int hsa_interleave_hs = 0, hsa_interleave_lp = 0;
+ int hfp_interleave_hs = 0, hfp_interleave_lp = 0;
+ int hbp_interleave_hs = 0, hbp_interleave_lp = 0;
+ int bl_interleave_hs = 0, bl_interleave_lp = 0;
+ u32 r;
+
+ r = dsi_read_reg(dsidev, DSI_CTRL);
+ blanking_mode = FLD_GET(r, 20, 20);
+ hfp_blanking_mode = FLD_GET(r, 21, 21);
+ hbp_blanking_mode = FLD_GET(r, 22, 22);
+ hsa_blanking_mode = FLD_GET(r, 23, 23);
+
+ r = dsi_read_reg(dsidev, DSI_VM_TIMING1);
+ hbp = FLD_GET(r, 11, 0);
+ hfp = FLD_GET(r, 23, 12);
+ hsa = FLD_GET(r, 31, 24);
+
+ r = dsi_read_reg(dsidev, DSI_CLK_TIMING);
+ ddr_clk_post = FLD_GET(r, 7, 0);
+ ddr_clk_pre = FLD_GET(r, 15, 8);
+
+ r = dsi_read_reg(dsidev, DSI_VM_TIMING7);
+ exit_hs_mode_lat = FLD_GET(r, 15, 0);
+ enter_hs_mode_lat = FLD_GET(r, 31, 16);
+
+ r = dsi_read_reg(dsidev, DSI_CLK_CTRL);
+ lp_clk_div = FLD_GET(r, 12, 0);
+ ddr_alwon = FLD_GET(r, 13, 13);
+
+ r = dsi_read_reg(dsidev, DSI_DSIPHY_CFG0);
+ ths_exit = FLD_GET(r, 7, 0);
+
+ r = dsi_read_reg(dsidev, DSI_DSIPHY_CFG1);
+ tclk_trail = FLD_GET(r, 15, 8);
+
+ exiths_clk = ths_exit + tclk_trail;
+
+ width_bytes = DIV_ROUND_UP(timings->x_res * bpp, 8);
+ bllp = hbp + hfp + hsa + DIV_ROUND_UP(width_bytes + 6, ndl);
+
+ if (!hsa_blanking_mode) {
+ hsa_interleave_hs = dsi_compute_interleave_hs(hsa, ddr_alwon,
+ enter_hs_mode_lat, exit_hs_mode_lat,
+ exiths_clk, ddr_clk_pre, ddr_clk_post);
+ hsa_interleave_lp = dsi_compute_interleave_lp(hsa,
+ enter_hs_mode_lat, exit_hs_mode_lat,
+ lp_clk_div, dsi_fclk_hsdiv);
+ }
+
+ if (!hfp_blanking_mode) {
+ hfp_interleave_hs = dsi_compute_interleave_hs(hfp, ddr_alwon,
+ enter_hs_mode_lat, exit_hs_mode_lat,
+ exiths_clk, ddr_clk_pre, ddr_clk_post);
+ hfp_interleave_lp = dsi_compute_interleave_lp(hfp,
+ enter_hs_mode_lat, exit_hs_mode_lat,
+ lp_clk_div, dsi_fclk_hsdiv);
+ }
+
+ if (!hbp_blanking_mode) {
+ hbp_interleave_hs = dsi_compute_interleave_hs(hbp, ddr_alwon,
+ enter_hs_mode_lat, exit_hs_mode_lat,
+ exiths_clk, ddr_clk_pre, ddr_clk_post);
+
+ hbp_interleave_lp = dsi_compute_interleave_lp(hbp,
+ enter_hs_mode_lat, exit_hs_mode_lat,
+ lp_clk_div, dsi_fclk_hsdiv);
+ }
+
+ if (!blanking_mode) {
+ bl_interleave_hs = dsi_compute_interleave_hs(bllp, ddr_alwon,
+ enter_hs_mode_lat, exit_hs_mode_lat,
+ exiths_clk, ddr_clk_pre, ddr_clk_post);
+
+ bl_interleave_lp = dsi_compute_interleave_lp(bllp,
+ enter_hs_mode_lat, exit_hs_mode_lat,
+ lp_clk_div, dsi_fclk_hsdiv);
+ }
+
+ DSSDBG("DSI HS interleaving(TXBYTECLKHS) HSA %d, HFP %d, HBP %d, BLLP %d\n",
+ hsa_interleave_hs, hfp_interleave_hs, hbp_interleave_hs,
+ bl_interleave_hs);
+
+ DSSDBG("DSI LP interleaving(bytes) HSA %d, HFP %d, HBP %d, BLLP %d\n",
+ hsa_interleave_lp, hfp_interleave_lp, hbp_interleave_lp,
+ bl_interleave_lp);
+
+ r = dsi_read_reg(dsidev, DSI_VM_TIMING4);
+ r = FLD_MOD(r, hsa_interleave_hs, 23, 16);
+ r = FLD_MOD(r, hfp_interleave_hs, 15, 8);
+ r = FLD_MOD(r, hbp_interleave_hs, 7, 0);
+ dsi_write_reg(dsidev, DSI_VM_TIMING4, r);
+
+ r = dsi_read_reg(dsidev, DSI_VM_TIMING5);
+ r = FLD_MOD(r, hsa_interleave_lp, 23, 16);
+ r = FLD_MOD(r, hfp_interleave_lp, 15, 8);
+ r = FLD_MOD(r, hbp_interleave_lp, 7, 0);
+ dsi_write_reg(dsidev, DSI_VM_TIMING5, r);
+
+ r = dsi_read_reg(dsidev, DSI_VM_TIMING6);
+ r = FLD_MOD(r, bl_interleave_hs, 31, 15);
+ r = FLD_MOD(r, bl_interleave_lp, 16, 0);
+ dsi_write_reg(dsidev, DSI_VM_TIMING6, r);
+}
+
static int dsi_proto_config(struct omap_dss_device *dssdev)
{
struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
@@ -3821,6 +4001,7 @@ static int dsi_proto_config(struct omap_dss_device *dssdev)
if (dssdev->panel.dsi_mode = OMAP_DSS_DSI_VIDEO_MODE) {
dsi_config_vp_sync_events(dssdev);
dsi_config_blanking_modes(dssdev);
+ dsi_config_cmd_mode_interleaving(dssdev);
}
dsi_vc_initial_config(dsidev, 0);
--
1.7.5.4
^ permalink raw reply related
* Re: [patch] fb: handle NULL pointers in framebuffer release
From: Hein Tibosch @ 2012-05-15 7:20 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20120514205837.GE20836@elgon.mountain>
On 5/15/2012 4:58 AM, Dan Carpenter wrote:
> This function is called with a potential NULL pointer in
> picolcd_init_framebuffer() and it causes a static checker warning. This
> used to handle NULL pointers when the picolcd code was written, but a
> couple months later we added the "info->apertures" dereference.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/video/fbsysfs.c b/drivers/video/fbsysfs.c
> index 67afa9c..a55e366 100644
> --- a/drivers/video/fbsysfs.c
> +++ b/drivers/video/fbsysfs.c
> @@ -80,6 +80,8 @@ EXPORT_SYMBOL(framebuffer_alloc);
> */
> void framebuffer_release(struct fb_info *info)
> {
> + if (!info)
> + return;
> kfree(info->apertures);
> kfree(info);
> }
And not like this:
+ if (info) {
+ if (info->apertures)
+ kfree(info->apertures);
+ kfree(info);
+ }
?
- Hein
^ permalink raw reply
* Re: [patch] fb: handle NULL pointers in framebuffer release
From: Dan Carpenter @ 2012-05-15 7:29 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20120514205837.GE20836@elgon.mountain>
On Tue, May 15, 2012 at 03:20:14PM +0800, Hein Tibosch wrote:
> On 5/15/2012 4:58 AM, Dan Carpenter wrote:
> > This function is called with a potential NULL pointer in
> > picolcd_init_framebuffer() and it causes a static checker warning. This
> > used to handle NULL pointers when the picolcd code was written, but a
> > couple months later we added the "info->apertures" dereference.
> >
> > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> >
> > diff --git a/drivers/video/fbsysfs.c b/drivers/video/fbsysfs.c
> > index 67afa9c..a55e366 100644
> > --- a/drivers/video/fbsysfs.c
> > +++ b/drivers/video/fbsysfs.c
> > @@ -80,6 +80,8 @@ EXPORT_SYMBOL(framebuffer_alloc);
> > */
> > void framebuffer_release(struct fb_info *info)
> > {
> > + if (!info)
> > + return;
> > kfree(info->apertures);
> > kfree(info);
> > }
> And not like this:
>
> + if (info) {
> + if (info->apertures)
> + kfree(info->apertures);
> + kfree(info);
> + }
>
Nah. kfree() has a NULL check built in. I think it would trigger
a checkpatch.pl warning?
regards,
dan carpenter
^ permalink raw reply
* [PATCH] OMAPDSS: DISPC: Update Accumulator configuration for chroma plane
From: Chandrabhanu Mahapatra @ 2012-05-15 8:16 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Chandrabhanu Mahapatra
DISPC has two accumulator registers DISPC_VIDp_ACCU_0 and DISPC_VIDp_ACCU_1 each
with horizontal and vertical bit fields. The bit fields can take values in the
range of -1024 to 1023. Based on bit field values DISPC decides on which one out
of 8 phases the filtering starts. DISPC_VIDp_ACCU_0 is used for progressive
output and for interlaced output both DISPC_VIDp_ACCU_0 and DISPC_VIDp_ACCU_1
are used.
The current accumulator values in DISPC scaling logic for chroma plane takes
default values for all color modes and rotation types. So, the horizontal and
vertical up and downsampling accumulator bit field values have been updated for
better performance.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
---
drivers/video/omap2/dss/dispc.c | 92 +++++++++++++++++++++++++++++++++++++-
1 files changed, 89 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index ee30937..ad779d9 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1185,6 +1185,92 @@ static void dispc_ovl_set_scale_param(enum omap_plane plane,
dispc_ovl_set_fir(plane, fir_hinc, fir_vinc, color_comp);
}
+static void dispc_ovl_set_accu_uv(enum omap_plane plane,
+ u16 orig_width, u16 orig_height, u16 out_width, u16 out_height,
+ bool ilace, enum omap_color_mode color_mode, u8 rotation)
+{
+ int h_accu2_0, h_accu2_1;
+ int v_accu2_0, v_accu2_1;
+ int chroma_hinc, chroma_vinc;
+ int idx;
+
+ struct accu {
+ s8 h0_m, h0_n;
+ s8 h1_m, h1_n;
+ s8 v0_m, v0_n;
+ s8 v1_m, v1_n;
+ };
+
+ const struct accu *accu_table;
+ const struct accu *accu_val;
+
+ static const struct accu accu_nv12[4] = {
+ { 0, 1, 0, 1 , -1, 2, 0, 1 },
+ { 1, 2, -3, 4 , 0, 1, 0, 1 },
+ { -1, 1, 0, 1 , -1, 2, 0, 1 },
+ { -1, 2, -1, 2 , -1, 1, 0, 1 },
+ };
+
+ static const struct accu accu_nv12_ilace[4] = {
+ { 0, 1, 0, 1 , -3, 4, -1, 4 },
+ { -1, 4, -3, 4 , 0, 1, 0, 1 },
+ { -1, 1, 0, 1 , -1, 4, -3, 4 },
+ { -3, 4, -3, 4 , -1, 1, 0, 1 },
+ };
+
+ static const struct accu accu_yuv[4] = {
+ { 0, 1, 0, 1, 0, 1, 0, 1 },
+ { 0, 1, 0, 1, 0, 1, 0, 1 },
+ { -1, 1, 0, 1, 0, 1, 0, 1 },
+ { 0, 1, 0, 1, -1, 1, 0, 1 },
+ };
+
+ switch (rotation) {
+ case OMAP_DSS_ROT_0:
+ idx = 0;
+ break;
+ case OMAP_DSS_ROT_90:
+ idx = 1;
+ break;
+ case OMAP_DSS_ROT_180:
+ idx = 2;
+ break;
+ case OMAP_DSS_ROT_270:
+ idx = 3;
+ break;
+ default:
+ BUG();
+ }
+
+ switch (color_mode) {
+ case OMAP_DSS_COLOR_NV12:
+ if (ilace)
+ accu_table = accu_nv12_ilace;
+ else
+ accu_table = accu_nv12;
+ break;
+ case OMAP_DSS_COLOR_YUV2:
+ case OMAP_DSS_COLOR_UYVY:
+ accu_table = accu_yuv;
+ break;
+ default:
+ BUG();
+ }
+
+ accu_val = &accu_table[idx];
+
+ chroma_hinc = 1024 * orig_width / out_width;
+ chroma_vinc = 1024 * orig_height / out_height;
+
+ h_accu2_0 = (accu_val->h0_m * chroma_hinc / accu_val->h0_n) % 1024;
+ h_accu2_1 = (accu_val->h1_m * chroma_hinc / accu_val->h1_n) % 1024;
+ v_accu2_0 = (accu_val->v0_m * chroma_vinc / accu_val->v0_n) % 1024;
+ v_accu2_1 = (accu_val->v1_m * chroma_vinc / accu_val->v1_n) % 1024;
+
+ dispc_ovl_set_vid_accu2_0(plane, h_accu2_0, v_accu2_0);
+ dispc_ovl_set_vid_accu2_1(plane, h_accu2_1, v_accu2_1);
+}
+
static void dispc_ovl_set_scaling_common(enum omap_plane plane,
u16 orig_width, u16 orig_height,
u16 out_width, u16 out_height,
@@ -1249,6 +1335,9 @@ static void dispc_ovl_set_scaling_uv(enum omap_plane plane,
int scale_x = out_width != orig_width;
int scale_y = out_height != orig_height;
+ dispc_ovl_set_accu_uv(plane, orig_width, orig_height, out_width,
+ out_height, ilace, color_mode, rotation);
+
if (!dss_has_feature(FEAT_HANDLE_UV_SEPARATE))
return;
if ((color_mode != OMAP_DSS_COLOR_YUV2 &&
@@ -1297,9 +1386,6 @@ static void dispc_ovl_set_scaling_uv(enum omap_plane plane,
REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), scale_x ? 1 : 0, 5, 5);
/* set V scaling */
REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), scale_y ? 1 : 0, 6, 6);
-
- dispc_ovl_set_vid_accu2_0(plane, 0x80, 0);
- dispc_ovl_set_vid_accu2_1(plane, 0x80, 0);
}
static void dispc_ovl_set_scaling(enum omap_plane plane,
--
1.7.1
^ permalink raw reply related
* Re: ASoC: wm9712: Microphone doesn't work: Mux handling broken?
From: Christoph Fritz @ 2012-05-15 9:15 UTC (permalink / raw)
To: Mark Brown
Cc: alsa-devel, Hans J. Koch, Sascha Hauer, Liam Girdwood,
linux-fbdev
In-Reply-To: <20120513035652.GA3532@lovely.krouter>
On Sun, May 13, 2012 at 05:56:53AM +0200, Christoph Fritz wrote:
> On Sat, May 12, 2012 at 12:51:31PM +0100, Mark Brown wrote:
> > On Sat, May 12, 2012 at 02:15:56AM +0200, Christoph Fritz wrote:
> >
> > > They refuse to change their Item0 because they are defined as
> > > SND_SOC_DAPM_MUX without a correlating path->name so that
> > > snd_soc_dapm_mux_update_power() (in sound/soc/soc-dapmc) doesn't
> > > change anything.
> >
> > A route into a mux without a path name (other than a supply) just isn't
> > meaningful and I'm surprised it ever worked.
> >
> > > It works in 2.6.33, but current kernel has different mux handling and
> > > it seems that no one since cared that much about microphone support.
> >
> > It's nothing to do with microphones really, it's more that AC'97 CODECs
> > are rarely used with modern kernels as the boards that use AC'97 are
> > mostly quite old and suffer performance issues with modern software
> > stacks so newer kernels haven't been getting much testing with them.
> >
> > > Mark, can you confirm this, purpose a fix or even come up with
> > > a patch?
> >
> > Just filling in the appropriate mux value in the relevant route should
> > do the trick.
Do you mean filling in to wm9712_audio_map or wm9712_enum?
> > Looking at the code it looks like the widget isn't hooked
> > into the audio routing map at all so I'm a little surprised.
Does that mean that wm9712_dapm_widgets should be referred by a
struct snd_kcontrol_new ?
> >I'm out of
> > the office at the minute and so can't readily set up a test system
> > myself.
I'm not that into alsa and would greatly appreciate if you could have
a look with your test system.
Thanks,
-- Christoph
^ permalink raw reply
* Re: [PATCH] OMAPDSS: DISPC: Update Accumulator configuration for chroma plane
From: Tomi Valkeinen @ 2012-05-15 12:51 UTC (permalink / raw)
To: Chandrabhanu Mahapatra; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1337069087-21121-1-git-send-email-cmahapatra@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1687 bytes --]
On Tue, 2012-05-15 at 13:34 +0530, Chandrabhanu Mahapatra wrote:
> DISPC has two accumulator registers DISPC_VIDp_ACCU_0 and DISPC_VIDp_ACCU_1 each
> with horizontal and vertical bit fields. The bit fields can take values in the
> range of -1024 to 1023. Based on bit field values DISPC decides on which one out
> of 8 phases the filtering starts. DISPC_VIDp_ACCU_0 is used for progressive
> output and for interlaced output both DISPC_VIDp_ACCU_0 and DISPC_VIDp_ACCU_1
> are used.
>
> The current accumulator values in DISPC scaling logic for chroma plane takes
> default values for all color modes and rotation types. So, the horizontal and
> vertical up and downsampling accumulator bit field values have been updated for
> better performance.
>
> Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
> ---
> @@ -1249,6 +1335,9 @@ static void dispc_ovl_set_scaling_uv(enum omap_plane plane,
> int scale_x = out_width != orig_width;
> int scale_y = out_height != orig_height;
>
> + dispc_ovl_set_accu_uv(plane, orig_width, orig_height, out_width,
> + out_height, ilace, color_mode, rotation);
> +
> if (!dss_has_feature(FEAT_HANDLE_UV_SEPARATE))
> return;
> if ((color_mode != OMAP_DSS_COLOR_YUV2 &&
This crashes if color mode is not yuv or nv.
Should the set_accu_uv call be a bit later, after these lines:
if (!dss_has_feature(FEAT_HANDLE_UV_SEPARATE))
return;
if ((color_mode != OMAP_DSS_COLOR_YUV2 &&
color_mode != OMAP_DSS_COLOR_UYVY &&
color_mode != OMAP_DSS_COLOR_NV12)) {
/* reset chroma resampling for RGB formats */
REG_FLD_MOD(DISPC_OVL_ATTRIBUTES2(plane), 0, 8, 8);
return;
}
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/4] iio: add LM3533 ambient light sensor driver
From: Johan Hovold @ 2012-05-15 16:44 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Johan Hovold, Rob Landley, Richard Purdie, Samuel Ortiz,
Greg Kroah-Hartman, Florian Tobias Schandinat, Arnd Bergmann,
Andrew Morton, Mark Brown, linux-doc, linux-kernel, linux-iio,
devel, linux-fbdev
In-Reply-To: <4FA923E7.6050707@cam.ac.uk>
On Tue, May 08, 2012 at 02:47:19PM +0100, Jonathan Cameron wrote:
> On 5/3/2012 5:36 PM, Johan Hovold wrote:
> > On Thu, May 03, 2012 at 12:40:10PM +0100, Jonathan Cameron wrote:
> >> On 5/3/2012 11:26 AM, Johan Hovold wrote:
> >>> Add sub-driver for the ambient light sensor interface on National
> >>> Semiconductor / TI LM3533 lighting power chips.
> >>>
> >>> The sensor interface can be used to control the LEDs and backlights of
> >>> the chip through defining five light zones and three sets of
> >>> corresponding brightness target levels.
> >>>
> >>> The driver provides raw and mean adc readings along with the current
> >>> light zone through sysfs. A threshold event can be generated on zone
> >>> changes.
> >> Code is fine. Pretty much all my comments are to do with the interface.
> > [...]
> >
> >>> diff --git a/drivers/staging/iio/Documentation/sysfs-bus-iio-light-lm3533-als b/drivers/staging/iio/Documentation/sysfs-bus-iio-light-lm3533-als
> >>> new file mode 100644
> >>> index 0000000..9849d14
> >>> --- /dev/null
> >>> +++ b/drivers/staging/iio/Documentation/sysfs-bus-iio-light-lm3533-als
> >>> @@ -0,0 +1,62 @@
> >>> +What: /sys/bus/iio/devices/iio:deviceX/gain
> >>> +Date: April 2012
> >>> +KernelVersion: 3.5
> >>> +Contact: Johan Hovold<jhovold@gmail.com>
> >>> +Description:
> >>> + Set the ALS gain-resistor setting (0..127) for analog input
> >>> + mode, where
> >>> +
> >>> + 0000000 - ALS input is high impedance
> >>> + 0000001 - 200kOhm (10uA at 2V full-scale)
> >>> + 0000010 - 100kOhm (20uA at 2V full-scale)
> >>> + ...
> >>> + 1111110 - 1.587kOhm (1.26mA at 2V full-scale)
> >>> + 1111111 - 1.575kOhm (1.27mA at 2V full-scale)
> >>> +
> >>> + R_als = 2V / (10uA * gain) (gain> 0)
> >> Firstly, no magic numbers. These are definitely magic.
> > Not that magic as they're clearly documented (in code and public
> > datasheets), right? What would you prefer instead?
> The numbers on the right of the - look good to me though then this isn't
> a gain. (200kohm) and the infinite element is annoying. Why not
> compute the actual gains?
> Gain = (Rals*10e-6)/2 and use those values? Yes you will have to do
> a bit of fixed point maths in the driver but the advantage is you'll
> have real values that are standardizable across multiple devices
> and hence allow your device to be operated by generic userspace
> code. Welcome to standardising interfaces - my favourite occupation ;)
>
> >> Secondly see in_illuminance0_scale for a suitable existing attribute.
> > I didn't consider scale to be appropriate given the following
> > documentation (e.g, for in_voltageY_scale):
> sorry I just did this to someone else in another review (so I'm
> consistently wrong!)
>
> in_voltageY_calibscale is what I should have said. That one applies a
> scaling before the raw reading is generated (so in hardware).
Ok, then calibscale is the appropriate attribute for the resistor
setting. But as this is a device-specific hardware-calibration setting
I would suggest using the following interface:
What: /sys/bus/iio/devices/iio:deviceX/in_illuminance_calibscale
Description:
Set the ALS calibration scale (internal resistors) for
analog input mode, where the scale factor is the current in uA
at 2V full-scale (10..1270, 10uA step), that is,
R_als = 2V / in_illuminance_calibscale
This setting is ignored in PWM mode.
[...]
> >>> +What: /sys/bus/iio/devices/iio:deviceX/target[m]_[n]
> >>> +Date: April 2012
> >>> +KernelVersion: 3.5
> >>> +Contact: Johan Hovold<jhovold@gmail.com>
> >>> +Description:
> >>> + Set the target brightness for ALS-mapper m in light zone n
> >>> + (0..255), where m in 1..3 and n in 0..4.
> >> Don't suppose you could do a quick summary of what these zones are
> >> and why there are 3 ALS-mappers? I'm not getting terribly far on a
> >> quick look at the datasheet!
> > Of course. The average adc readings are mapped to five light zones using
> > eight zone boundary registers (4 boundaries with hysteresis) and a set
> > of rules.
> This is going to be fun. We'll need the boundaries and attached
> hysteresis attributes to fully specify these (nothing would indicate
> that hysterisis is involved otherwise).
You can't define the hysteresis explicitly with the lm3533 register
interface, rather it's is defined implicitly in case threshY_falling is
less than threshY_rasising.
So the raising/falling attributes should be enough, right?
> > To simplify somewhat (by ignoring some of the rules): If the average
> > adc input drops below boundary0_low, the zone register reads 0; if it
> > drops below boundary1_low, it reads 1, and so on. If the input it
> > increases over boundary3_high, the zone register return 4; if it
> > increases passed boundary2_high, it returns zone 3, etc.
> >
> > That is, roughly something like (we get 8-bits of input from the ADC):
> >
> > zone 0
> >
> > boundary0_low 51
> > boundary0_high 53
> >
> > zone 1
> >
> > boundary1_low 102
> > boundary1_high 106
> >
> > zone 2
> >
> > boundary2_low 153
> > boundary2_high 161
> >
> > zone 3
> >
> > boundary3_low 204
> > boundary3_high 220
> >
> > zone 4
> >
> > [ Figure 6 on page 20 in the datasheets should make it clear. ]
> >
> > The ALS interface and it's zone concept can then be used to control the
> > LEDs and backlights of the chip, by determining the target brightness for
> > each zone, e.g., set brightness to 52 when in zone 0.
> >
> > To complicate things further (and it is complicated), there are three
> > such sets of target brightness values: ALSM1, ALSM2, ALSM3.
> >
> > So for each LED or backlight you can set ALS-input control mode, by
> > saying that the device should get it's brightness levels from target set
> > 1, 2, or 3.
> >
> > [ And it gets even more complicated, as ALSM1 can only control
> > backlight0, where as ALSM2 and ALSM3 can control any of the remaining
> > devices, but that's irrelevant here. ]
> >
> > Initially, I thought this interface to be too esoteric to be worth
> > generalising, but it sort of fits with event thresholds so I gave it a
> > try.
> Glad you did and it pretty much fits, be it with a few extensions being
> necessary.
> > The biggest conceptual problem, I think, is that the zone
> > boundaries can be used to control the other devices, even when the event
> > is not enabled (or even an irq line not configured). That is, I find it
> > a bit awkward that the event thresholds also defines the zones (a sort of
> > discrete scaling factor).
> That is indeed awkward. I'm not sure how we handle this either. If we
> need to control these from the other devices (e.g. the back light
> driver) then we'll have to get them into chan_spec and use the
> inkernel interfaces to do it. Not infeasible but I was hoping to
> avoid that until we have had a few months to see what similar devices
> show up (on basis nothing in this world is a one off for long ;)
I don't think the control bits can or should be generalised at this
point. The same ALS-target values may be used to control more than one
device, so they need to be set from the als rather from the controlled
device (otherwise, changing the target value of led1 could change that
of the other three leds without the user realising that this can be a
side effect).
> > Perhaps simply keeping the attributes outside of events (e.g. named
> > boundary[n]_{low,high}) and having a custom event enabled (e.g.
> > in_illuminance_zone_change_en) is the best solution?
> Maybe, but it's ugly and as you have said, they do correspond pretty well to
> thresholds so I'd rather you went with that.
> The core stuff for registering events clearly needs a rethink.... For
> now doing it as you describe above (with the addition fo hysteresis
> attributes) should be fine. Just document the 'quirks'.
Ok, I'll keep the event/zone interface as it stands for now and we'll
see if it can be generalised later. [ See my comment on the hysteresis
above: there are only the rising/falling thresholds (low/high
boundaries) and no boundary or hysteresis settings. ]
Thanks,
Johan
^ 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