* [PATCH] da8xx-fb: Rounding FB size to satisfy SGX buffer requirements
From: Aditya Nellutla @ 2012-05-23 6:18 UTC (permalink / raw)
To: linux-fbdev
In the real time use-case when SGX is used for rendering to FB buffers it has been
observed that, the available memory from framebuffer driver is not sufficient for
SGX under certain cases (like 16-bit WVGA resolution). SGX requires 2 swap buffers
with each of the buffers aligned to lcm(line_length, PAGE_SIZE).
Inorder to satisfy this requirement, we have two options,
- Increase number of FB buffers (LCD_NUM_BUFFERS) to 3. This is not
recommended as we end up wasting huge memory in most of the cases.
- Align FB buffers to lcm(line_length, PAGE_SIZE).This ensures framebuffer
size is increased to satisfy SGX requirements keeping alignment intact.
This patch makes sure that FB allocates buffers aligned to above formula.
Signed-off-by: Aditya Nellutla <aditya.n@ti.com>
---
drivers/video/da8xx-fb.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 47118c7..2f24c19 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -31,6 +31,7 @@
#include <linux/cpufreq.h>
#include <linux/console.h>
#include <linux/slab.h>
+#include <linux/lcm.h>
#include <video/da8xx-fb.h>
#include <asm/div64.h>
@@ -1114,6 +1115,7 @@ static int __devinit fb_probe(struct platform_device *device)
struct da8xx_fb_par *par;
resource_size_t len;
int ret, i;
+ unsigned long ulcm;
if (fb_pdata = NULL) {
dev_err(&device->dev, "Can not get platform data\n");
@@ -1209,7 +1211,8 @@ static int __devinit fb_probe(struct platform_device *device)
/* allocate frame buffer */
par->vram_size = lcdc_info->width * lcdc_info->height * lcd_cfg->bpp;
- par->vram_size = PAGE_ALIGN(par->vram_size/8);
+ ulcm = lcm((lcdc_info->width * lcd_cfg->bpp)/8, PAGE_SIZE);
+ par->vram_size = roundup(par->vram_size/8, ulcm);
par->vram_size = par->vram_size * LCD_NUM_BUFFERS;
par->vram_virt = dma_alloc_coherent(NULL,
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] backlight: initialize struct backlight_properties properly
From: Andrew Morton @ 2012-05-22 20:59 UTC (permalink / raw)
To: Corentin Chary
Cc: Arnd Bergmann, Mathieu Poirier, Tobias Schandinat, Mark Brown,
linux-kernel, dri-devel, platform-driver-x86, patches, Florian,
Dave, Richard Purdie, linux-fbdev, Lars-Peter, Airlie, Axel Lin,
linux-omap, Matthew Garrett
In-Reply-To: <1337585085-4891-1-git-send-email-corentin.chary@gmail.com>
On Mon, 21 May 2012 09:24:35 +0200
Corentin Chary <corentin.chary@gmail.com> wrote:
> In all these files, the .power field was never correctly initialized.
>
> ...
>
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -342,6 +342,7 @@ int intel_panel_setup_backlight(struct drm_device *dev)
> else
> return -ENODEV;
>
> + memset(&props, 0, sizeof(props));
This code is all still quite fragile. What happens if we add a new
field to backlight_properties? We need to go edit a zillion drivers?
There are two ways of fixing this:
a) write and use
void backlight_properties_init(struct backlight_properties *props,
int type, int max_brightness, etc);
or
b) edit all sites to do
struct backlight_properties bl_props = {
.type = BACKLIGHT_RAW,
.max_brighness = intel_panel_get_max_backlight(dev),
.power = FB_BLANK_UNBLANK,
};
they're largely equivalent - the struct will be zeroed out and
then certain fields will be initialised. a) is a bit better because
some future field may not want the all-zeroes pattern (eg, a spinlock).
But they're both better than what we have now!
^ permalink raw reply
* Re: [PATCH 0/2] OMAPDSS: write-through caching support for omapfb
From: Siarhei Siamashka @ 2012-05-22 20:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1337716444-30139-1-git-send-email-siarhei.siamashka@gmail.com>
On Tue, May 22, 2012 at 10:54 PM, Siarhei Siamashka
<siarhei.siamashka@gmail.com> wrote:
> And at least for ARM11 and Cortex-A8 processors, the performance of
> write-through cache is really good. Cortex-A9 is another story, because
> all pages marked as Write-Through are supposedly treated as Non-Cacheable:
> http://infocenter.arm.com/help/topic/com.arm.doc.ddi0388h/CBBFDIJD.html
> So OMAP4 is out of luck.
I don't have Pandaboard ES, but still tried to experiment changing the
following line in the kernel sources to benchmark different types of
caching for the framebuffer on Origen board (Exynos 4210):
https://github.com/torvalds/linux/blob/v3.4/drivers/media/video/videobuf2-memops.c#L158
It was not a totally clean experiment, because 500x500 16bpp pixel
buffer is much smaller than 1MiB L2 cache and the performance numbers
may be a bit odd. Also I have not checked whether the same buffer may
be mapped with different cacheability attributes anywhere else (which
would be bad). But still it was interesting to see whether
write-through cache is of any use and whether it could serve as a
replacement for shadowfb.
Origen board, Exynos 4210, Cortex-A9 1.2GHz, 1920x1080 screen
resolution, 16bpp desktop color depth (I did not find any obvious way
how to change it to 32bpp yet):
$ x11perf -scroll500 -copywinwin500 -copypixpix500 \
-copypixwin500 -copywinpix500
-- pgprot_noncached + shadowfb
100000 trep @ 0.2708 msec ( 3690.0/sec): Scroll 500x500 pixels
40000 trep @ 0.7307 msec ( 1370.0/sec): Copy 500x500 from window to window
60000 trep @ 0.5471 msec ( 1830.0/sec): Copy 500x500 from pixmap to window
60000 trep @ 0.5822 msec ( 1720.0/sec): Copy 500x500 from window to pixmap
40000 trep @ 0.6584 msec ( 1520.0/sec): Copy 500x500 from pixmap to pixmap
-- pgprot_writecombine + shadowfb
100000 trep @ 0.2612 msec ( 3830.0/sec): Scroll 500x500 pixels
40000 trep @ 0.7058 msec ( 1420.0/sec): Copy 500x500 from window to window
60000 trep @ 0.5262 msec ( 1900.0/sec): Copy 500x500 from pixmap to window
60000 trep @ 0.5797 msec ( 1730.0/sec): Copy 500x500 from window to pixmap
40000 trep @ 0.6554 msec ( 1530.0/sec): Copy 500x500 from pixmap to pixmap
-- pgprot_writethrough + shadowfb
100000 trep @ 0.2609 msec ( 3830.0/sec): Scroll 500x500 pixels
40000 trep @ 0.7018 msec ( 1420.0/sec): Copy 500x500 from window to window
60000 trep @ 0.5260 msec ( 1900.0/sec): Copy 500x500 from pixmap to window
60000 trep @ 0.5758 msec ( 1740.0/sec): Copy 500x500 from window to pixmap
40000 trep @ 0.6569 msec ( 1520.0/sec): Copy 500x500 from pixmap to pixmap
-- pgprot_noncached
3500 trep @ 7.5972 msec ( 132.0/sec): Scroll 500x500 pixels
1800 trep @ 14.7146 msec ( 68.0/sec): Copy 500x500 from window to window
6000 trep @ 4.6501 msec ( 215.0/sec): Copy 500x500 from pixmap to window
8000 trep @ 3.3500 msec ( 299.0/sec): Copy 500x500 from window to pixmap
40000 trep @ 0.6546 msec ( 1530.0/sec): Copy 500x500 from pixmap to pixmap
-- pgprot_writecombine
10000 trep @ 2.9439 msec ( 340.0/sec): Scroll 500x500 pixels
6000 trep @ 5.7246 msec ( 175.0/sec): Copy 500x500 from window to window
60000 trep @ 0.4213 msec ( 2370.0/sec): Copy 500x500 from pixmap to window
12000 trep @ 2.2423 msec ( 446.0/sec): Copy 500x500 from window to pixmap
40000 trep @ 0.6648 msec ( 1500.0/sec): Copy 500x500 from pixmap to pixmap
-- pgprot_writethrough
40000 trep @ 0.7103 msec ( 1410.0/sec): Scroll 500x500 pixels
20000 trep @ 1.3024 msec ( 768.0/sec): Copy 500x500 from window to window
80000 trep @ 0.3933 msec ( 2540.0/sec): Copy 500x500 from pixmap to window
18000 trep @ 1.3967 msec ( 716.0/sec): Copy 500x500 from window to pixmap
40000 trep @ 0.6548 msec ( 1530.0/sec): Copy 500x500 from pixmap to pixmap
Without shadowfb, the performance of "writecombine" looks to be better
than "noncached". And "writethrough" is clearly the fastest. Still
even "writethrough" is no match for shadowfb on Cortex-A9 (unlike
ARM11 and Cortex-A8).
So is Cortex-A9 a lost cause? Maybe experimenting with page table
entries and tweaking inner/outer cacheability attributes could provide
something? From the first glance, it looks like read performance for
write-through cached memory is rather bad on Cortex-A9. But still
there is some speedup, so it does not seem to be treated as totally
non-cached. And at least PL310 L2 cache controller has some support
for "Cacheable write-through, allocate on read":
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0246f/ch02s03s01.html
--
Best regards,
Siarhei Siamashka
^ permalink raw reply
* [PATCH 2/2] OMAPDSS: Optionally enable write-through cache for the framebuffer
From: Siarhei Siamashka @ 2012-05-22 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1337716444-30139-1-git-send-email-siarhei.siamashka@gmail.com>
Write-through cached framebuffer eliminates the need for using shadow
framebuffer in xf86-video-fbdev DDX. At the very least this reduces
memory footprint, but the performance is also the same or better
when moving windows or scrolling on ARM11 and Cortex-A8 hardware.
Benchmark with xf86-video-fbdev on IGEPv2 board (TI DM3730, 1GHz),
1280x1024 screen resolution and 32bpp desktop color depth:
$ x11perf -scroll500 -copywinwin500 -copypixpix500 \
-copypixwin500 -copywinpix500
-- omapfb.vram_cache=n, Option "ShadowFB" "true" in xorg.conf
10000 trep @ 3.4583 msec ( 289.0/sec): Scroll 500x500 pixels
6000 trep @ 4.3255 msec ( 231.0/sec): Copy 500x500 from window to window
8000 trep @ 3.2738 msec ( 305.0/sec): Copy 500x500 from pixmap to window
8000 trep @ 3.1707 msec ( 315.0/sec): Copy 500x500 from window to pixmap
8000 trep @ 3.4761 msec ( 288.0/sec): Copy 500x500 from pixmap to pixmap
-- omapfb.vram_cache=n, Option "ShadowFB" "false" in xorg.conf
5000 trep @ 5.2357 msec ( 191.0/sec): Scroll 500x500 pixels
1200 trep @ 21.0346 msec ( 47.5/sec): Copy 500x500 from window to window
8000 trep @ 3.1590 msec ( 317.0/sec): Copy 500x500 from pixmap to window
6000 trep @ 4.5062 msec ( 222.0/sec): Copy 500x500 from window to pixmap
8000 trep @ 3.4767 msec ( 288.0/sec): Copy 500x500 from pixmap to pixmap
-- omapfb.vram_cache=y, Option "ShadowFB" "true" in xorg.conf
10000 trep @ 3.4580 msec ( 289.0/sec): Scroll 500x500 pixels
6000 trep @ 4.3424 msec ( 230.0/sec): Copy 500x500 from window to window
8000 trep @ 3.2673 msec ( 306.0/sec): Copy 500x500 from pixmap to window
8000 trep @ 3.1626 msec ( 316.0/sec): Copy 500x500 from window to pixmap
8000 trep @ 3.4733 msec ( 288.0/sec): Copy 500x500 from pixmap to pixmap
-- omapfb.vram_cache=y, Option "ShadowFB" "false" in xorg.conf
10000 trep @ 3.4893 msec ( 287.0/sec): Scroll 500x500 pixels
8000 trep @ 4.0600 msec ( 246.0/sec): Copy 500x500 from window to window
8000 trep @ 3.1565 msec ( 317.0/sec): Copy 500x500 from pixmap to window
8000 trep @ 3.1373 msec ( 319.0/sec): Copy 500x500 from window to pixmap
8000 trep @ 3.4631 msec ( 289.0/sec): Copy 500x500 from pixmap to pixmap
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
---
Documentation/arm/OMAP/DSS | 10 ++++++++++
drivers/video/omap2/omapfb/omapfb-main.c | 7 ++++++-
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/Documentation/arm/OMAP/DSS b/Documentation/arm/OMAP/DSS
index 888ae7b..4e41a15 100644
--- a/Documentation/arm/OMAP/DSS
+++ b/Documentation/arm/OMAP/DSS
@@ -293,6 +293,16 @@ omapfb.rotate=<angle>
omapfb.mirror=<y|n>
- Default mirror for all framebuffers. Only works with DMA rotation.
+omapfb.vram_cache=<y|n>
+ - Sets the framebuffer memory to be write-through cached. This may be
+ useful in the configurations where only CPU is allowed to write to
+ the framebuffer and eliminate the need for enabling shadow
+ framebuffer in Xorg DDX drivers such as xf86-video-fbdev and
+ xf86-video-omapfb. Enabling write-through cache is only useful
+ for ARM11 and Cortex-A8 processors. Cortex-A9 does not support
+ write-through cache well, see "Cortex-A9 behavior for Normal Memory
+ Cacheable memory regions" section in Cortex-A9 TRM for more details.
+
omapdss.def_disp=<display>
- Name of default display, to which all overlays will be connected.
Common examples are "lcd" or "tv".
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index b00db40..a684920 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -46,6 +46,7 @@ static char *def_vram;
static bool def_vrfb;
static int def_rotate;
static bool def_mirror;
+static bool def_vram_cache;
static bool auto_update;
static unsigned int auto_update_freq;
module_param(auto_update, bool, 0);
@@ -1123,7 +1124,10 @@ static int omapfb_mmap(struct fb_info *fbi, struct vm_area_struct *vma)
vma->vm_pgoff = off >> PAGE_SHIFT;
vma->vm_flags |= VM_IO | VM_RESERVED;
- vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
+ if (def_vram_cache)
+ vma->vm_page_prot = pgprot_writethrough(vma->vm_page_prot);
+ else
+ vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
vma->vm_ops = &mmap_user_ops;
vma->vm_private_data = rg;
if (io_remap_pfn_range(vma, vma->vm_start, off >> PAGE_SHIFT,
@@ -2493,6 +2497,7 @@ module_param_named(vram, def_vram, charp, 0);
module_param_named(rotate, def_rotate, int, 0);
module_param_named(vrfb, def_vrfb, bool, 0);
module_param_named(mirror, def_mirror, bool, 0);
+module_param_named(vram_cache, def_vram_cache, bool, 0444);
/* late_initcall to let panel/ctrl drivers loaded first.
* I guess better option would be a more dynamic approach,
--
1.7.3.4
^ permalink raw reply related
* [PATCH 1/2] ARM: pgtable: add pgprot_writethrough() macro
From: Siarhei Siamashka @ 2012-05-22 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1337716444-30139-1-git-send-email-siarhei.siamashka@gmail.com>
Needed for remapping pages with write-through cacheable
attribute. May be useful for framebuffers.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
---
arch/arm/include/asm/pgtable.h | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index f66626d..04297fa 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
@@ -103,6 +103,9 @@ extern pgprot_t pgprot_kernel;
#define pgprot_stronglyordered(prot) \
__pgprot_modify(prot, L_PTE_MT_MASK, L_PTE_MT_UNCACHED)
+#define pgprot_writethrough(prot) \
+ __pgprot_modify(prot, L_PTE_MT_MASK, L_PTE_MT_WRITETHROUGH)
+
#ifdef CONFIG_ARM_DMA_MEM_BUFFERABLE
#define pgprot_dmacoherent(prot) \
__pgprot_modify(prot, L_PTE_MT_MASK, L_PTE_MT_BUFFERABLE | L_PTE_XN)
--
1.7.3.4
^ permalink raw reply related
* [PATCH 0/2] OMAPDSS: write-through caching support for omapfb
From: Siarhei Siamashka @ 2012-05-22 19:54 UTC (permalink / raw)
To: linux-arm-kernel
This is a very simple few-liner patchset, which allows to optionally
enable write-through caching for OMAP DSS framebuffer. The problem with
the current writecombine cacheability attribute is that it only speeds
up writes. Uncached reads are slow, even though the use of NEON mitigates
this problem a bit.
Traditionally, xf86-video-fbdev DDX is using shadow framebuffer in the
system memory. Which contains a copy of the framebuffer data for the
purpose of providing fast read access to it when needed. Framebuffer
read access is required not so often, but it still gets used for
scrolling and moving windows around in Xorg server. And the users
perceive their linux desktop as rather sluggish when these operations
are not fast enough.
In the case of ARM hardware, framebuffer is typically physically
located in the main memory. And the processors still support
write-through cacheability attribute. According to ARM ARM, the writes
done to write-through cached memory inside the level of cache are
visible to all observers outside the level of cache without the need
of explicit cache maintenance (same rule as for non-cached memory).
So write-through cache is a perfect choice when only CPU is allowed
to modify the data in the framebuffer and everyone else (screen
refresh DMA) is only reading it. That is, assuming that write-through
cached memory provides good performance and there are no quirks.
As the framebuffer reads become fast, the need for shadow framebuffer
disappears.
And at least for ARM11 and Cortex-A8 processors, the performance of
write-through cache is really good. Cortex-A9 is another story, because
all pages marked as Write-Through are supposedly treated as Non-Cacheable:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0388h/CBBFDIJD.html
So OMAP4 is out of luck. But OMAP3 based hardware can have a nice
graphics performance boost. And OMAP3 actually needs it a lot more.
PS. The xf86-video-omapfb-0.1.1 driver does not even use shadow
framebuffer (ouch!). So its users, if any, should see an immediate
speedup.
Siarhei Siamashka (2):
ARM: pgtable: add pgprot_writethrough() macro
OMAPDSS: Optionally enable write-through cache for the framebuffer
Documentation/arm/OMAP/DSS | 10 ++++++++++
arch/arm/include/asm/pgtable.h | 3 +++
drivers/video/omap2/omapfb/omapfb-main.c | 7 ++++++-
3 files changed, 19 insertions(+), 1 deletions(-)
--
1.7.3.4
^ permalink raw reply
* [GIT PULL] OMAP DSS for v3.5
From: Tomi Valkeinen @ 2012-05-22 10:09 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: linux-omap, linux-fbdev, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 11032 bytes --]
Hi Florian,
Here are the OMAP DSS changes for 3.5.
I really tried this time to send the pull request early, but here I am
again, sending it when the merge window has already opened... A few
late-found bugs caused some unnecessary delays.
I'm using github this time instead of gitorious, as gitorious seems to
be down. This is my first pull request with a signed tag, I hope
everything is correct.
Note that there's a merge for small branch with omap board file changes
(e4a9e94cc58ed6e4efb02b80be3a9bf57f448d07) that is also pulled by Tony
for the linux-omap tree. This is meant to help avoid conflicts in the
board files.
Tomi
The following changes since commit 66f75a5d028beaf67c931435fdc3e7823125730c:
Linux 3.4-rc4 (2012-04-21 14:47:52 -0700)
are available in the git repository at:
git://github.com/tomba/linux.git tags/omapdss-for-3.5
for you to fetch changes up to e92a5b28f71aea01b281f9c89d97a4bc5b24748f:
OMAPDSS: HDMI: OMAP4: Update IRQ flags for the HPD IRQ request (2012-05-22 11:00:09 +0300)
----------------------------------------------------------------
Omapdss driver changes for 3.5 merge window.
Lots of normal development commits, but perhaps most notable changes are:
* HDMI rework to properly decouple the HDMI audio part from the HDMI video part.
* Restructure omapdss core driver so that it's possible to implement device
tree support. This included changing how platform data is passed to the
drivers, changing display device registration and improving the panel driver's
ability to configure the underlying video output interface.
* Basic support for DSI packet interleaving
----------------------------------------------------------------
Archit Taneja (19):
OMAPDSS: DISPC/RFBI: Use dispc_mgr_set_lcd_timings() for setting lcd size
OMAPDSS: DISPC: Use a common function to set manager timings
OMAPDSS: DISPC: Clean up manager timing/size functions
OMAPDSS: HDMI: Fix ti_hdmi_4xxx_core_dump
OMAPDSS: HDMI: define and dump CORE registers in correct order
OMAPDSS: Fix DSI_FCLK clock source selection
OMAPDSS: DISPC: Remove Fake VSYNC support
OMAPDSS: APPLY: Add manager timings as extra_info in private data
OMAPDSS: Apply manager timings instead of direct DISPC writes
OMAPDSS: MANAGER: Create a function to check manager timings
OMAPDSS: APPLY: Don't check manager settings if it is disabled
OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled
OMAPDSS: APPLY: Remove an unnecessary omap_dss_device pointer
OMAPDSS: DISPC: Remove omap_dss_device pointer usage from dispc_mgr_pclk_rate()
OMAPDSS: DISPC: Remove usage of dispc_mgr_get_device()
OMAPDSS: DSI: Support command mode interleaving during video mode blanking periods
OMAPDSS: VENC/DISPC: Delay dividing Y resolution for managers connected to VENC
OMAPDSS: Apply VENC timings even if panel is disabled
Axel Castaneda Gonzalez (1):
OMAPDSS: HDMI: Decouple wrapper enable/disable and audio start/stop
Chandrabhanu Mahapatra (5):
OMAPDSS: DISPC: Enable predecimation
OMAPDSS: DISPC: Handle synclost errors in OMAP3
OMAPDSS: DISPC: Correct DISPC functional clock usage
OMAPDSS: DISPC: Update Accumulator configuration for chroma plane
OMAPDSS: DISPC: Support rotation through TILER
Grazvydas Ignotas (5):
OMAPDSS: OMAPFB: check for matching memory size early
OMAPDSS: provide default get_timings function for panels
OMAPDSS: TPO-TD03MTEA1: add set/check timing functions
OMAPDSS: VENC: allow switching venc output type at runtime
OMAPDSS: OMAPFB: always allow to configure overlay
Jan Weitzel (1):
ARM: OMAP2+ Add Primview displays to panel-generic
Mark Brown (4):
OMAP: DSS2: Remove suspicous and unused TAAL regulator API usage
OMAPDSS: VENC: Check for errors from regulator_enable()
OMAPDSS: TPO-TD03MTEA1: Check for errors from regulator_enable()
OMAPDSS: TPO-TD03MTEA1: Correct comment for power on delay
Peter Meerwald (1):
OMAPFB: remove unused FB_OMAP_BOOTLOADER_INIT config option
Ricardo Neri (15):
OMAPDSS: Provide an interface for audio support
OMAPDSS: HDMI: Split audio_enable into audio_enable/disable
OMAPDSS: HDMI: Split video_enable into video_enable/disable
OMAPDSS: HDMI: Remove ASoC codec
OMAPDSS: HDMI: OMAP4: Remove CEA-861 audio infoframe and IEC-60958 enums
OMAPDSS: HDMI: OMAP4: Remove invalid I2S settings
OMAPDSS: HDMI: Decouple HDMI audio from ASoC
OMAPDSS: HDMI: OMAP4: Expand configuration for IEC-60958 audio
OMAPDSS: HDMI: Relocate N/CTS calculation
OMAPDSS: HDMI: Add support for more audio sample rates in N/CTS calculation
OMAPDSS: HDMI: Add an audio configuration function
OMAPDSS: HDMI: OMAP4: Remap speaker order to match ALSA order
OMAPDSS: HDMI: Panel: Simplify the name of the HDMI mutex
OMAPDSS: HDMI: Implement DSS driver interface for audio
OMAPDSS: HDMI: OMAP4: Update IRQ flags for the HPD IRQ request
Russ Dill (1):
OMAPDSS: TFP410: use gpio_set_value_cansleep
Thomas Weber (2):
OMAPDSS: Add Mitsubishi AA084SB01 display support
OMAPDSS: Add EDT ET0500G0DH6 display support
Tomi Valkeinen (38):
OMAPDSS: add set_min_bus_tput pointer to omapdss's platform data
OMAPDSS: Ensure OPP100 when DSS is operational
OMAPDSS: DSI: remove option to use pck for DSI PLL clkin
OMAPDSS: panel-dvi: add PD gpio handling
OMAP: board-files: remove custom PD GPIO handling for DVI output
OMAPDSS: TFP410: rename dvi -> tfp410
OMAPDSS: TFP410: rename dvi files to tfp410
OMAPDSS: Taal: move reset gpio handling to taal driver
OMAPDSS: DSI: implement generic DSI pin config
Merge branch 'archit/set-timing-work'
Merge branch 'for-l-o-3.5'
OMAPFB: fix parsing of vram parameter
OMAPDSS: TFP410: pdata rewrite
OMAPDSS: DSI: use dsi_get_dsidev_id(dsidev) instead of dsidev->id
OMAPDSS: clean up the omapdss platform data mess
OMAPDSS: remove return from platform_driver_unreg
OMAPDSS: use platform_driver_probe for core/dispc/dss
OMAPDSS: create custom pdevs for DSS omap_devices
OMAPDSS: create DPI & SDI devices
OMAPDSS: create DPI & SDI drivers
OMAPDSS: remove uses of dss_runtime_get/put
OMAPDSS: handle output-driver reg/unreg more dynamically
OMAPDSS: move the creation of debugfs files
OMAPDSS: use platform_driver_probe for dsi/hdmi/rfbi/venc/dpi/sdi
OMAPDSS: add __init & __exit
OMAPFB: add __init & __exit
OMAPDSS: change default_device handling
OMAPDSS: interface drivers register their panel devices
OMAPDSS: init omap_dss_devices internally
OMAPDSS: DSI: improve DSI module id handling
OMAPDSS: separate pdata based initialization
Merge branch 'dss-devtree-cleanup'
Merge branch 'omapdss-hdmi-audio'
OMAPDSS: use DSI_FIFO_BUG workaround only for manual update displays
OMAPDSS: DISPC: fix usage of dispc_ovl_set_accu_uv
OMAPDSS: remove compiler warnings when CONFIG_BUG=n
OMAPFB: remove compiler warnings when CONFIG_BUG=n
OMAPDSS: VRFB: remove compiler warnings when CONFIG_BUG=n
Documentation/arm/OMAP/DSS | 46 ++
arch/arm/mach-omap2/board-3430sdp.c | 38 +-
arch/arm/mach-omap2/board-4430sdp.c | 37 +-
arch/arm/mach-omap2/board-am3517evm.c | 25 +-
arch/arm/mach-omap2/board-cm-t35.c | 30 +-
arch/arm/mach-omap2/board-devkit8000.c | 30 +-
arch/arm/mach-omap2/board-igep0020.c | 32 +-
arch/arm/mach-omap2/board-omap3beagle.c | 37 +-
arch/arm/mach-omap2/board-omap3evm.c | 29 +-
arch/arm/mach-omap2/board-omap3stalker.c | 29 +-
arch/arm/mach-omap2/board-omap4panda.c | 39 +-
arch/arm/mach-omap2/board-overo.c | 25 +-
arch/arm/mach-omap2/display.c | 196 ++++-
drivers/video/omap/Kconfig | 8 -
drivers/video/omap2/displays/Kconfig | 8 +-
drivers/video/omap2/displays/Makefile | 2 +-
drivers/video/omap2/displays/panel-acx565akm.c | 7 -
drivers/video/omap2/displays/panel-generic-dpi.c | 107 ++-
drivers/video/omap2/displays/panel-n8x0.c | 8 -
drivers/video/omap2/displays/panel-taal.c | 108 +--
.../omap2/displays/{panel-dvi.c => panel-tfp410.c} | 186 ++---
.../video/omap2/displays/panel-tpo-td043mtea1.c | 22 +-
drivers/video/omap2/dss/Kconfig | 13 +-
drivers/video/omap2/dss/apply.c | 134 +++-
drivers/video/omap2/dss/core.c | 255 ++++---
drivers/video/omap2/dss/dispc.c | 747 ++++++++++++++------
drivers/video/omap2/dss/dispc.h | 72 ++
drivers/video/omap2/dss/display.c | 49 +-
drivers/video/omap2/dss/dpi.c | 75 +-
drivers/video/omap2/dss/dsi.c | 537 ++++++++------
drivers/video/omap2/dss/dss.c | 65 +-
drivers/video/omap2/dss/dss.h | 151 ++--
drivers/video/omap2/dss/dss_features.c | 30 +-
drivers/video/omap2/dss/dss_features.h | 5 +
drivers/video/omap2/dss/hdmi.c | 443 +++++-------
drivers/video/omap2/dss/hdmi_panel.c | 236 ++++++-
drivers/video/omap2/dss/manager.c | 19 +-
drivers/video/omap2/dss/overlay.c | 16 +-
drivers/video/omap2/dss/rfbi.c | 84 ++-
drivers/video/omap2/dss/sdi.c | 63 +-
drivers/video/omap2/dss/ti_hdmi.h | 32 +-
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 480 ++++++++-----
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 161 +----
drivers/video/omap2/dss/venc.c | 133 +++-
drivers/video/omap2/omapfb/omapfb-ioctl.c | 17 +-
drivers/video/omap2/omapfb/omapfb-main.c | 12 +-
drivers/video/omap2/omapfb/omapfb.h | 1 +
drivers/video/omap2/vrfb.c | 4 +-
include/video/omap-panel-nokia-dsi.h | 3 +
.../{omap-panel-dvi.h => omap-panel-tfp410.h} | 18 +-
include/video/omapdss.h | 75 +-
51 files changed, 2983 insertions(+), 1996 deletions(-)
rename drivers/video/omap2/displays/{panel-dvi.c => panel-tfp410.c} (56%)
rename include/video/{omap-panel-dvi.h => omap-panel-tfp410.h} (63%)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH 2/2] backlight: lm3533: replace als attribute with als_channel and als_en
From: Johan Hovold @ 2012-05-22 10:05 UTC (permalink / raw)
To: Richard Purdie, Andrew Morton
Cc: Rob Landley, Florian Tobias Schandinat, linux-doc, linux-fbdev,
Jonathan Cameron, linux-kernel, Johan Hovold
In-Reply-To: <1337681108-13838-1-git-send-email-jhovold@gmail.com>
Replace the als attribute with two separate attributes for selecting ALS
channel and enabling ALS-current-control mode.
This change is needed to reflect changes made to the ALS sub-driver
which now uses 0-indexed current output channels (rather than 1-indexed
ALS-mapper target sets).
Signed-off-by: Johan Hovold <jhovold@gmail.com>
---
.../testing/sysfs-class-backlight-driver-lm3533 | 19 +++++---
drivers/video/backlight/lm3533_bl.c | 48 ++++++++++----------
2 files changed, 37 insertions(+), 30 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-class-backlight-driver-lm3533 b/Documentation/ABI/testing/sysfs-class-backlight-driver-lm3533
index ea91f71..77cf7ac 100644
--- a/Documentation/ABI/testing/sysfs-class-backlight-driver-lm3533
+++ b/Documentation/ABI/testing/sysfs-class-backlight-driver-lm3533
@@ -1,13 +1,20 @@
-What: /sys/class/backlight/<backlight>/als
-Date: April 2012
+What: /sys/class/backlight/<backlight>/als_channel
+Date: May 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
- Set the ALS-control mode (0..2), where
+ Get the ALS output channel used as input in
+ ALS-current-control mode (0, 1), where
+
+ 0 - out_current0 (backlight 0)
+ 1 - out_current1 (backlight 1)
- 0 - disabled
- 1 - ALS-mapper 1 (backlight 0)
- 2 - ALS-mapper 2 (backlight 1)
+What: /sys/class/backlight/<backlight>/als_en
+Date: May 2012
+KernelVersion: 3.5
+Contact: Johan Hovold <jhovold@gmail.com>
+Description:
+ Enable ALS-current-control mode (0, 1).
What: /sys/class/backlight/<backlight>/id
Date: April 2012
diff --git a/drivers/video/backlight/lm3533_bl.c b/drivers/video/backlight/lm3533_bl.c
index d916ffe..18dca0c 100644
--- a/drivers/video/backlight/lm3533_bl.c
+++ b/drivers/video/backlight/lm3533_bl.c
@@ -79,55 +79,52 @@ static ssize_t show_id(struct device *dev,
return scnprintf(buf, PAGE_SIZE, "%d\n", bl->id);
}
-/*
- * ALS-control setting:
- *
- * 0 - ALS disabled
- * 1 - ALS-mapper 1 (backlight 0)
- * 2 - ALS-mapper 2 (backlight 1)
- */
-static ssize_t show_als(struct device *dev,
+static ssize_t show_als_channel(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct lm3533_bl *bl = dev_get_drvdata(dev);
+ unsigned channel = lm3533_bl_get_ctrlbank_id(bl);
+
+ return scnprintf(buf, PAGE_SIZE, "%u\n", channel);
+}
+
+static ssize_t show_als_en(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct lm3533_bl *bl = dev_get_drvdata(dev);
int ctrlbank = lm3533_bl_get_ctrlbank_id(bl);
u8 val;
u8 mask;
- int als;
+ bool enable;
int ret;
ret = lm3533_read(bl->lm3533, LM3533_REG_CTRLBANK_AB_BCONF, &val);
if (ret)
return ret;
- mask = 2 * ctrlbank;
- als = val & mask;
- if (als)
- als = ctrlbank + 1;
+ mask = 1 << (2 * ctrlbank);
+ enable = val & mask;
- return scnprintf(buf, PAGE_SIZE, "%d\n", als);
+ return scnprintf(buf, PAGE_SIZE, "%d\n", enable);
}
-static ssize_t store_als(struct device *dev,
+static ssize_t store_als_en(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t len)
{
struct lm3533_bl *bl = dev_get_drvdata(dev);
int ctrlbank = lm3533_bl_get_ctrlbank_id(bl);
- int als;
+ int enable;
u8 val;
u8 mask;
int ret;
- if (kstrtoint(buf, 0, &als))
- return -EINVAL;
-
- if (als != 0 && (als != ctrlbank + 1))
+ if (kstrtoint(buf, 0, &enable))
return -EINVAL;
mask = 1 << (2 * ctrlbank);
- if (als)
+ if (enable)
val = mask;
else
val = 0;
@@ -224,13 +221,15 @@ static ssize_t store_pwm(struct device *dev,
return len;
}
-static LM3533_ATTR_RW(als);
+static LM3533_ATTR_RO(als_channel);
+static LM3533_ATTR_RW(als_en);
static LM3533_ATTR_RO(id);
static LM3533_ATTR_RW(linear);
static LM3533_ATTR_RW(pwm);
static struct attribute *lm3533_bl_attributes[] = {
- &dev_attr_als.attr,
+ &dev_attr_als_channel.attr,
+ &dev_attr_als_en.attr,
&dev_attr_id.attr,
&dev_attr_linear.attr,
&dev_attr_pwm.attr,
@@ -244,7 +243,8 @@ static umode_t lm3533_bl_attr_is_visible(struct kobject *kobj,
struct lm3533_bl *bl = dev_get_drvdata(dev);
umode_t mode = attr->mode;
- if (attr = &dev_attr_als.attr) {
+ if (attr = &dev_attr_als_channel.attr ||
+ attr = &dev_attr_als_en.attr) {
if (!bl->lm3533->have_als)
mode = 0;
}
--
1.7.8.5
^ permalink raw reply related
* [PATCH 1/2] leds: lm3533: replace als attribute with als_channel and als_en
From: Johan Hovold @ 2012-05-22 10:05 UTC (permalink / raw)
To: Richard Purdie, Andrew Morton
Cc: Rob Landley, Florian Tobias Schandinat, linux-doc, linux-fbdev,
Jonathan Cameron, linux-kernel, Johan Hovold
Replace the als attribute with two separate attributes for selecting ALS
channel and enabling ALS-current-control mode.
This change is needed to reflect changes made to the ALS sub-driver
which now uses 0-indexed current output channels (rather than 1-indexed
ALS-mapper target sets).
Signed-off-by: Johan Hovold <jhovold@gmail.com>
---
.../ABI/testing/sysfs-class-led-driver-lm3533 | 19 +++-
drivers/leds/leds-lm3533.c | 98 +++++++++++++++-----
2 files changed, 87 insertions(+), 30 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-class-led-driver-lm3533 b/Documentation/ABI/testing/sysfs-class-led-driver-lm3533
index a9633fd..620ebb3 100644
--- a/Documentation/ABI/testing/sysfs-class-led-driver-lm3533
+++ b/Documentation/ABI/testing/sysfs-class-led-driver-lm3533
@@ -1,13 +1,20 @@
-What: /sys/class/leds/<led>/als
-Date: April 2012
+What: /sys/class/leds/<led>/als_channel
+Date: May 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
- Set the ALS-control mode (0, 2, 3), where
+ Set the ALS output channel to use as input in
+ ALS-current-control mode (1, 2), where
+
+ 1 - out_current1
+ 2 - out_current2
- 0 - disabled
- 2 - ALS-mapper 2
- 3 - ALS-mapper 3
+What: /sys/class/leds/<led>/als_en
+Date: May 2012
+KernelVersion: 3.5
+Contact: Johan Hovold <jhovold@gmail.com>
+Description:
+ Enable ALS-current-control mode (0, 1).
What: /sys/class/leds/<led>/falltime
What: /sys/class/leds/<led>/risetime
diff --git a/drivers/leds/leds-lm3533.c b/drivers/leds/leds-lm3533.c
index e968470..f56b6e7 100644
--- a/drivers/leds/leds-lm3533.c
+++ b/drivers/leds/leds-lm3533.c
@@ -27,8 +27,8 @@
#define LM3533_LVCTRLBANK_MAX 5
#define LM3533_LVCTRLBANK_COUNT 4
#define LM3533_RISEFALLTIME_MAX 7
-#define LM3533_ALS_LV_MIN 2
-#define LM3533_ALS_LV_MAX 3
+#define LM3533_ALS_CHANNEL_LV_MIN 1
+#define LM3533_ALS_CHANNEL_LV_MAX 2
#define LM3533_REG_CTRLBANK_BCONF_BASE 0x1b
#define LM3533_REG_PATTERN_ENABLE 0x28
@@ -39,8 +39,9 @@
#define LM3533_REG_PATTERN_STEP 0x10
-#define LM3533_REG_CTRLBANK_BCONF_MAPPING_MASK 0x04
-#define LM3533_REG_CTRLBANK_BCONF_ALS_MASK 0x03
+#define LM3533_REG_CTRLBANK_BCONF_MAPPING_MASK 0x04
+#define LM3533_REG_CTRLBANK_BCONF_ALS_EN_MASK 0x02
+#define LM3533_REG_CTRLBANK_BCONF_ALS_CHANNEL_MASK 0x01
#define LM3533_LED_FLAG_PATTERN_ENABLE 1
@@ -416,21 +417,14 @@ static ssize_t store_falltime(struct device *dev,
LM3533_REG_PATTERN_FALLTIME_BASE);
}
-/*
- * ALS-control setting:
- *
- * 0 - ALS disabled
- * 2 - ALS-mapper 2
- * 3 - ALS-mapper 3
- */
-static ssize_t show_als(struct device *dev,
+static ssize_t show_als_channel(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct led_classdev *led_cdev = dev_get_drvdata(dev);
struct lm3533_led *led = to_lm3533_led(led_cdev);
+ unsigned channel;
u8 reg;
u8 val;
- int als;
int ret;
reg = lm3533_led_get_lv_reg(led, LM3533_REG_CTRLBANK_BCONF_BASE);
@@ -438,32 +432,85 @@ static ssize_t show_als(struct device *dev,
if (ret)
return ret;
- als = val & LM3533_REG_CTRLBANK_BCONF_ALS_MASK;
+ channel = (val & LM3533_REG_CTRLBANK_BCONF_ALS_CHANNEL_MASK) + 1;
- return scnprintf(buf, PAGE_SIZE, "%d\n", als);
+ return scnprintf(buf, PAGE_SIZE, "%u\n", channel);
}
-static ssize_t store_als(struct device *dev,
+static ssize_t store_als_channel(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t len)
{
struct led_classdev *led_cdev = dev_get_drvdata(dev);
struct lm3533_led *led = to_lm3533_led(led_cdev);
- u8 als;
+ unsigned channel;
u8 reg;
+ u8 val;
u8 mask;
int ret;
- if (kstrtou8(buf, 0, &als))
+ if (kstrtouint(buf, 0, &channel))
return -EINVAL;
- if (als != 0 && (als < LM3533_ALS_LV_MIN || als > LM3533_ALS_LV_MAX))
+ if (channel < LM3533_ALS_CHANNEL_LV_MIN ||
+ channel > LM3533_ALS_CHANNEL_LV_MAX)
return -EINVAL;
reg = lm3533_led_get_lv_reg(led, LM3533_REG_CTRLBANK_BCONF_BASE);
- mask = LM3533_REG_CTRLBANK_BCONF_ALS_MASK;
+ mask = LM3533_REG_CTRLBANK_BCONF_ALS_CHANNEL_MASK;
+ val = channel - 1;
+
+ ret = lm3533_update(led->lm3533, reg, val, mask);
+ if (ret)
+ return ret;
+
+ return len;
+}
+
+static ssize_t show_als_en(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct led_classdev *led_cdev = dev_get_drvdata(dev);
+ struct lm3533_led *led = to_lm3533_led(led_cdev);
+ bool enable;
+ u8 reg;
+ u8 val;
+ int ret;
+
+ reg = lm3533_led_get_lv_reg(led, LM3533_REG_CTRLBANK_BCONF_BASE);
+ ret = lm3533_read(led->lm3533, reg, &val);
+ if (ret)
+ return ret;
- ret = lm3533_update(led->lm3533, reg, als, mask);
+ enable = val & LM3533_REG_CTRLBANK_BCONF_ALS_EN_MASK;
+
+ return scnprintf(buf, PAGE_SIZE, "%d\n", enable);
+}
+
+static ssize_t store_als_en(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct led_classdev *led_cdev = dev_get_drvdata(dev);
+ struct lm3533_led *led = to_lm3533_led(led_cdev);
+ unsigned enable;
+ u8 reg;
+ u8 mask;
+ u8 val;
+ int ret;
+
+ if (kstrtouint(buf, 0, &enable))
+ return -EINVAL;
+
+ reg = lm3533_led_get_lv_reg(led, LM3533_REG_CTRLBANK_BCONF_BASE);
+ mask = LM3533_REG_CTRLBANK_BCONF_ALS_EN_MASK;
+
+ if (enable)
+ val = mask;
+ else
+ val = 0;
+
+ ret = lm3533_update(led->lm3533, reg, val, mask);
if (ret)
return ret;
@@ -558,7 +605,8 @@ static ssize_t store_pwm(struct device *dev,
return len;
}
-static LM3533_ATTR_RW(als);
+static LM3533_ATTR_RW(als_channel);
+static LM3533_ATTR_RW(als_en);
static LM3533_ATTR_RW(falltime);
static LM3533_ATTR_RO(id);
static LM3533_ATTR_RW(linear);
@@ -566,7 +614,8 @@ static LM3533_ATTR_RW(pwm);
static LM3533_ATTR_RW(risetime);
static struct attribute *lm3533_led_attributes[] = {
- &dev_attr_als.attr,
+ &dev_attr_als_channel.attr,
+ &dev_attr_als_en.attr,
&dev_attr_falltime.attr,
&dev_attr_id.attr,
&dev_attr_linear.attr,
@@ -583,7 +632,8 @@ static umode_t lm3533_led_attr_is_visible(struct kobject *kobj,
struct lm3533_led *led = to_lm3533_led(led_cdev);
umode_t mode = attr->mode;
- if (attr = &dev_attr_als.attr) {
+ if (attr = &dev_attr_als_channel.attr ||
+ attr = &dev_attr_als_en.attr) {
if (!led->lm3533->have_als)
mode = 0;
}
--
1.7.8.5
^ permalink raw reply related
* Re: [PATCH] backlight: initialize struct backlight_properties properly
From: Dave Airlie @ 2012-05-22 9:25 UTC (permalink / raw)
To: Corentin Chary
Cc: Richard Purdie, Keith Packard, David Airlie, Matthew Garrett,
Florian Tobias Schandinat, Mark Brown, Tomi Valkeinen,
Mathieu Poirier, Dave Airlie, Arnd Bergmann, Lars-Peter Clausen,
Axel Lin, dri-devel, linux-kernel, platform-driver-x86,
linux-fbdev, patches, linux-omap
In-Reply-To: <1337585085-4891-1-git-send-email-corentin.chary@gmail.com>
On Mon, May 21, 2012 at 8:24 AM, Corentin Chary
<corentin.chary@gmail.com> wrote:
> In all these files, the .power field was never correctly initialized.
>
> Signed-off-by: Corentin Chary <corentin.chary@gmail.com>
> ---
> drivers/gpu/drm/i915/intel_panel.c | 1 +
> drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 1 +
I've taken these two hunks into drm-next.
Dave.
^ permalink raw reply
* Re: [PATCH] backlight: initialize struct backlight_properties properly
From: Jingoo Han @ 2012-05-22 0:07 UTC (permalink / raw)
To: 'Corentin Chary', 'Richard Purdie',
'Andrew Morton'
Cc: 'Keith Packard', 'David Airlie',
'Matthew Garrett', 'Florian Tobias Schandinat',
'Mark Brown', 'Tomi Valkeinen',
'Mathieu Poirier', 'Dave Airlie',
'Arnd Bergmann', 'Lars-Peter Clausen',
'Axel Lin', dri-devel, linux-kernel, platform-driver-x86,
linux-fbdev, patches, linux-omap, 'Jingoo Han'
In-Reply-To: <1337585085-4891-1-git-send-email-corentin.chary@gmail.com>
On Mon, May 21, 2012 at 04:25 PM +0000, Corentin Chary wrote:
>
> In all these files, the .power field was never correctly initialized.
>
> Signed-off-by: Corentin Chary <corentin.chary@gmail.com>
It looks good.
Best regards,
Jingoo Han
> ---
> drivers/gpu/drm/i915/intel_panel.c | 1 +
> drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 1 +
> drivers/platform/x86/toshiba_acpi.c | 1 +
> drivers/video/backlight/da903x_bl.c | 1 +
> drivers/video/backlight/pcf50633-backlight.c | 1 +
> drivers/video/backlight/wm831x_bl.c | 1 +
> drivers/video/omap2/displays/panel-acx565akm.c | 1 +
> 7 files changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c
> index 48177ec..ec4a1e0 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -342,6 +342,7 @@ int intel_panel_setup_backlight(struct drm_device *dev)
> else
> return -ENODEV;
>
> + memset(&props, 0, sizeof(props));
> props.type = BACKLIGHT_RAW;
> props.max_brightness = intel_panel_get_max_backlight(dev);
> dev_priv->backlight > diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> index 42db254..a0c8222 100644
> --- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> +++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> @@ -369,6 +369,7 @@ void radeon_legacy_backlight_init(struct radeon_encoder *radeon_encoder,
> goto error;
> }
>
> + memset(&props, 0, sizeof(props));
> props.max_brightness = MAX_RADEON_LEVEL;
> props.type = BACKLIGHT_RAW;
> bd = backlight_device_register("radeon_bl", &drm_connector->kdev,
> diff --git a/drivers/platform/x86/toshiba_acpi.c b/drivers/platform/x86/toshiba_acpi.c
> index bde32de..d680bb2 100644
> --- a/drivers/platform/x86/toshiba_acpi.c
> +++ b/drivers/platform/x86/toshiba_acpi.c
> @@ -1095,6 +1095,7 @@ static int __devinit toshiba_acpi_setup_backlight(struct toshiba_acpi_dev *dev)
> ret = get_tr_backlight_status(dev, &enabled);
> dev->tr_backlight_supported = !ret;
>
> + memset(&props, 0, sizeof(props));
> props.type = BACKLIGHT_PLATFORM;
> props.max_brightness = HCI_LCD_BRIGHTNESS_LEVELS - 1;
>
> diff --git a/drivers/video/backlight/da903x_bl.c b/drivers/video/backlight/da903x_bl.c
> index 30e1968..573c7ec 100644
> --- a/drivers/video/backlight/da903x_bl.c
> +++ b/drivers/video/backlight/da903x_bl.c
> @@ -136,6 +136,7 @@ static int da903x_backlight_probe(struct platform_device *pdev)
> da903x_write(data->da903x_dev, DA9034_WLED_CONTROL2,
> DA9034_WLED_ISET(pdata->output_current));
>
> + memset(&props, 0, sizeof(props));
> props.type = BACKLIGHT_RAW;
> props.max_brightness = max_brightness;
> bl = backlight_device_register(pdev->name, data->da903x_dev, data,
> diff --git a/drivers/video/backlight/pcf50633-backlight.c b/drivers/video/backlight/pcf50633-backlight.c
> index c65853c..c092159 100644
> --- a/drivers/video/backlight/pcf50633-backlight.c
> +++ b/drivers/video/backlight/pcf50633-backlight.c
> @@ -111,6 +111,7 @@ static int __devinit pcf50633_bl_probe(struct platform_device *pdev)
> if (!pcf_bl)
> return -ENOMEM;
>
> + memset(&bl_props, 0, sizeof(bl_props));
> bl_props.type = BACKLIGHT_RAW;
> bl_props.max_brightness = 0x3f;
> bl_props.power = FB_BLANK_UNBLANK;
> diff --git a/drivers/video/backlight/wm831x_bl.c b/drivers/video/backlight/wm831x_bl.c
> index 5d365de..9e5517a 100644
> --- a/drivers/video/backlight/wm831x_bl.c
> +++ b/drivers/video/backlight/wm831x_bl.c
> @@ -194,6 +194,7 @@ static int wm831x_backlight_probe(struct platform_device *pdev)
> data->current_brightness = 0;
> data->isink_reg = isink_reg;
>
> + memset(&props, 0, sizeof(props));
> props.type = BACKLIGHT_RAW;
> props.max_brightness = max_isel;
> bl = backlight_device_register("wm831x", &pdev->dev, data,
> diff --git a/drivers/video/omap2/displays/panel-acx565akm.c b/drivers/video/omap2/displays/panel-
> acx565akm.c
> index d26f37a..74e7cf0 100644
> --- a/drivers/video/omap2/displays/panel-acx565akm.c
> +++ b/drivers/video/omap2/displays/panel-acx565akm.c
> @@ -532,6 +532,7 @@ static int acx_panel_probe(struct omap_dss_device *dssdev)
>
> /*------- Backlight control --------*/
>
> + memset(&props, 0, sizeof(props));
> props.fb_blank = FB_BLANK_UNBLANK;
> props.power = FB_BLANK_UNBLANK;
> props.type = BACKLIGHT_RAW;
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] OMAPDSS: DSI: Support command mode interleaving during video mode blanking periods
From: Archit Taneja @ 2012-05-21 8:26 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1337348396.2607.19.camel@deskari>
On Friday 18 May 2012 07:09 PM, Tomi Valkeinen wrote:
> Hi,
>
> On Tue, 2012-05-15 at 11:32 +0530, Archit Taneja wrote:
>> 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 code in dsi_config_cmd_mode_interleaving() looks a bit long and
> confusing, but I don't think it's trivial to simplify it. There's just
> so many variables to consider.
There is a little optimisation done in the code to not calculate the
interleaving parameter for a blanking period which is not used for
interleaving. Checks like below are done for that:
if(!hsa_blanking_mode) {
...
}
if (!hfp_blanking_mode) {
...
}
...
We could remove this, as the computation is just done once and there
seems to be no side effects to write interleaving parameters for a
blanking period not used for interleaving. But it won't make much
function much simpler.
>
> In the future I think we should store the DSI configurations into
> memory, so that we don't need to parse the hardware registers to find
> out things like DSI timings.
Yes, I'll do this clean up sometime soon.
Archit
^ permalink raw reply
* [PATCH] backlight: initialize struct backlight_properties properly
From: Corentin Chary @ 2012-05-21 7:24 UTC (permalink / raw)
To: Richard Purdie
Cc: Corentin Chary, Keith Packard, David Airlie, Matthew Garrett,
Florian Tobias Schandinat, Mark Brown, Tomi Valkeinen,
Mathieu Poirier, Dave Airlie, Arnd Bergmann, Lars-Peter Clausen,
Axel Lin, dri-devel, linux-kernel, platform-driver-x86,
linux-fbdev, patches, linux-omap
In all these files, the .power field was never correctly initialized.
Signed-off-by: Corentin Chary <corentin.chary@gmail.com>
---
drivers/gpu/drm/i915/intel_panel.c | 1 +
drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 1 +
drivers/platform/x86/toshiba_acpi.c | 1 +
drivers/video/backlight/da903x_bl.c | 1 +
drivers/video/backlight/pcf50633-backlight.c | 1 +
drivers/video/backlight/wm831x_bl.c | 1 +
drivers/video/omap2/displays/panel-acx565akm.c | 1 +
7 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c
index 48177ec..ec4a1e0 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -342,6 +342,7 @@ int intel_panel_setup_backlight(struct drm_device *dev)
else
return -ENODEV;
+ memset(&props, 0, sizeof(props));
props.type = BACKLIGHT_RAW;
props.max_brightness = intel_panel_get_max_backlight(dev);
dev_priv->backlight diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
index 42db254..a0c8222 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
@@ -369,6 +369,7 @@ void radeon_legacy_backlight_init(struct radeon_encoder *radeon_encoder,
goto error;
}
+ memset(&props, 0, sizeof(props));
props.max_brightness = MAX_RADEON_LEVEL;
props.type = BACKLIGHT_RAW;
bd = backlight_device_register("radeon_bl", &drm_connector->kdev,
diff --git a/drivers/platform/x86/toshiba_acpi.c b/drivers/platform/x86/toshiba_acpi.c
index bde32de..d680bb2 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -1095,6 +1095,7 @@ static int __devinit toshiba_acpi_setup_backlight(struct toshiba_acpi_dev *dev)
ret = get_tr_backlight_status(dev, &enabled);
dev->tr_backlight_supported = !ret;
+ memset(&props, 0, sizeof(props));
props.type = BACKLIGHT_PLATFORM;
props.max_brightness = HCI_LCD_BRIGHTNESS_LEVELS - 1;
diff --git a/drivers/video/backlight/da903x_bl.c b/drivers/video/backlight/da903x_bl.c
index 30e1968..573c7ec 100644
--- a/drivers/video/backlight/da903x_bl.c
+++ b/drivers/video/backlight/da903x_bl.c
@@ -136,6 +136,7 @@ static int da903x_backlight_probe(struct platform_device *pdev)
da903x_write(data->da903x_dev, DA9034_WLED_CONTROL2,
DA9034_WLED_ISET(pdata->output_current));
+ memset(&props, 0, sizeof(props));
props.type = BACKLIGHT_RAW;
props.max_brightness = max_brightness;
bl = backlight_device_register(pdev->name, data->da903x_dev, data,
diff --git a/drivers/video/backlight/pcf50633-backlight.c b/drivers/video/backlight/pcf50633-backlight.c
index c65853c..c092159 100644
--- a/drivers/video/backlight/pcf50633-backlight.c
+++ b/drivers/video/backlight/pcf50633-backlight.c
@@ -111,6 +111,7 @@ static int __devinit pcf50633_bl_probe(struct platform_device *pdev)
if (!pcf_bl)
return -ENOMEM;
+ memset(&bl_props, 0, sizeof(bl_props));
bl_props.type = BACKLIGHT_RAW;
bl_props.max_brightness = 0x3f;
bl_props.power = FB_BLANK_UNBLANK;
diff --git a/drivers/video/backlight/wm831x_bl.c b/drivers/video/backlight/wm831x_bl.c
index 5d365de..9e5517a 100644
--- a/drivers/video/backlight/wm831x_bl.c
+++ b/drivers/video/backlight/wm831x_bl.c
@@ -194,6 +194,7 @@ static int wm831x_backlight_probe(struct platform_device *pdev)
data->current_brightness = 0;
data->isink_reg = isink_reg;
+ memset(&props, 0, sizeof(props));
props.type = BACKLIGHT_RAW;
props.max_brightness = max_isel;
bl = backlight_device_register("wm831x", &pdev->dev, data,
diff --git a/drivers/video/omap2/displays/panel-acx565akm.c b/drivers/video/omap2/displays/panel-acx565akm.c
index d26f37a..74e7cf0 100644
--- a/drivers/video/omap2/displays/panel-acx565akm.c
+++ b/drivers/video/omap2/displays/panel-acx565akm.c
@@ -532,6 +532,7 @@ static int acx_panel_probe(struct omap_dss_device *dssdev)
/*------- Backlight control --------*/
+ memset(&props, 0, sizeof(props));
props.fb_blank = FB_BLANK_UNBLANK;
props.power = FB_BLANK_UNBLANK;
props.type = BACKLIGHT_RAW;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v2 2/4] iio: add LM3533 ambient light sensor driver
From: Jonathan Cameron @ 2012-05-19 8:04 UTC (permalink / raw)
To: Johan Hovold
Cc: Jonathan Cameron, 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: <20120518175742.GA12894@localhost>
On 05/18/2012 06:57 PM, Johan Hovold wrote:
> On Fri, May 18, 2012 at 06:34:01PM +0100, Jonathan Cameron wrote:
>> On 05/18/2012 01:27 PM, Johan Hovold wrote:
>
> [...]
>
>>> I really think that this should remain a device specific attribute as I
>>> originally suggested. It's an integration parameter that needs to be set
>>> precisely depending on the actual hardware setup (which analog light
>>> sensor and other external components).
>> Then it shouldn't be exposed to userspace. If there is reason to vary
>> it from userspace then it is a calibration parameter and should be
>> treated like the other ones we have, if not it should be done from
>> dt or platform data.
>>>
>>> The lm3533 also supports two types of light sensors: pwm- and analog-
>>> output ones. The resistor select settings only applies when in analog
>>> mode as the input is always high impedance otherwise. Thus a generic
>>> attribute (such as calibscale or hardware gain) shouldn't be used as it
>>> will have no effect whatsoever in PWM-mode.
>>>
>>> I'm thus back at my original proposal, albeit with a different name (I
>>> think a lot of this discussion could have been avoided had I not
>>> misnamed the parameter "gain"):
>>>
>>> What: /sys/bus/iio/devices/iio:deviceX/r_select
>>> Description:
>>> Set the ALS internal pull-down resistor for analog input mode
>>> (1..127), such that,
>>>
>>> R_als = 200000 / r_select (ohm)
>>>
>>> This setting is ignored in PWM-mode (input is always high
>>> impedance in PWM-mode).
>>>
>>> I don't think much is gained from using ohm as the unit: it just adds
>>> complexity and the selected resistor setting will likely not match the
>>> input value anyway. It's better that the chip integrators have full
>>> control over which resistor setting is actually used so that it matches
>>> external components.
>> This smacks of something that should never be exposed to users.
>> I'd hide it away in platform data.
>
> Fair enough. I'll drop the sysfs param and submit a patch for mfd-next
> which adds r_select to the platform data.
>
cool. I'll review the rest of the patch with the assumption you'll do this.
Jonathan
^ permalink raw reply
* Re: [PATCH v2 2/4] iio: add LM3533 ambient light sensor driver
From: Johan Hovold @ 2012-05-18 17:57 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Johan Hovold, Jonathan Cameron, 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: <4FB68809.2010009@kernel.org>
On Fri, May 18, 2012 at 06:34:01PM +0100, Jonathan Cameron wrote:
> On 05/18/2012 01:27 PM, Johan Hovold wrote:
[...]
> > I really think that this should remain a device specific attribute as I
> > originally suggested. It's an integration parameter that needs to be set
> > precisely depending on the actual hardware setup (which analog light
> > sensor and other external components).
> Then it shouldn't be exposed to userspace. If there is reason to vary
> it from userspace then it is a calibration parameter and should be
> treated like the other ones we have, if not it should be done from
> dt or platform data.
> >
> > The lm3533 also supports two types of light sensors: pwm- and analog-
> > output ones. The resistor select settings only applies when in analog
> > mode as the input is always high impedance otherwise. Thus a generic
> > attribute (such as calibscale or hardware gain) shouldn't be used as it
> > will have no effect whatsoever in PWM-mode.
> >
> > I'm thus back at my original proposal, albeit with a different name (I
> > think a lot of this discussion could have been avoided had I not
> > misnamed the parameter "gain"):
> >
> > What: /sys/bus/iio/devices/iio:deviceX/r_select
> > Description:
> > Set the ALS internal pull-down resistor for analog input mode
> > (1..127), such that,
> >
> > R_als = 200000 / r_select (ohm)
> >
> > This setting is ignored in PWM-mode (input is always high
> > impedance in PWM-mode).
> >
> > I don't think much is gained from using ohm as the unit: it just adds
> > complexity and the selected resistor setting will likely not match the
> > input value anyway. It's better that the chip integrators have full
> > control over which resistor setting is actually used so that it matches
> > external components.
> This smacks of something that should never be exposed to users.
> I'd hide it away in platform data.
Fair enough. I'll drop the sysfs param and submit a patch for mfd-next
which adds r_select to the platform data.
Thanks,
Johan
^ permalink raw reply
* Re: [PATCH v2 2/4] iio: add LM3533 ambient light sensor driver
From: Jonathan Cameron @ 2012-05-18 17:34 UTC (permalink / raw)
To: Johan Hovold
Cc: Jonathan Cameron, 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: <20120518122725.GB20467@localhost>
On 05/18/2012 01:27 PM, Johan Hovold wrote:
> On Wed, May 16, 2012 at 03:21:14PM +0100, Jonathan Cameron wrote:
>> On 5/16/2012 2:05 PM, Johan Hovold wrote:
>>> On Tue, May 15, 2012 at 09:00:46PM +0100, Jonathan Cameron wrote:
>>>> On 05/15/2012 05:44 PM, Johan Hovold wrote:
>>>>> 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.
>>>> This is a generic element that really ought to just fit in with the
>>>> equivalent in sysfs-bus-iio for calibscan. It's a ratio, so it should
>>>> be unit free for starters.
>>>
>>> I'm starting to doubt that calibscale is really appropriate in this case.
>>>
>>> For starters, the description in sysfs-bus-iio doesn't really apply:
>>>
>>> "Hardware applied calibration scale factor. (assumed to fix
>>> production inaccuracies)."
>> Hmm.. if you really don't like this, Michael Hennerich had a case
>> where this made even less sense, so we now have hardwaregain.
>> Use that if you like...
>
> I really think that this should remain a device specific attribute as I
> originally suggested. It's an integration parameter that needs to be set
> precisely depending on the actual hardware setup (which analog light
> sensor and other external components).
Then it shouldn't be exposed to userspace. If there is reason to vary
it from userspace then it is a calibration parameter and should be
treated like the other ones we have, if not it should be done from
dt or platform data.
>
> The lm3533 also supports two types of light sensors: pwm- and analog-
> output ones. The resistor select settings only applies when in analog
> mode as the input is always high impedance otherwise. Thus a generic
> attribute (such as calibscale or hardware gain) shouldn't be used as it
> will have no effect whatsoever in PWM-mode.
>
> I'm thus back at my original proposal, albeit with a different name (I
> think a lot of this discussion could have been avoided had I not
> misnamed the parameter "gain"):
>
> What: /sys/bus/iio/devices/iio:deviceX/r_select
> Description:
> Set the ALS internal pull-down resistor for analog input mode
> (1..127), such that,
>
> R_als = 200000 / r_select (ohm)
>
> This setting is ignored in PWM-mode (input is always high
> impedance in PWM-mode).
>
> I don't think much is gained from using ohm as the unit: it just adds
> complexity and the selected resistor setting will likely not match the
> input value anyway. It's better that the chip integrators have full
> control over which resistor setting is actually used so that it matches
> external components.
This smacks of something that should never be exposed to users.
I'd hide it away in platform data.
>
>
>>> The resistor setting of the lm3533 is about fitting an external analog
>>> light sensor to the lm3533 als interface (which is basically just an adc
>>> with some extra logic), that is, it is used to match the output current
>>> of the chosen sensor so that the ADC measures 2V at full LUX.
>>>
>>> It's not a setting to calibrate "inaccuracies", but rather an
>>> integration parameter that is set once when the characteristics of the
>>> light sensor is known. (Sure, it could be used later to increase
>>> sensitivity as well, but the main purpose is to fit a new light sensor
>>> to a generic input interface.)
>>>
>>>>> [...]
>>>>>
>>>>>>>>> +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?
>>>> Nope, because they don't tell a general userspace application what is
>>>> going on. Without hysterisis attributes it has no way of knowing there
>>>> is hysterisis present.
>>>
>>> Well an application could simply look at the difference between raising
>>> and falling to determine the hysteresis?
>> Only if it knows it has your sensor. For other sensors it could be
>> completely separate or not present. If the parameter is missing
>> assumption is that there is no hysterisis.
>>>
>>> It gets more complicated as the lm3533 allow the raising threshold to
>>> be lower than the falling. It appears the device is using whichever
>>> register is lower for the falling threshold. I guess I should compensate
>>> for this in the driver.
>> That's nasty.
>>>
>>> Furthermore, you can define threshold 1 to be lower than threshold 0,
>>> effectively preventing zone 1 to be reached. In this case, dropping
>>> below thres1_falling gives zone 0, and raising above thres1_raising gives
>>> zone 2. In particular, no threshold event is generated when
>>> thres0_{falling/raising} is passed in either direction. But perhaps this
>>> should just be documented as a feature/quirk of the device.
>> Seems sensible...
>>>
>>>> Feel free to make them read only though.
>>>
>>> So you're suggesting something like:
>>>
>>> events/in_illuminance0_threshY_falling_value
>>> events/in_illuminance0_threshY_raising_value
>>> events/in_illuminance0_threshY_hysteresis
>>>
>>> where hysteresis is a read-only attribute whose value is
>>>
>>> threshY_raising_value - threshY_falling_value
>> yes. Annoying it may be but it matches existing interface.
>
> I'm posting a v4 which includes the above proposal for resistor select.
> I've also added the hysteresis attributes as requested and fixed the
> device threshold quirkiness mentioned above (the device is using
> whichever register value is smaller as the falling threshold).
cool. I'll take a look soon.
>
> Thanks,
> Johan
^ permalink raw reply
* Re: [PATCH] OMAPDSS: DSI: Support command mode interleaving during video mode blanking periods
From: Tomi Valkeinen @ 2012-05-18 13:39 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1337061738-32488-1-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2381 bytes --]
Hi,
On Tue, 2012-05-15 at 11:32 +0530, Archit Taneja wrote:
> 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 code in dsi_config_cmd_mode_interleaving() looks a bit long and
confusing, but I don't think it's trivial to simplify it. There's just
so many variables to consider.
In the future I think we should store the DSI configurations into
memory, so that we don't need to parse the hardware registers to find
out things like DSI timings.
I'll apply this, as it's very nice to have at least minimal interleaving
support.
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-18 12:27 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Johan Hovold, Jonathan Cameron, 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: <4FB3B7DA.5050306@cam.ac.uk>
On Wed, May 16, 2012 at 03:21:14PM +0100, Jonathan Cameron wrote:
> On 5/16/2012 2:05 PM, Johan Hovold wrote:
> > On Tue, May 15, 2012 at 09:00:46PM +0100, Jonathan Cameron wrote:
> >> On 05/15/2012 05:44 PM, Johan Hovold wrote:
> >>> 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.
> >> This is a generic element that really ought to just fit in with the
> >> equivalent in sysfs-bus-iio for calibscan. It's a ratio, so it should
> >> be unit free for starters.
> >
> > I'm starting to doubt that calibscale is really appropriate in this case.
> >
> > For starters, the description in sysfs-bus-iio doesn't really apply:
> >
> > "Hardware applied calibration scale factor. (assumed to fix
> > production inaccuracies)."
> Hmm.. if you really don't like this, Michael Hennerich had a case
> where this made even less sense, so we now have hardwaregain.
> Use that if you like...
I really think that this should remain a device specific attribute as I
originally suggested. It's an integration parameter that needs to be set
precisely depending on the actual hardware setup (which analog light
sensor and other external components).
The lm3533 also supports two types of light sensors: pwm- and analog-
output ones. The resistor select settings only applies when in analog
mode as the input is always high impedance otherwise. Thus a generic
attribute (such as calibscale or hardware gain) shouldn't be used as it
will have no effect whatsoever in PWM-mode.
I'm thus back at my original proposal, albeit with a different name (I
think a lot of this discussion could have been avoided had I not
misnamed the parameter "gain"):
What: /sys/bus/iio/devices/iio:deviceX/r_select
Description:
Set the ALS internal pull-down resistor for analog input mode
(1..127), such that,
R_als = 200000 / r_select (ohm)
This setting is ignored in PWM-mode (input is always high
impedance in PWM-mode).
I don't think much is gained from using ohm as the unit: it just adds
complexity and the selected resistor setting will likely not match the
input value anyway. It's better that the chip integrators have full
control over which resistor setting is actually used so that it matches
external components.
> > The resistor setting of the lm3533 is about fitting an external analog
> > light sensor to the lm3533 als interface (which is basically just an adc
> > with some extra logic), that is, it is used to match the output current
> > of the chosen sensor so that the ADC measures 2V at full LUX.
> >
> > It's not a setting to calibrate "inaccuracies", but rather an
> > integration parameter that is set once when the characteristics of the
> > light sensor is known. (Sure, it could be used later to increase
> > sensitivity as well, but the main purpose is to fit a new light sensor
> > to a generic input interface.)
> >
> >>> [...]
> >>>
> >>>>>>> +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?
> >> Nope, because they don't tell a general userspace application what is
> >> going on. Without hysterisis attributes it has no way of knowing there
> >> is hysterisis present.
> >
> > Well an application could simply look at the difference between raising
> > and falling to determine the hysteresis?
> Only if it knows it has your sensor. For other sensors it could be
> completely separate or not present. If the parameter is missing
> assumption is that there is no hysterisis.
> >
> > It gets more complicated as the lm3533 allow the raising threshold to
> > be lower than the falling. It appears the device is using whichever
> > register is lower for the falling threshold. I guess I should compensate
> > for this in the driver.
> That's nasty.
> >
> > Furthermore, you can define threshold 1 to be lower than threshold 0,
> > effectively preventing zone 1 to be reached. In this case, dropping
> > below thres1_falling gives zone 0, and raising above thres1_raising gives
> > zone 2. In particular, no threshold event is generated when
> > thres0_{falling/raising} is passed in either direction. But perhaps this
> > should just be documented as a feature/quirk of the device.
> Seems sensible...
> >
> >> Feel free to make them read only though.
> >
> > So you're suggesting something like:
> >
> > events/in_illuminance0_threshY_falling_value
> > events/in_illuminance0_threshY_raising_value
> > events/in_illuminance0_threshY_hysteresis
> >
> > where hysteresis is a read-only attribute whose value is
> >
> > threshY_raising_value - threshY_falling_value
> yes. Annoying it may be but it matches existing interface.
I'm posting a v4 which includes the above proposal for resistor select.
I've also added the hysteresis attributes as requested and fixed the
device threshold quirkiness mentioned above (the device is using
whichever register value is smaller as the falling threshold).
Thanks,
Johan
^ permalink raw reply
* [PATCH for v3.4] fbdev: sh_mobile_lcdc: Don't confuse line size with pitch
From: Laurent Pinchart @ 2012-05-18 8:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Florian Tobias Schandinat, LKML, linux-fbdev
When using the MERAM the LCDC line size needs to be programmed with a
MERAM-specific value different than the real frame buffer pitch. Fix it.
Reported-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/sh_mobile_lcdcfb.c | 5 +++--
drivers/video/sh_mobile_lcdcfb.h | 1 +
2 files changed, 4 insertions(+), 2 deletions(-)
Hi Linus,
Could you please apply this patch to v3.4-rc ? I apologize for pushing it this
late, but this is a fix for a 3.4 regression that has only been discovered now
and breaks an important use case (fbcon on SH Mobile).
Due to the little time left before v3.4 Florian has asked me to send you the
patch directly instead of pushing it through his tree.
diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index 7a0b301..e672698 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -758,7 +758,7 @@ static void __sh_mobile_lcdc_start(struct sh_mobile_lcdc_priv *priv)
}
lcdc_write_chan(ch, LDDFR, tmp);
- lcdc_write_chan(ch, LDMLSR, ch->pitch);
+ lcdc_write_chan(ch, LDMLSR, ch->line_size);
lcdc_write_chan(ch, LDSA1R, ch->base_addr_y);
if (ch->format->yuv)
lcdc_write_chan(ch, LDSA2R, ch->base_addr_c);
@@ -847,6 +847,7 @@ static int sh_mobile_lcdc_start(struct sh_mobile_lcdc_priv *priv)
ch->base_addr_y = ch->dma_handle;
ch->base_addr_c = ch->base_addr_y + ch->xres * ch->yres_virtual;
+ ch->line_size = ch->pitch;
/* Enable MERAM if possible. */
if (mdev = NULL || mdev->ops = NULL ||
@@ -882,7 +883,7 @@ static int sh_mobile_lcdc_start(struct sh_mobile_lcdc_priv *priv)
meram = mdev->ops->meram_register(mdev, ch->cfg->meram_cfg,
ch->pitch, ch->yres, pixelformat,
- &ch->pitch);
+ &ch->line_size);
if (!IS_ERR(meram)) {
mdev->ops->meram_update(mdev, meram,
ch->base_addr_y, ch->base_addr_c,
diff --git a/drivers/video/sh_mobile_lcdcfb.h b/drivers/video/sh_mobile_lcdcfb.h
index da1c26e..5c3bddd 100644
--- a/drivers/video/sh_mobile_lcdcfb.h
+++ b/drivers/video/sh_mobile_lcdcfb.h
@@ -84,6 +84,7 @@ struct sh_mobile_lcdc_chan {
unsigned long base_addr_y;
unsigned long base_addr_c;
+ unsigned int line_size;
int (*notify)(struct sh_mobile_lcdc_chan *ch,
enum sh_mobile_lcdc_entity_event event,
--
Regards,
Laurent Pinchart
^ permalink raw reply related
* Re: [PULL for v3.4] SH Mobile LCDC fix
From: Laurent Pinchart @ 2012-05-18 8:57 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <26224047.6PR9YZjWoc@avalon>
Hi Florian,
On Friday 18 May 2012 01:39:19 Florian Tobias Schandinat wrote:
> On 05/17/2012 10:23 PM, Laurent Pinchart wrote:
> > Hi Florian,
> >
> > Is it still possible for the following patch to go to v3.4 ? I've only
> > realized now that MERAM support was broken in some use cases (one of them
> > being fbcon) due to a v3.4-rc regression - thanks to Guennadi Liakhovetski
> > for reporting this.
>
> Umm, I don't like last minute stuff, but this is important enough. BUT...
I don't like it either, I'll add fbcon to my test cases for the future.
> > If this is too late for v3.4 please let me know and I'll CC stable on the
> > patch and resend a pull request for v3.5.
> >
> > The following changes since commit
5e7b911f9a3e582635801675b7fe935b16cd4af5:
> > drivers/video: fsl-diu-fb: don't initialize the THRESHOLDS registers
> >
> > (2012-05-13 13:08:56 +0000)
>
> ...how am I supposed to merge this? It's based on top of all the stuff
> that I plan to ask Linus to pull during the merge window and AFAIK there
> is no way to merge only upper parts of branches. I could cherry-pick it
> but that wouldn't look like a merge or a patch I applied.
Oops, my bad, sorry.
> As this is only a single patch and not much time left, I'd suggest you
> send it directly to Linus (as a patch) with my Ack added to it. Oh and
> make sure to mention that this fixes a regression.
Sure, I'll do that.
Thank you.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PULL for v3.4] SH Mobile LCDC fix
From: Florian Tobias Schandinat @ 2012-05-18 1:39 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <26224047.6PR9YZjWoc@avalon>
Hi Laurent,
On 05/17/2012 10:23 PM, Laurent Pinchart wrote:
> Hi Florian,
>
> Is it still possible for the following patch to go to v3.4 ? I've only
> realized now that MERAM support was broken in some use cases (one of them
> being fbcon) due to a v3.4-rc regression - thanks to Guennadi Liakhovetski for
> reporting this.
Umm, I don't like last minute stuff, but this is important enough. BUT...
>
> If this is too late for v3.4 please let me know and I'll CC stable on the
> patch and resend a pull request for v3.5.
>
> The following changes since commit 5e7b911f9a3e582635801675b7fe935b16cd4af5:
>
> drivers/video: fsl-diu-fb: don't initialize the THRESHOLDS registers
> (2012-05-13 13:08:56 +0000)
...how am I supposed to merge this? It's based on top of all the stuff
that I plan to ask Linus to pull during the merge window and AFAIK there
is no way to merge only upper parts of branches. I could cherry-pick it
but that wouldn't look like a merge or a patch I applied.
As this is only a single patch and not much time left, I'd suggest you
send it directly to Linus (as a patch) with my Ack added to it. Oh and
make sure to mention that this fixes a regression.
Thanks,
Florian Tobias Schandinat
>
> are available in the git repository at:
> git://linuxtv.org/pinchartl/fbdev.git fixes
>
> Laurent Pinchart (1):
> fbdev: sh_mobile_lcdc: Don't confuse line size with pitch
>
> drivers/video/sh_mobile_lcdcfb.c | 5 +++--
> drivers/video/sh_mobile_lcdcfb.h | 1 +
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
^ permalink raw reply
* [PULL for v3.4] SH Mobile LCDC fix
From: Laurent Pinchart @ 2012-05-17 22:23 UTC (permalink / raw)
To: linux-fbdev
Hi Florian,
Is it still possible for the following patch to go to v3.4 ? I've only
realized now that MERAM support was broken in some use cases (one of them
being fbcon) due to a v3.4-rc regression - thanks to Guennadi Liakhovetski for
reporting this.
If this is too late for v3.4 please let me know and I'll CC stable on the
patch and resend a pull request for v3.5.
The following changes since commit 5e7b911f9a3e582635801675b7fe935b16cd4af5:
drivers/video: fsl-diu-fb: don't initialize the THRESHOLDS registers
(2012-05-13 13:08:56 +0000)
are available in the git repository at:
git://linuxtv.org/pinchartl/fbdev.git fixes
Laurent Pinchart (1):
fbdev: sh_mobile_lcdc: Don't confuse line size with pitch
drivers/video/sh_mobile_lcdcfb.c | 5 +++--
drivers/video/sh_mobile_lcdcfb.h | 1 +
2 files changed, 4 insertions(+), 2 deletions(-)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes
From: Hans Verkuil @ 2012-05-17 7:53 UTC (permalink / raw)
To: Jun Nie
Cc: Guennadi Liakhovetski, Laurent Pinchart, Daniel Vetter,
Tomasz Stanislawski, linux-fbdev, Sakari Ailus, Pawel Osciak,
Magnus Damm, Marcus Lorentzon, dri-devel, Alexander Deucher,
Rob Clark, linux-media, Marek Szyprowski
In-Reply-To: <CAGA24M+OEwi-ayBrXcMPg5PzndRF4mSr2dOOQAxhDCu6ShZLjQ@mail.gmail.com>
On Thu May 17 2012 04:46:37 Jun Nie wrote:
> Is there any discussion on HDCP on the summit? It is tightly
> coupled with HDMI and DVI and should be managed together with the
> transmitter. But there is not code to handle HDCP in DRM/FB/V4L in
> latest kernel. Any thoughts on HDCP? Or you guys think there is risk
> to support it in kernel? Thanks for your comments!
There is no risk to support it in the kernel, the risk is all for the
implementer (usually by having to lock down the system preventing access
to the box). You'd better read the HDCP license very carefully before deciding
to use HDCP under linux!
I'm working on V4L HDMI receivers and transmitters myself, but not on HDCP.
But I'd be happy to review/comment on proposals for adding HDCP support.
Note that there is very little work to be done to add this for simple
receivers and transmitters. The hard part will be supporting repeaters.
For simple receivers all you need in V4L2 is a flag telling you that the
received video was encrypted and for a transmitter I think you just need a
control to turn encryption on or off (AFAIK, I'd have to verify that statement
regarding the transmitter to be 100% certain). All the actual encryption and
decryption is handled by the receiver/transmitter hardware, at least on the
hardware that I have seen.
Repeaters are a lot harder as you have to handle key exchanges. I don't know
off-hand what that would involve API-wise in V4L2.
Regards,
Hans
^ permalink raw reply
* Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes
From: Jun Nie @ 2012-05-17 2:46 UTC (permalink / raw)
To: Guennadi Liakhovetski, Laurent Pinchart
Cc: Daniel Vetter, Tomasz Stanislawski, linux-fbdev, Sakari Ailus,
Pawel Osciak, Magnus Damm, Marcus Lorentzon, dri-devel,
Alexander Deucher, Rob Clark, linux-media, Marek Szyprowski
In-Reply-To: <Pine.LNX.4.64.1202201633100.2836@axis700.grange>
Is there any discussion on HDCP on the summit? It is tightly
coupled with HDMI and DVI and should be managed together with the
transmitter. But there is not code to handle HDCP in DRM/FB/V4L in
latest kernel. Any thoughts on HDCP? Or you guys think there is risk
to support it in kernel? Thanks for your comments!
Jun
^ permalink raw reply
* Re: [PATCH v2 2/4] iio: add LM3533 ambient light sensor driver
From: Jonathan Cameron @ 2012-05-16 14:21 UTC (permalink / raw)
To: Johan Hovold
Cc: Jonathan Cameron, 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: <20120516130507.GA10774@localhost>
On 5/16/2012 2:05 PM, Johan Hovold wrote:
> On Tue, May 15, 2012 at 09:00:46PM +0100, Jonathan Cameron wrote:
>> On 05/15/2012 05:44 PM, Johan Hovold wrote:
>>> 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.
>> This is a generic element that really ought to just fit in with the
>> equivalent in sysfs-bus-iio for calibscan. It's a ratio, so it should
>> be unit free for starters.
>
> I'm starting to doubt that calibscale is really appropriate in this case.
>
> For starters, the description in sysfs-bus-iio doesn't really apply:
>
> "Hardware applied calibration scale factor. (assumed to fix
> production inaccuracies)."
Hmm.. if you really don't like this, Michael Hennerich had a case
where this made even less sense, so we now have hardwaregain.
Use that if you like...
>
> The resistor setting of the lm3533 is about fitting an external analog
> light sensor to the lm3533 als interface (which is basically just an adc
> with some extra logic), that is, it is used to match the output current
> of the chosen sensor so that the ADC measures 2V at full LUX.
>
> It's not a setting to calibrate "inaccuracies", but rather an
> integration parameter that is set once when the characteristics of the
> light sensor is known. (Sure, it could be used later to increase
> sensitivity as well, but the main purpose is to fit a new light sensor
> to a generic input interface.)
>
>>> [...]
>>>
>>>>>>> +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?
>> Nope, because they don't tell a general userspace application what is
>> going on. Without hysterisis attributes it has no way of knowing there
>> is hysterisis present.
>
> Well an application could simply look at the difference between raising
> and falling to determine the hysteresis?
Only if it knows it has your sensor. For other sensors it could be
completely separate or not present. If the parameter is missing
assumption is that there is no hysterisis.
>
> It gets more complicated as the lm3533 allow the raising threshold to
> be lower than the falling. It appears the device is using whichever
> register is lower for the falling threshold. I guess I should compensate
> for this in the driver.
That's nasty.
>
> Furthermore, you can define threshold 1 to be lower than threshold 0,
> effectively preventing zone 1 to be reached. In this case, dropping
> below thres1_falling gives zone 0, and raising above thres1_raising gives
> zone 2. In particular, no threshold event is generated when
> thres0_{falling/raising} is passed in either direction. But perhaps this
> should just be documented as a feature/quirk of the device.
Seems sensible...
>
>> Feel free to make them read only though.
>
> So you're suggesting something like:
>
> events/in_illuminance0_threshY_falling_value
> events/in_illuminance0_threshY_raising_value
> events/in_illuminance0_threshY_hysteresis
>
> where hysteresis is a read-only attribute whose value is
>
> threshY_raising_value - threshY_falling_value
yes. Annoying it may be but it matches existing interface.
>
>>>>> 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).
>> Good point. Nasty little device to write an interface for :)
>
> Indeed. Thanks for appreciating that. ;)
>
>>>>> 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. ]
>> On that, just to reiterate, to have anything generalizable, userspace
>> needs to know that hysterisis exists on the individual thresholds
>> (though it is clearly a function of the neighbouring one).
>
> See my comments above.
>
> 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