* Re: Introduce a new helper framework for buffer synchronization
From: Daniel Vetter @ 2013-05-20 21:30 UTC (permalink / raw)
To: Inki Dae
Cc: Rob Clark, linux-fbdev, DRI mailing list, Kyungmin Park,
myungjoo.ham, YoungJun Cho, linux-arm-kernel@lists.infradead.org,
linux-media@vger.kernel.org
In-Reply-To: <20130520211304.GV12292@phenom.ffwll.local>
On Mon, May 20, 2013 at 11:13:04PM +0200, Daniel Vetter wrote:
> On Sat, May 18, 2013 at 03:47:43PM +0900, Inki Dae wrote:
> > 2013/5/15 Rob Clark <robdclark@gmail.com>
> >
> > > On Wed, May 15, 2013 at 1:19 AM, Inki Dae <inki.dae@samsung.com> wrote:
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: Rob Clark [mailto:robdclark@gmail.com]
> > > >> Sent: Tuesday, May 14, 2013 10:39 PM
> > > >> To: Inki Dae
> > > >> Cc: linux-fbdev; DRI mailing list; Kyungmin Park; myungjoo.ham; YoungJun
> > > >> Cho; linux-arm-kernel@lists.infradead.org; linux-media@vger.kernel.org
> > > >> Subject: Re: Introduce a new helper framework for buffer synchronization
> > > >>
> > > >> On Mon, May 13, 2013 at 10:52 PM, Inki Dae <inki.dae@samsung.com>
> > > wrote:
> > > >> >> well, for cache management, I think it is a better idea.. I didn't
> > > >> >> really catch that this was the motivation from the initial patch, but
> > > >> >> maybe I read it too quickly. But cache can be decoupled from
> > > >> >> synchronization, because CPU access is not asynchronous. For
> > > >> >> userspace/CPU access to buffer, you should:
> > > >> >>
> > > >> >> 1) wait for buffer
> > > >> >> 2) prepare-access
> > > >> >> 3) ... do whatever cpu access to buffer ...
> > > >> >> 4) finish-access
> > > >> >> 5) submit buffer for new dma-operation
> > > >> >>
> > > >> >
> > > >> >
> > > >> > For data flow from CPU to DMA device,
> > > >> > 1) wait for buffer
> > > >> > 2) prepare-access (dma_buf_begin_cpu_access)
> > > >> > 3) cpu access to buffer
> > > >> >
> > > >> >
> > > >> > For data flow from DMA device to CPU
> > > >> > 1) wait for buffer
> > > >>
> > > >> Right, but CPU access isn't asynchronous (from the point of view of
> > > >> the CPU), so there isn't really any wait step at this point. And if
> > > >> you do want the CPU to be able to signal a fence from userspace for
> > > >> some reason, you probably what something file/fd based so the
> > > >> refcnting/cleanup when process dies doesn't leave some pending DMA
> > > >> action wedged. But I don't really see the point of that complexity
> > > >> when the CPU access isn't asynchronous in the first place.
> > > >>
> > > >
> > > > There was my missing comments, please see the below sequence.
> > > >
> > > > For data flow from CPU to DMA device and then from DMA device to CPU,
> > > > 1) wait for buffer <- at user side - ioctl(fd, DMA_BUF_GET_FENCE, ...)
> > > > - including prepare-access (dma_buf_begin_cpu_access)
> > > > 2) cpu access to buffer
> > > > 3) wait for buffer <- at device driver
> > > > - but CPU is already accessing the buffer so blocked.
> > > > 4) signal <- at user side - ioctl(fd, DMA_BUF_PUT_FENCE, ...)
> > > > 5) the thread, blocked at 3), is waked up by 4).
> > > > - and then finish-access (dma_buf_end_cpu_access)
> > >
> > > right, I understand you can have background threads, etc, in
> > > userspace. But there are already plenty of synchronization primitives
> > > that can be used for cpu->cpu synchronization, either within the same
> > > process or between multiple processes. For cpu access, even if it is
> > > handled by background threads/processes, I think it is better to use
> > > the traditional pthreads or unix synchronization primitives. They
> > > have existed forever, they are well tested, and they work.
> > >
> > > So while it seems nice and orthogonal/clean to couple cache and
> > > synchronization and handle dma->cpu and cpu->cpu and cpu->dma in the
> > > same generic way, but I think in practice we have to make things more
> > > complex than they otherwise need to be to do this. Otherwise I think
> > > we'll be having problems with badly behaved or crashing userspace.
> > >
> > >
> > Right, this is very important. I think it's not esay to solve this
> > issue. Aand at least for ARM based embedded system, such feature is useful
> > to us; coupling cache operation and buffer synchronization. I'd like to
> > collect other opinions and advices to solve this issue.
>
> Maybe we have a bit a misunderstanding here. The kernel really should take
> care of sync and cache coherency, and I agree that with the current
> dma_buf code (and the proposed fences) that part is still a bit hazy. But
> the kernel should not allow userspace to block access to a buffer until
> userspace is done. It should only sync with any oustanding fences and
> flush buffers before that userspace access happens.
>
> Then the kernel would again flush caches on the next dma access (which
> hopefully is only started once userspace completed access). Atm this isn't
> possible in an efficient way since the dma_buf api only exposes map/unmap
> attachment and not a function to just sync an existing mapping like
> dma_sync_single_for_device. I guess we should add a
> dma_buf_sync_attachment interface for that - we already have range-based
> cpu sync support with the begin/end_cpu_access interfaces.
I think my mail here was a bit unclear, so let me try to rephrase.
Re-reading through part of this discussion I think you raise some good
shortcomings of the current dma_buf interfaces and the proposed fence
patches. But I think we should address the individual pieces bit-by-bit.
On a quick survey I see a few parts to what you're trying to solve:
- More efficient cache coherency management. I think we already have all
required interfaces for efficient cpu-side access with
begin/end_cpu_access. So I think we only need a device-side dma sync
mechanism to be able to flush cpu caches after userspace/cpu access has
completed (before the next dma op).
- More efficient mmap handling. The current dma_buf mmap support is
explicitly designed as something simply, but probably dead-slow for
last-resort fallback ops. I'm not sure whether we should fix this up and
extend with special ioctls. But the current coherency interface should
be good enough for you to write an efficient private mmap implementation
for exynos drm.
- Integration of fence syncing into dma_buf. Imo we should have a
per-attachment mode which decides whether map/unmap (and the new sync)
should wait for fences or whether the driver takes care of syncing
through the new fence framework itself (for direct hw sync). Imo cpu
access should also have such a flag. I guess in both cases we should
sync by default.
- cpu/cpu sync additions to dma_buf. Like I've said, I'm not sold at all
on this idea. I think it would be best if we try to fix up all the other
current shortcomings first though and then take a fresh look at this
issue here.
Have I missed or misunderstood something?
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* Re: Introduce a new helper framework for buffer synchronization
From: Daniel Vetter @ 2013-05-20 21:13 UTC (permalink / raw)
To: Inki Dae
Cc: Rob Clark, linux-fbdev, DRI mailing list, Kyungmin Park,
myungjoo.ham, YoungJun Cho, linux-arm-kernel@lists.infradead.org,
linux-media@vger.kernel.org
In-Reply-To: <CAAQKjZP37koEPob6yqpn-WxxTh3+O=twyvRzDiEhVJTD8BxQzw@mail.gmail.com>
On Sat, May 18, 2013 at 03:47:43PM +0900, Inki Dae wrote:
> 2013/5/15 Rob Clark <robdclark@gmail.com>
>
> > On Wed, May 15, 2013 at 1:19 AM, Inki Dae <inki.dae@samsung.com> wrote:
> > >
> > >
> > >> -----Original Message-----
> > >> From: Rob Clark [mailto:robdclark@gmail.com]
> > >> Sent: Tuesday, May 14, 2013 10:39 PM
> > >> To: Inki Dae
> > >> Cc: linux-fbdev; DRI mailing list; Kyungmin Park; myungjoo.ham; YoungJun
> > >> Cho; linux-arm-kernel@lists.infradead.org; linux-media@vger.kernel.org
> > >> Subject: Re: Introduce a new helper framework for buffer synchronization
> > >>
> > >> On Mon, May 13, 2013 at 10:52 PM, Inki Dae <inki.dae@samsung.com>
> > wrote:
> > >> >> well, for cache management, I think it is a better idea.. I didn't
> > >> >> really catch that this was the motivation from the initial patch, but
> > >> >> maybe I read it too quickly. But cache can be decoupled from
> > >> >> synchronization, because CPU access is not asynchronous. For
> > >> >> userspace/CPU access to buffer, you should:
> > >> >>
> > >> >> 1) wait for buffer
> > >> >> 2) prepare-access
> > >> >> 3) ... do whatever cpu access to buffer ...
> > >> >> 4) finish-access
> > >> >> 5) submit buffer for new dma-operation
> > >> >>
> > >> >
> > >> >
> > >> > For data flow from CPU to DMA device,
> > >> > 1) wait for buffer
> > >> > 2) prepare-access (dma_buf_begin_cpu_access)
> > >> > 3) cpu access to buffer
> > >> >
> > >> >
> > >> > For data flow from DMA device to CPU
> > >> > 1) wait for buffer
> > >>
> > >> Right, but CPU access isn't asynchronous (from the point of view of
> > >> the CPU), so there isn't really any wait step at this point. And if
> > >> you do want the CPU to be able to signal a fence from userspace for
> > >> some reason, you probably what something file/fd based so the
> > >> refcnting/cleanup when process dies doesn't leave some pending DMA
> > >> action wedged. But I don't really see the point of that complexity
> > >> when the CPU access isn't asynchronous in the first place.
> > >>
> > >
> > > There was my missing comments, please see the below sequence.
> > >
> > > For data flow from CPU to DMA device and then from DMA device to CPU,
> > > 1) wait for buffer <- at user side - ioctl(fd, DMA_BUF_GET_FENCE, ...)
> > > - including prepare-access (dma_buf_begin_cpu_access)
> > > 2) cpu access to buffer
> > > 3) wait for buffer <- at device driver
> > > - but CPU is already accessing the buffer so blocked.
> > > 4) signal <- at user side - ioctl(fd, DMA_BUF_PUT_FENCE, ...)
> > > 5) the thread, blocked at 3), is waked up by 4).
> > > - and then finish-access (dma_buf_end_cpu_access)
> >
> > right, I understand you can have background threads, etc, in
> > userspace. But there are already plenty of synchronization primitives
> > that can be used for cpu->cpu synchronization, either within the same
> > process or between multiple processes. For cpu access, even if it is
> > handled by background threads/processes, I think it is better to use
> > the traditional pthreads or unix synchronization primitives. They
> > have existed forever, they are well tested, and they work.
> >
> > So while it seems nice and orthogonal/clean to couple cache and
> > synchronization and handle dma->cpu and cpu->cpu and cpu->dma in the
> > same generic way, but I think in practice we have to make things more
> > complex than they otherwise need to be to do this. Otherwise I think
> > we'll be having problems with badly behaved or crashing userspace.
> >
> >
> Right, this is very important. I think it's not esay to solve this
> issue. Aand at least for ARM based embedded system, such feature is useful
> to us; coupling cache operation and buffer synchronization. I'd like to
> collect other opinions and advices to solve this issue.
Maybe we have a bit a misunderstanding here. The kernel really should take
care of sync and cache coherency, and I agree that with the current
dma_buf code (and the proposed fences) that part is still a bit hazy. But
the kernel should not allow userspace to block access to a buffer until
userspace is done. It should only sync with any oustanding fences and
flush buffers before that userspace access happens.
Then the kernel would again flush caches on the next dma access (which
hopefully is only started once userspace completed access). Atm this isn't
possible in an efficient way since the dma_buf api only exposes map/unmap
attachment and not a function to just sync an existing mapping like
dma_sync_single_for_device. I guess we should add a
dma_buf_sync_attachment interface for that - we already have range-based
cpu sync support with the begin/end_cpu_access interfaces.
Yours, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* [PATCH v2] video/matrox/matroxfb_maven: Use module_i2c_driver to register driver
From: Peter Huewe @ 2013-05-20 19:56 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: Jean Delvare, Mark Brown, Peter Huewe, linux-fbdev, linux-kernel
In-Reply-To: <20130520214206.078bc580@endymion.delvare>
Removing some boilerplate by using module_i2c_driver instead of calling
register and unregister in the otherwise empty init/exit functions.
Also removed a useless comment as suggested by Jean Delvare
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Reviewed-by: Jean Delvare <khali@linux-fr.org>
---
drivers/video/matrox/matroxfb_maven.c | 14 +-------------
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/video/matrox/matroxfb_maven.c b/drivers/video/matrox/matroxfb_maven.c
index 217678e..6360796 100644
--- a/drivers/video/matrox/matroxfb_maven.c
+++ b/drivers/video/matrox/matroxfb_maven.c
@@ -1283,19 +1283,7 @@ static struct i2c_driver maven_driver={
.id_table = maven_id,
};
-static int __init matroxfb_maven_init(void)
-{
- return i2c_add_driver(&maven_driver);
-}
-
-static void __exit matroxfb_maven_exit(void)
-{
- i2c_del_driver(&maven_driver);
-}
-
+module_i2c_driver(maven_driver);
MODULE_AUTHOR("(c) 1999-2002 Petr Vandrovec <vandrove@vc.cvut.cz>");
MODULE_DESCRIPTION("Matrox G200/G400 Matrox MGA-TVO driver");
MODULE_LICENSE("GPL");
-module_init(matroxfb_maven_init);
-module_exit(matroxfb_maven_exit);
-/* we do not have __setup() yet */
--
1.8.1.5
^ permalink raw reply related
* Re: [PATCH] video/matrox/matroxfb_maven: Use module_i2c_driver to register driver
From: Jean Delvare @ 2013-05-20 19:42 UTC (permalink / raw)
To: Peter Huewe
Cc: Florian Tobias Schandinat, Wolfram Sang, Mark Brown, linux-fbdev,
linux-kernel
In-Reply-To: <1369078578-3138-1-git-send-email-peterhuewe@gmx.de>
On Mon, 20 May 2013 21:36:18 +0200, Peter Huewe wrote:
> Removing some boilerplate by using module_i2c_driver instead of calling
> register and unregister in the otherwise empty init/exit functions
>
> Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
> ---
> drivers/video/matrox/matroxfb_maven.c | 13 +------------
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/video/matrox/matroxfb_maven.c b/drivers/video/matrox/matroxfb_maven.c
> index 217678e..fd4b64e 100644
> --- a/drivers/video/matrox/matroxfb_maven.c
> +++ b/drivers/video/matrox/matroxfb_maven.c
> @@ -1283,19 +1283,8 @@ static struct i2c_driver maven_driver={
> .id_table = maven_id,
> };
>
> -static int __init matroxfb_maven_init(void)
> -{
> - return i2c_add_driver(&maven_driver);
> -}
> -
> -static void __exit matroxfb_maven_exit(void)
> -{
> - i2c_del_driver(&maven_driver);
> -}
> -
> +module_i2c_driver(maven_driver);
> MODULE_AUTHOR("(c) 1999-2002 Petr Vandrovec <vandrove@vc.cvut.cz>");
> MODULE_DESCRIPTION("Matrox G200/G400 Matrox MGA-TVO driver");
> MODULE_LICENSE("GPL");
> -module_init(matroxfb_maven_init);
> -module_exit(matroxfb_maven_exit);
> /* we do not have __setup() yet */
This last comment could certainly go away as well, AFAICT it's a now
meaningless relic.
Other than this:
Reviewed-by: Jean Delvare <khali@linux-fr.org>
--
Jean Delvare
^ permalink raw reply
* [PATCH] video/matrox/matroxfb_maven: Use module_i2c_driver to register driver
From: Peter Huewe @ 2013-05-20 19:36 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: Wolfram Sang, Mark Brown, Peter Huewe, Jean Delvare, linux-fbdev,
linux-kernel
Removing some boilerplate by using module_i2c_driver instead of calling
register and unregister in the otherwise empty init/exit functions
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
---
drivers/video/matrox/matroxfb_maven.c | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/video/matrox/matroxfb_maven.c b/drivers/video/matrox/matroxfb_maven.c
index 217678e..fd4b64e 100644
--- a/drivers/video/matrox/matroxfb_maven.c
+++ b/drivers/video/matrox/matroxfb_maven.c
@@ -1283,19 +1283,8 @@ static struct i2c_driver maven_driver={
.id_table = maven_id,
};
-static int __init matroxfb_maven_init(void)
-{
- return i2c_add_driver(&maven_driver);
-}
-
-static void __exit matroxfb_maven_exit(void)
-{
- i2c_del_driver(&maven_driver);
-}
-
+module_i2c_driver(maven_driver);
MODULE_AUTHOR("(c) 1999-2002 Petr Vandrovec <vandrove@vc.cvut.cz>");
MODULE_DESCRIPTION("Matrox G200/G400 Matrox MGA-TVO driver");
MODULE_LICENSE("GPL");
-module_init(matroxfb_maven_init);
-module_exit(matroxfb_maven_exit);
/* we do not have __setup() yet */
--
1.8.1.5
^ permalink raw reply related
* Re: [PATCH V2] video: implement a simple framebuffer driver
From: Stephen Warren @ 2013-05-20 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAVeFuJ5q4Y0QtvJX2iVmq_O2ofs1B9=MB_aA8VdcEBdM4zf2Q@mail.gmail.com>
On 05/18/2013 04:29 AM, Alexandre Courbot wrote:
> On Thu, Apr 4, 2013 at 11:39 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> +struct simplefb_format {
>> + const char *name;
>> + u32 bits_per_pixel;
>> + struct fb_bitfield red;
>> + struct fb_bitfield green;
>> + struct fb_bitfield blue;
>> + struct fb_bitfield transp;
>> +};
>> +
>> +struct simplefb_format simplefb_formats[] = {
>> + { "r5g6b5", 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} },
>> +};
>
> I have been adding a few extra formats to this list, and I wonder if
> this could not simply be turned into a function that would directly
> convert the name string into the corresponding right format. The
> mapping between name and format seems to be a 1:1 and this would
> probably avoid errors in the future. I'm especially thinking about
> color order here - I started adding a mode that reads
>
> { "r8g8b8a8", 32, {0, 8}, {8, 8}, {16, 8}, {24, 8} },
>
> while it should probably be called "a8b8g8r8" as the order of colors
> is not the same as your r5g6b5.
>
> I can submit a patch if there is no issue with that idea.
I chose r5g6b5 rather than rgb565 specifically to make that format
trivially name machine-parsable. So, I'm not opposed to converting that
table to code. I'm not 100% sure if it's worth it or necessary by the
time we get to just 2 formats in the array, but I don't see any big
disadvantage, so why not. The DT binding documentation might want
enhancing with a more general description of how formats should be
represented if this is implemented.
^ permalink raw reply
* Re: [PATCH 0/4] FB updates for 3.11
From: Tony Prisk @ 2013-05-19 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1368868514-18975-1-git-send-email-linux@prisktech.co.nz>
On 18/05/13 21:15, Tony Prisk wrote:
> Patch #1 - Move register defines inside the driver and drop the header.
> Patch #2 - Convert the register defines to use the vendor preferred names.
> Patch #3 - Add a device clock to wm8505fb. Without it, only the uboot
> initialized resolution is supported.
> Patch #4 - Add support for the VGA output found on the APC8750 board.
>
> Tony Prisk (4):
> fb: vt8500: Move register defines inside driver
> fb: vt8500: Convert to use vendor register names
> fb: vt8500: Require a device clock for wm8505fb driver
> fb: vt8500: Add VGA output support to wm8505fb driver.
>
> .../devicetree/bindings/video/wm,wm8505-fb.txt | 9 +-
> drivers/video/wm8505fb.c | 195 ++++++++++++--
> drivers/video/wm8505fb_regs.h | 76 ------
> drivers/video/wmt_ge_rops.c | 280 +++++++++++++++-----
> 4 files changed, 394 insertions(+), 166 deletions(-)
> delete mode 100644 drivers/video/wm8505fb_regs.h
>
Florian/Tomi,
Please ignore these patches. This driver needs a bit more work, so I
will do a
more thorough series and resubmit.
Regards
Tony Prisk
^ permalink raw reply
* Re: [PATCH 4/4] fb: vt8500: Add VGA output support to wm8505fb driver.
From: Tony Prisk @ 2013-05-18 19:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABjd4Yxrk3hXnB5f6u+1HcJjymDZbtQ1F1HXkZ2dzF3dwCrWhg@mail.gmail.com>
On 19/05/13 01:28, Alexey Charkov wrote:
> 2013/5/18 Tony Prisk <linux@prisktech.co.nz>:
>> The APC8750 does not support an LCD panel, but provides a VGA connector.
>> This patch adds support for the VGA interface, and defines an optional
>> devicetree property to specify the output interface. The default if not
>> specified is LCD for backward compatibility.
>>
>> Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
>> ---
>> .../devicetree/bindings/video/wm,wm8505-fb.txt | 5 ++++
>> drivers/video/wm8505fb.c | 31 ++++++++++++++++++--
>> 2 files changed, 34 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt b/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
>> index 601416c..9f1d648 100644
>> --- a/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
>> +++ b/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
>> @@ -7,6 +7,10 @@ Required properties:
>> - bits-per-pixel : bit depth of framebuffer (16 or 32)
>> - clocks : phandle to DVO clock
>>
>> +Optional properties:
>> +- output-interface : the interface the fb should output on. Valid values are
>> + "lcd" or "vga". If not specified, the default is "lcd".
>> +
>> Required subnodes:
>> - display-timings: see display-timing.txt for information
>>
>> @@ -17,6 +21,7 @@ Example:
>> reg = <0xd8051700 0x200>;
>> bits-per-pixel = <16>;
>> clocks = <&clkdvo>;
>> + output-interface = "vga";
>>
>> display-timings {
>> native-mode = <&timing0>;
>> diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
>> index f8bffc2..d1f7f33 100644
>> --- a/drivers/video/wm8505fb.c
>> +++ b/drivers/video/wm8505fb.c
>> @@ -130,12 +130,17 @@
>>
>> #define to_wm8505fb_info(__info) container_of(__info, \
>> struct wm8505fb_info, fb)
>> +
>> +#define INTERFACE_LCD 1
>> +#define INTERFACE_VGA 2
>> +
>> struct wm8505fb_info {
>> struct fb_info fb;
>> void __iomem *regbase;
>> unsigned int contrast;
>> struct device *dev;
>> struct clk *clk_dvo;
>> + int interface;
>> };
>>
>>
>> @@ -158,7 +163,11 @@ static int wm8505fb_init_hw(struct fb_info *info)
>> * 0x31C sets the correct color mode (RGB565) for WM8650
>> * Bit 8+9 (0x300) are ignored on WM8505 as reserved
>> */
>> - writel(0x31c, fbi->regbase + REG_GOVRH_YUVRGB);
>> + if (fbi->interface = INTERFACE_VGA)
>> + writel(0x338, fbi->regbase + REG_GOVRH_YUVRGB);
>> + else
>> + writel(0x31c, fbi->regbase + REG_GOVRH_YUVRGB);
>> +
>> writel(1, fbi->regbase + REG_GOVRH_DVO_PIX);
> Tony,
>
> Would it be possible to also define known bit offsets for those
> registers, while you are at this? It would probably reduce the black
> magic quite a bit :)
On my list of things to do :)
>> /* Virtual buffer size */
>> @@ -167,7 +176,12 @@ static int wm8505fb_init_hw(struct fb_info *info)
>>
>> /* black magic ;) */
>> writel(0xf, fbi->regbase + REG_GOVRH_FHI);
>> - writel(4, fbi->regbase + REG_GOVRH_DVO_SET);
>> +
>> + if (fbi->interface = INTERFACE_VGA)
>> + writel(0xe, fbi->regbase + REG_GOVRH_DVO_SET);
>> + else
>> + writel(4, fbi->regbase + REG_GOVRH_DVO_SET);
> I don't remember if HDMI is yet another option for this register or
> not... If it is, it would probably warrant defining fbi->interface as
> an enum and changing this if-else into a switch statement to let the
> compiler add its checks/warnings.
This register defines the h/v syncpolarity and enable/disable for DVO.
>
>> writel(1, fbi->regbase + REG_GOVRH_MIF);
>> writel(1, fbi->regbase + REG_GOVRH_REG_STS);
>>
>> @@ -194,11 +208,15 @@ static int wm8505fb_set_timing(struct fb_info *info)
>> writel(h_end, fbi->regbase + REG_GOVRH_ACTPX_END);
>> writel(h_all, fbi->regbase + REG_GOVRH_H_ALLPXL);
>> writel(h_sync, fbi->regbase + REG_GOVRH_HDMI_HSYNW);
>> + if (fbi->interface = INTERFACE_VGA)
>> + writel(h_sync, fbi->regbase + REG_GOVRH_VGA_HSYNW);
> Will it misbehave on LCD if you write to the VGA register unconditionally?
Don't know - wouldn't imagine so. I will test it and see.
>
>> writel(v_start, fbi->regbase + REG_GOVRH_ACTLN_BG);
>> writel(v_end, fbi->regbase + REG_GOVRH_ACTLN_END);
>> writel(v_all, fbi->regbase + REG_GOVRH_V_ALLLN);
>> writel(v_sync, fbi->regbase + REG_GOVRH_HDMI_VBISW);
>> + if (fbi->interface = INTERFACE_VGA)
>> + writel(info->var.pixclock, fbi->regbase + REG_GOVRH_VGA_VSYNW);
> Same here. I would assume that setting the pixclock should not hurt
> LCD, which would then simplify the code a little.
>
> Thanks,
> Alexey
Regards
Tony Prisk
^ permalink raw reply
* Re: [PATCH 4/4] fb: vt8500: Add VGA output support to wm8505fb driver.
From: Andy Chernyak @ 2013-05-18 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABjd4Yxrk3hXnB5f6u+1HcJjymDZbtQ1F1HXkZ2dzF3dwCrWhg@mail.gmail.com>
On 05/18/2013 03:28 PM, Alexey Charkov wrote:
> 2013/5/18 Tony Prisk <linux@prisktech.co.nz>:
>
>> /* Virtual buffer size */
>> @@ -167,7 +176,12 @@ static int wm8505fb_init_hw(struct fb_info *info)
>>
>> /* black magic ;) */
>> writel(0xf, fbi->regbase + REG_GOVRH_FHI);
>> - writel(4, fbi->regbase + REG_GOVRH_DVO_SET);
>> +
>> + if (fbi->interface = INTERFACE_VGA)
>> + writel(0xe, fbi->regbase + REG_GOVRH_DVO_SET);
>> + else
>> + writel(4, fbi->regbase + REG_GOVRH_DVO_SET);
> I don't remember if HDMI is yet another option for this register or
> not... If it is, it would probably warrant defining fbi->interface as
> an enum and changing this if-else into a switch statement to let the
> compiler add its checks/warnings.
HDMI output can work simultaneously with LCD (on 8850 at least), which
fbi->interface in its current form would not allow to express.
> + if (fbi->interface = INTERFACE_VGA)
> + writel(h_sync, fbi->regbase + REG_GOVRH_VGA_HSYNW);
> Will it misbehave on LCD if you write to the VGA register unconditionally?
>
Can we have 3 flags, something like LCD_ON, VGA_ON, HDMI_ON instead of
enum for video interface selection?
Regards,
Andy.
^ permalink raw reply
* Re: [PATCH 4/4] fb: vt8500: Add VGA output support to wm8505fb driver.
From: Alexey Charkov @ 2013-05-18 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1368868514-18975-5-git-send-email-linux@prisktech.co.nz>
2013/5/18 Tony Prisk <linux@prisktech.co.nz>:
> The APC8750 does not support an LCD panel, but provides a VGA connector.
> This patch adds support for the VGA interface, and defines an optional
> devicetree property to specify the output interface. The default if not
> specified is LCD for backward compatibility.
>
> Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
> ---
> .../devicetree/bindings/video/wm,wm8505-fb.txt | 5 ++++
> drivers/video/wm8505fb.c | 31 ++++++++++++++++++--
> 2 files changed, 34 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt b/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
> index 601416c..9f1d648 100644
> --- a/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
> +++ b/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
> @@ -7,6 +7,10 @@ Required properties:
> - bits-per-pixel : bit depth of framebuffer (16 or 32)
> - clocks : phandle to DVO clock
>
> +Optional properties:
> +- output-interface : the interface the fb should output on. Valid values are
> + "lcd" or "vga". If not specified, the default is "lcd".
> +
> Required subnodes:
> - display-timings: see display-timing.txt for information
>
> @@ -17,6 +21,7 @@ Example:
> reg = <0xd8051700 0x200>;
> bits-per-pixel = <16>;
> clocks = <&clkdvo>;
> + output-interface = "vga";
>
> display-timings {
> native-mode = <&timing0>;
> diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
> index f8bffc2..d1f7f33 100644
> --- a/drivers/video/wm8505fb.c
> +++ b/drivers/video/wm8505fb.c
> @@ -130,12 +130,17 @@
>
> #define to_wm8505fb_info(__info) container_of(__info, \
> struct wm8505fb_info, fb)
> +
> +#define INTERFACE_LCD 1
> +#define INTERFACE_VGA 2
> +
> struct wm8505fb_info {
> struct fb_info fb;
> void __iomem *regbase;
> unsigned int contrast;
> struct device *dev;
> struct clk *clk_dvo;
> + int interface;
> };
>
>
> @@ -158,7 +163,11 @@ static int wm8505fb_init_hw(struct fb_info *info)
> * 0x31C sets the correct color mode (RGB565) for WM8650
> * Bit 8+9 (0x300) are ignored on WM8505 as reserved
> */
> - writel(0x31c, fbi->regbase + REG_GOVRH_YUVRGB);
> + if (fbi->interface = INTERFACE_VGA)
> + writel(0x338, fbi->regbase + REG_GOVRH_YUVRGB);
> + else
> + writel(0x31c, fbi->regbase + REG_GOVRH_YUVRGB);
> +
> writel(1, fbi->regbase + REG_GOVRH_DVO_PIX);
Tony,
Would it be possible to also define known bit offsets for those
registers, while you are at this? It would probably reduce the black
magic quite a bit :)
> /* Virtual buffer size */
> @@ -167,7 +176,12 @@ static int wm8505fb_init_hw(struct fb_info *info)
>
> /* black magic ;) */
> writel(0xf, fbi->regbase + REG_GOVRH_FHI);
> - writel(4, fbi->regbase + REG_GOVRH_DVO_SET);
> +
> + if (fbi->interface = INTERFACE_VGA)
> + writel(0xe, fbi->regbase + REG_GOVRH_DVO_SET);
> + else
> + writel(4, fbi->regbase + REG_GOVRH_DVO_SET);
I don't remember if HDMI is yet another option for this register or
not... If it is, it would probably warrant defining fbi->interface as
an enum and changing this if-else into a switch statement to let the
compiler add its checks/warnings.
> writel(1, fbi->regbase + REG_GOVRH_MIF);
> writel(1, fbi->regbase + REG_GOVRH_REG_STS);
>
> @@ -194,11 +208,15 @@ static int wm8505fb_set_timing(struct fb_info *info)
> writel(h_end, fbi->regbase + REG_GOVRH_ACTPX_END);
> writel(h_all, fbi->regbase + REG_GOVRH_H_ALLPXL);
> writel(h_sync, fbi->regbase + REG_GOVRH_HDMI_HSYNW);
> + if (fbi->interface = INTERFACE_VGA)
> + writel(h_sync, fbi->regbase + REG_GOVRH_VGA_HSYNW);
Will it misbehave on LCD if you write to the VGA register unconditionally?
> writel(v_start, fbi->regbase + REG_GOVRH_ACTLN_BG);
> writel(v_end, fbi->regbase + REG_GOVRH_ACTLN_END);
> writel(v_all, fbi->regbase + REG_GOVRH_V_ALLLN);
> writel(v_sync, fbi->regbase + REG_GOVRH_HDMI_VBISW);
> + if (fbi->interface = INTERFACE_VGA)
> + writel(info->var.pixclock, fbi->regbase + REG_GOVRH_VGA_VSYNW);
Same here. I would assume that setting the pixclock should not hurt
LCD, which would then simplify the code a little.
Thanks,
Alexey
^ permalink raw reply
* Re: [PATCH V2] video: implement a simple framebuffer driver
From: Alexandre Courbot @ 2013-05-18 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
On Thu, Apr 4, 2013 at 11:39 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> +struct simplefb_format {
> + const char *name;
> + u32 bits_per_pixel;
> + struct fb_bitfield red;
> + struct fb_bitfield green;
> + struct fb_bitfield blue;
> + struct fb_bitfield transp;
> +};
> +
> +struct simplefb_format simplefb_formats[] = {
> + { "r5g6b5", 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} },
> +};
I have been adding a few extra formats to this list, and I wonder if
this could not simply be turned into a function that would directly
convert the name string into the corresponding right format. The
mapping between name and format seems to be a 1:1 and this would
probably avoid errors in the future. I'm especially thinking about
color order here - I started adding a mode that reads
{ "r8g8b8a8", 32, {0, 8}, {8, 8}, {16, 8}, {24, 8} },
while it should probably be called "a8b8g8r8" as the order of colors
is not the same as your r5g6b5.
I can submit a patch if there is no issue with that idea.
Alex.
^ permalink raw reply
* [PATCH 4/4] fb: vt8500: Add VGA output support to wm8505fb driver.
From: Tony Prisk @ 2013-05-18 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1368868514-18975-1-git-send-email-linux@prisktech.co.nz>
The APC8750 does not support an LCD panel, but provides a VGA connector.
This patch adds support for the VGA interface, and defines an optional
devicetree property to specify the output interface. The default if not
specified is LCD for backward compatibility.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
.../devicetree/bindings/video/wm,wm8505-fb.txt | 5 ++++
drivers/video/wm8505fb.c | 31 ++++++++++++++++++--
2 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt b/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
index 601416c..9f1d648 100644
--- a/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
+++ b/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
@@ -7,6 +7,10 @@ Required properties:
- bits-per-pixel : bit depth of framebuffer (16 or 32)
- clocks : phandle to DVO clock
+Optional properties:
+- output-interface : the interface the fb should output on. Valid values are
+ "lcd" or "vga". If not specified, the default is "lcd".
+
Required subnodes:
- display-timings: see display-timing.txt for information
@@ -17,6 +21,7 @@ Example:
reg = <0xd8051700 0x200>;
bits-per-pixel = <16>;
clocks = <&clkdvo>;
+ output-interface = "vga";
display-timings {
native-mode = <&timing0>;
diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
index f8bffc2..d1f7f33 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -130,12 +130,17 @@
#define to_wm8505fb_info(__info) container_of(__info, \
struct wm8505fb_info, fb)
+
+#define INTERFACE_LCD 1
+#define INTERFACE_VGA 2
+
struct wm8505fb_info {
struct fb_info fb;
void __iomem *regbase;
unsigned int contrast;
struct device *dev;
struct clk *clk_dvo;
+ int interface;
};
@@ -158,7 +163,11 @@ static int wm8505fb_init_hw(struct fb_info *info)
* 0x31C sets the correct color mode (RGB565) for WM8650
* Bit 8+9 (0x300) are ignored on WM8505 as reserved
*/
- writel(0x31c, fbi->regbase + REG_GOVRH_YUVRGB);
+ if (fbi->interface = INTERFACE_VGA)
+ writel(0x338, fbi->regbase + REG_GOVRH_YUVRGB);
+ else
+ writel(0x31c, fbi->regbase + REG_GOVRH_YUVRGB);
+
writel(1, fbi->regbase + REG_GOVRH_DVO_PIX);
/* Virtual buffer size */
@@ -167,7 +176,12 @@ static int wm8505fb_init_hw(struct fb_info *info)
/* black magic ;) */
writel(0xf, fbi->regbase + REG_GOVRH_FHI);
- writel(4, fbi->regbase + REG_GOVRH_DVO_SET);
+
+ if (fbi->interface = INTERFACE_VGA)
+ writel(0xe, fbi->regbase + REG_GOVRH_DVO_SET);
+ else
+ writel(4, fbi->regbase + REG_GOVRH_DVO_SET);
+
writel(1, fbi->regbase + REG_GOVRH_MIF);
writel(1, fbi->regbase + REG_GOVRH_REG_STS);
@@ -194,11 +208,15 @@ static int wm8505fb_set_timing(struct fb_info *info)
writel(h_end, fbi->regbase + REG_GOVRH_ACTPX_END);
writel(h_all, fbi->regbase + REG_GOVRH_H_ALLPXL);
writel(h_sync, fbi->regbase + REG_GOVRH_HDMI_HSYNW);
+ if (fbi->interface = INTERFACE_VGA)
+ writel(h_sync, fbi->regbase + REG_GOVRH_VGA_HSYNW);
writel(v_start, fbi->regbase + REG_GOVRH_ACTLN_BG);
writel(v_end, fbi->regbase + REG_GOVRH_ACTLN_END);
writel(v_all, fbi->regbase + REG_GOVRH_V_ALLLN);
writel(v_sync, fbi->regbase + REG_GOVRH_HDMI_VBISW);
+ if (fbi->interface = INTERFACE_VGA)
+ writel(info->var.pixclock, fbi->regbase + REG_GOVRH_VGA_VSYNW);
writel(1, fbi->regbase + REG_GOVRH_TG_ENABLE);
@@ -371,6 +389,7 @@ static int wm8505fb_probe(struct platform_device *pdev)
dma_addr_t fb_mem_phys;
unsigned long fb_mem_len;
void *fb_mem_virt;
+ const char *intf;
fbi = devm_kzalloc(&pdev->dev, sizeof(struct wm8505fb_info) +
sizeof(u32) * 16, GFP_KERNEL);
@@ -428,6 +447,14 @@ static int wm8505fb_probe(struct platform_device *pdev)
clk_prepare_enable(fbi->clk_dvo);
+ fbi->interface = INTERFACE_LCD;
+ ret = of_property_read_string(pdev->dev.of_node, "output-interface",
+ &intf);
+ if (!ret) {
+ if (!strcmp(intf, "vga"))
+ fbi->interface = INTERFACE_VGA;
+ }
+
fb_videomode_to_var(&fbi->fb.var, &mode);
fbi->fb.var.nonstd = 0;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/4] fb: vt8500: Require a device clock for wm8505fb driver
From: Tony Prisk @ 2013-05-18 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1368868514-18975-1-git-send-email-linux@prisktech.co.nz>
The wm8505fb driver requires a clock to work properly. Without a clock,
the driver can only initialize the display resolution that was set in
uboot.
This patch updates the driver to get and use a clock, and updates
the devicetree documentation to indicate the requirement for a clock.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
.../devicetree/bindings/video/wm,wm8505-fb.txt | 4 ++-
drivers/video/wm8505fb.c | 30 +++++++++++++++++---
2 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt b/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
index 0bcadb2..601416c 100644
--- a/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
+++ b/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
@@ -5,6 +5,7 @@ Required properties:
- compatible : "wm,wm8505-fb"
- reg : Should contain 1 register ranges(address and length)
- bits-per-pixel : bit depth of framebuffer (16 or 32)
+- clocks : phandle to DVO clock
Required subnodes:
- display-timings: see display-timing.txt for information
@@ -15,11 +16,12 @@ Example:
compatible = "wm,wm8505-fb";
reg = <0xd8051700 0x200>;
bits-per-pixel = <16>;
+ clocks = <&clkdvo>;
display-timings {
native-mode = <&timing0>;
timing0: 800x480 {
- clock-frequency = <0>; /* unused but required */
+ clock-frequency = <30000000>;
hactive = <800>;
vactive = <480>;
hfront-porch = <40>;
diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
index 167a9e2..f8bffc2 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -14,6 +14,7 @@
* GNU General Public License for more details.
*/
+#include <linux/clk.h>
#include <linux/delay.h>
#include <linux/dma-mapping.h>
#include <linux/fb.h>
@@ -130,9 +131,11 @@
#define to_wm8505fb_info(__info) container_of(__info, \
struct wm8505fb_info, fb)
struct wm8505fb_info {
- struct fb_info fb;
- void __iomem *regbase;
- unsigned int contrast;
+ struct fb_info fb;
+ void __iomem *regbase;
+ unsigned int contrast;
+ struct device *dev;
+ struct clk *clk_dvo;
};
@@ -210,6 +213,13 @@ static int wm8505fb_set_par(struct fb_info *info)
if (!fbi)
return -EINVAL;
+ if (info->var.pixclock = 0) {
+ dev_err(fbi->dev, "requested pixclock = 0\n");
+ return -EINVAL;
+ }
+
+ clk_set_rate(fbi->clk_dvo, PICOS2KHZ(info->var.pixclock)*1000);
+
if (info->var.bits_per_pixel = 32) {
info->var.red.offset = 16;
info->var.red.length = 8;
@@ -369,6 +379,8 @@ static int wm8505fb_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ fbi->dev = &pdev->dev;
+
strcpy(fbi->fb.fix.id, DRIVER_NAME);
fbi->fb.fix.type = FB_TYPE_PACKED_PIXELS;
@@ -408,6 +420,14 @@ static int wm8505fb_probe(struct platform_device *pdev)
if (ret)
return ret;
+ fbi->clk_dvo = of_clk_get(pdev->dev.of_node, 0);
+ if (IS_ERR(fbi->clk_dvo)) {
+ dev_err(&pdev->dev, "Error retrieving clock\n");
+ return PTR_ERR(fbi->clk_dvo);
+ }
+
+ clk_prepare_enable(fbi->clk_dvo);
+
fb_videomode_to_var(&fbi->fb.var, &mode);
fbi->fb.var.nonstd = 0;
@@ -421,7 +441,7 @@ static int wm8505fb_probe(struct platform_device *pdev)
fb_mem_virt = dmam_alloc_coherent(&pdev->dev, fb_mem_len, &fb_mem_phys,
GFP_KERNEL);
if (!fb_mem_virt) {
- pr_err("%s: Failed to allocate framebuffer\n", __func__);
+ dev_err(&pdev->dev, "Failed to allocate framebuffer\n");
return -ENOMEM;
}
@@ -480,6 +500,8 @@ static int wm8505fb_remove(struct platform_device *pdev)
unregister_framebuffer(&fbi->fb);
+ clk_disable_unprepare(fbi->clk_dvo);
+
writel(0, fbi->regbase);
if (fbi->fb.cmap.len)
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/4] fb: vt8500: Convert to use vendor register names
From: Tony Prisk @ 2013-05-18 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1368868514-18975-1-git-send-email-linux@prisktech.co.nz>
Change all the #defines to match the vendor defined names, and change the
references in wm8505fb.c and wmt_ge_rops.c.
Add all the missing register offsets as well to prevent churn in the future.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
drivers/video/wm8505fb.c | 159 ++++++++++++++++--------
drivers/video/wmt_ge_rops.c | 280 +++++++++++++++++++++++++++++++++----------
2 files changed, 332 insertions(+), 107 deletions(-)
diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
index f824af8..167a9e2 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -38,29 +38,94 @@
#define DRIVER_NAME "wm8505-fb"
-#define WMT_GOVR_COLORSPACE1 0x030
-#define WMT_GOVR_MIF_ENABLE 0x080
-#define WMT_GOVR_FBADDR 0x090
-#define WMT_GOVR_FBADDR1 0x094
-#define WMT_GOVR_XRES 0x098
-#define WMT_GOVR_XRES_VIRTUAL 0x09c
-#define WMT_GOVR_YPAN 0x0a0
-#define WMT_GOVR_XPAN 0x0a4
-#define WMT_GOVR_FHI 0x0a8
-#define WMT_GOVR_REG_UPDATE 0x0e4
-#define WMT_GOVR_TG 0x100
-#define WMT_GOVR_TIMING_H_ALL 0x108
-#define WMT_GOVR_TIMING_V_ALL 0x10c
-#define WMT_GOVR_TIMING_V_START 0x110
-#define WMT_GOVR_TIMING_V_END 0x114
-#define WMT_GOVR_TIMING_H_START 0x118
-#define WMT_GOVR_TIMING_H_END 0x11c
-#define WMT_GOVR_TIMING_V_SYNC 0x128
-#define WMT_GOVR_TIMING_H_SYNC 0x12c
-#define WMT_GOVR_DVO_SET 0x148
-#define WMT_GOVR_CONTRAST 0x1b8
-#define WMT_GOVR_BRGHTNESS 0x1bc
-#define WMT_GOVR_COLORSPACE 0x1e4
+#define REG_GOVRH_CUR_ADDR 0x0000
+#define REG_GOVRH_CUR_WIDTH 0x0004
+#define REG_GOVRH_CUR_FB_WIDTH 0x0008
+#define REG_GOVRH_CUR_VCROP 0x000C
+#define REG_GOVRH_CUR_HCROP 0x0010
+#define REG_GOVRH_CUR_HCOORD 0x0014
+#define REG_GOVRH_CUR_VCOORD 0x0018
+#define REG_GOVRH_CUR_STATUS 0x001C
+#define REG_GOVRH_CUR_COLOR_KEY 0x0020
+#define REG_GOVRH_DVO_PIX 0x0030
+#define REG_GOVRH_DVO_DLY_SEL 0x0034
+#define REG_GOVRH_INT 0x0038
+#define REG_GOVRH_DVO_BLANK_DATA 0x003C
+#define REG_GOVRH_DIRPATH 0x0040 /* WM8750+ */
+#define REG_GOVRH_MIF 0x0080
+#define REG_GOVRH_COLFMT 0x0084
+#define REG_GOVRH_SRCFMT 0x0088
+#define REG_GOVRH_DSTFMT 0x008C
+#define REG_GOVRH_YSA 0x0090
+#define REG_GOVRH_CSA 0x0094
+#define REG_GOVRH_PIXWID 0x0098
+#define REG_GOVRH_BUFWID 0x009C
+#define REG_GOVRH_VCROP 0x00A0
+#define REG_GOVRH_HCROP 0x00A4
+#define REG_GOVRH_FHI 0x00A8
+#define REG_GOVRH_COLFMT2 0x00AC
+#define REG_GOVRH_YSA2 0x00B0 /* WM8950 */
+#define REG_GOVRH_CSA2 0x00B4 /* WM8950 */
+#define REG_GOVRH_MIF_FRAME_MODE 0x00B8 /* WM8950 */
+#define REG_GOVRH_REG_STS 0x00E4
+#define REG_GOVRH_SWFLD 0x00E8
+#define REG_GOVRH_TG_ENABLE 0x0100
+#define REG_GOVRH_READ_CYC 0x0104
+#define REG_GOVRH_H_ALLPXL 0x0108
+#define REG_GOVRH_V_ALLLN 0x010C
+#define REG_GOVRH_ACTLN_BG 0x0110
+#define REG_GOVRH_ACTLN_END 0x0114
+#define REG_GOVRH_ACTPX_BG 0x0118
+#define REG_GOVRH_ACTPX_END 0x011C
+#define REG_GOVRH_VBIE_LINE 0x0120
+#define REG_GOVRH_PVBI_LINE 0x0124
+#define REG_GOVRH_HDMI_VBISW 0x0128
+#define REG_GOVRH_HDMI_HSYNW 0x012C
+#define REG_GOVRH_VSYNC_OFFSET 0x0130
+#define REG_GOVRH_FIELD_STATUS 0x0134
+#define REG_GOVRH_HDMI_3D 0x013C /* WM8950 */
+#define REG_GOVRH_DVO_SET 0x0148
+#define REG_GOVRH_CB_ENABLE 0x0150
+#define REG_GOVRH_H_ALLPXL2 0x0158
+#define REG_GOVRH_V_ALLLN2 0x015C
+#define REG_GOVRH_ACTLN_BG2 0x0160
+#define REG_GOVRH_ACTLN_END2 0x0164
+#define REG_GOVRH_ACTPX_BG2 0x0168
+#define REG_GOVRH_ACTPX_END2 0x016C
+#define REG_GOVRH_VBIE_LINE2 0x0170
+#define REG_GOVRH_PVBI_LINE2 0x0174
+#define REG_GOVRH_HDMI_VBISW2 0x0178
+#define REG_GOVRH_HDMI_HSYNW2 0x017C
+#define REG_GOVRH_LVDS_CTRL 0x0180 /* WM8750+ */
+#define REG_GOVRH_LVDS_CTRL2 0x0184 /* WM8750+ */
+#define REG_GOVRH_DAC_LP_SENSE_VAL 0x0188 /* WM8750 */
+#define REG_GOVRH_DAC_TEST_MODE 0x018C /* WM8750 */
+#define REG_GOVRH_VGA_HSYNW 0x0190 /* WM8750 */
+#define REG_GOVRH_VGA_VSYNW 0x0194 /* WM8750 */
+#define REG_GOVRH_VGA_SYNPOLAR 0x0198 /* WM8750 */
+#define REG_GOVRH_DAC_MOD 0x019C /* WM8750 */
+#define REG_GOVRH_DAC_VAL 0x01A0 /* WM8750 */
+#define REG_GOVRH_DAC_CON 0x01A4 /* WM8750 */
+#define REG_GOVRH_DAC_TEST 0x01A8 /* WM8750 */
+#define REG_GOVRH_DAC_BTEST 0x01AC /* WM8750 */
+#define REG_GOVRH_DAC_CTEST 0x01B0 /* WM8750 */
+#define REG_GOVRH_DAC_DBG 0x01B4 /* WM8750 */
+#define REG_GOVRH_CONTRAST 0x01B8
+#define REG_GOVRH_BRIGHTNESS 0x01BC
+#define REG_GOVRH_DMACSC_COEF0 0x01C0
+#define REG_GOVRH_DMACSC_COEF1 0x01C4
+#define REG_GOVRH_DMACSC_COEF2 0x01C8
+#define REG_GOVRH_DMACSC_COEF3 0x01CC
+#define REG_GOVRH_DMACSC_COEF4 0x01D0
+#define REG_GOVRH_DMACSC_COEF5 0x01D8
+#define REG_GOVRH_DMACSC_COEF6 0x01DC
+#define REG_GOVRH_CSC_MODE 0x01E0
+#define REG_GOVRH_YUVRGB 0x01E4
+#define REG_GOVRH_H264_INPUT_EN 0x01E8
+#define REG_GOVRH_DISP_EN 0x01EC /* WM8750 */
+#define REG_GOVRH_HSCALE_UP 0x01F4
+#define REG_GOVRH_IGS_MODE 0x01F8
+#define REG_GOVRH_IGS_MODE2 0x01FC
#define to_wm8505fb_info(__info) container_of(__info, \
struct wm8505fb_info, fb)
@@ -82,26 +147,26 @@ static int wm8505fb_init_hw(struct fb_info *info)
writel(0, fbi->regbase + i);
/* Set frame buffer address */
- writel(fbi->fb.fix.smem_start, fbi->regbase + WMT_GOVR_FBADDR);
- writel(fbi->fb.fix.smem_start, fbi->regbase + WMT_GOVR_FBADDR1);
+ writel(fbi->fb.fix.smem_start, fbi->regbase + REG_GOVRH_YSA);
+ writel(fbi->fb.fix.smem_start, fbi->regbase + REG_GOVRH_CSA);
/*
* Set in-memory picture format to RGB
* 0x31C sets the correct color mode (RGB565) for WM8650
* Bit 8+9 (0x300) are ignored on WM8505 as reserved
*/
- writel(0x31c, fbi->regbase + WMT_GOVR_COLORSPACE);
- writel(1, fbi->regbase + WMT_GOVR_COLORSPACE1);
+ writel(0x31c, fbi->regbase + REG_GOVRH_YUVRGB);
+ writel(1, fbi->regbase + REG_GOVRH_DVO_PIX);
/* Virtual buffer size */
- writel(info->var.xres, fbi->regbase + WMT_GOVR_XRES);
- writel(info->var.xres_virtual, fbi->regbase + WMT_GOVR_XRES_VIRTUAL);
+ writel(info->var.xres, fbi->regbase + REG_GOVRH_PIXWID);
+ writel(info->var.xres_virtual, fbi->regbase + REG_GOVRH_BUFWID);
/* black magic ;) */
- writel(0xf, fbi->regbase + WMT_GOVR_FHI);
- writel(4, fbi->regbase + WMT_GOVR_DVO_SET);
- writel(1, fbi->regbase + WMT_GOVR_MIF_ENABLE);
- writel(1, fbi->regbase + WMT_GOVR_REG_UPDATE);
+ writel(0xf, fbi->regbase + REG_GOVRH_FHI);
+ writel(4, fbi->regbase + REG_GOVRH_DVO_SET);
+ writel(1, fbi->regbase + REG_GOVRH_MIF);
+ writel(1, fbi->regbase + REG_GOVRH_REG_STS);
return 0;
}
@@ -120,19 +185,19 @@ static int wm8505fb_set_timing(struct fb_info *info)
int v_all = v_end + info->var.lower_margin;
int v_sync = info->var.vsync_len;
- writel(0, fbi->regbase + WMT_GOVR_TG);
+ writel(0, fbi->regbase + REG_GOVRH_TG_ENABLE);
- writel(h_start, fbi->regbase + WMT_GOVR_TIMING_H_START);
- writel(h_end, fbi->regbase + WMT_GOVR_TIMING_H_END);
- writel(h_all, fbi->regbase + WMT_GOVR_TIMING_H_ALL);
- writel(h_sync, fbi->regbase + WMT_GOVR_TIMING_H_SYNC);
+ writel(h_start, fbi->regbase + REG_GOVRH_ACTPX_BG);
+ writel(h_end, fbi->regbase + REG_GOVRH_ACTPX_END);
+ writel(h_all, fbi->regbase + REG_GOVRH_H_ALLPXL);
+ writel(h_sync, fbi->regbase + REG_GOVRH_HDMI_HSYNW);
- writel(v_start, fbi->regbase + WMT_GOVR_TIMING_V_START);
- writel(v_end, fbi->regbase + WMT_GOVR_TIMING_V_END);
- writel(v_all, fbi->regbase + WMT_GOVR_TIMING_V_ALL);
- writel(v_sync, fbi->regbase + WMT_GOVR_TIMING_V_SYNC);
+ writel(v_start, fbi->regbase + REG_GOVRH_ACTLN_BG);
+ writel(v_end, fbi->regbase + REG_GOVRH_ACTLN_END);
+ writel(v_all, fbi->regbase + REG_GOVRH_V_ALLLN);
+ writel(v_sync, fbi->regbase + REG_GOVRH_HDMI_VBISW);
- writel(1, fbi->regbase + WMT_GOVR_TG);
+ writel(1, fbi->regbase + REG_GOVRH_TG_ENABLE);
return 0;
}
@@ -174,7 +239,7 @@ static int wm8505fb_set_par(struct fb_info *info)
wm8505fb_set_timing(info);
writel(fbi->contrast<<16 | fbi->contrast<<8 | fbi->contrast,
- fbi->regbase + WMT_GOVR_CONTRAST);
+ fbi->regbase + REG_GOVRH_CONTRAST);
return 0;
}
@@ -250,8 +315,8 @@ static int wm8505fb_pan_display(struct fb_var_screeninfo *var,
{
struct wm8505fb_info *fbi = to_wm8505fb_info(info);
- writel(var->xoffset, fbi->regbase + WMT_GOVR_XPAN);
- writel(var->yoffset, fbi->regbase + WMT_GOVR_YPAN);
+ writel(var->xoffset, fbi->regbase + REG_GOVRH_VCROP);
+ writel(var->yoffset, fbi->regbase + REG_GOVRH_HCROP);
return 0;
}
@@ -264,7 +329,7 @@ static int wm8505fb_blank(int blank, struct fb_info *info)
wm8505fb_set_timing(info);
break;
default:
- writel(0, fbi->regbase + WMT_GOVR_TIMING_V_SYNC);
+ writel(0, fbi->regbase + REG_GOVRH_HDMI_VBISW);
break;
}
diff --git a/drivers/video/wmt_ge_rops.c b/drivers/video/wmt_ge_rops.c
index 4aaeb18..68de46a 100644
--- a/drivers/video/wmt_ge_rops.c
+++ b/drivers/video/wmt_ge_rops.c
@@ -20,29 +20,189 @@
#include <linux/platform_device.h>
#include "fb_draw.h"
-#define GE_COMMAND_OFF 0x00
-#define GE_DEPTH_OFF 0x04
-#define GE_HIGHCOLOR_OFF 0x08
-#define GE_ROPCODE_OFF 0x14
-#define GE_FIRE_OFF 0x18
-#define GE_SRCBASE_OFF 0x20
-#define GE_SRCDISPW_OFF 0x24
-#define GE_SRCDISPH_OFF 0x28
-#define GE_SRCAREAX_OFF 0x2c
-#define GE_SRCAREAY_OFF 0x30
-#define GE_SRCAREAW_OFF 0x34
-#define GE_SRCAREAH_OFF 0x38
-#define GE_DESTBASE_OFF 0x3c
-#define GE_DESTDISPW_OFF 0x40
-#define GE_DESTDISPH_OFF 0x44
-#define GE_DESTAREAX_OFF 0x48
-#define GE_DESTAREAY_OFF 0x4c
-#define GE_DESTAREAW_OFF 0x50
-#define GE_DESTAREAH_OFF 0x54
-#define GE_PAT0C_OFF 0x88 /* Pattern 0 color */
-#define GE_ENABLE_OFF 0xec
-#define GE_INTEN_OFF 0xf0
-#define GE_STATUS_OFF 0xf8
+#define GE_COMMAND 0x0000
+#define GE_COLOR_DEPTH 0x0004
+#define GE_HM_SEL 0x0008
+#define GE_PAT_TRAN_EN 0x000C
+#define GE_FONT_TRAN_EN 0x0010
+#define GE_ROP_CODE 0x0014
+#define GE_FIRE 0x0018
+#define GE_ROP_BG_CODE 0x001C
+#define GE_SRC_BADDR 0x0020
+#define GE_SRC_DISP_W 0x0024
+#define GE_SRC_DISP_H 0x0028
+#define GE_SRC_X_START 0x002C
+#define GE_SRC_Y_START 0x0030
+#define GE_SRC_WIDTH 0x0034
+#define GE_SRC_HEIGHT 0x0038
+#define GE_DES_BADDR 0x003C
+#define GE_DES_DISP_W 0x0040
+#define GE_DES_DISP_H 0x0044
+#define GE_DES_X_START 0x0048
+#define GE_DES_Y_START 0x004C
+#define GE_DES_WIDTH 0x0050
+#define GE_DES_HEIGHT 0x0054
+#define GE_FONT0_BUF 0x0058
+#define GE_FONT1_BUF 0x005C
+#define GE_FONT2_BUF 0x0060
+#define GE_FONT3_BUF 0x0064
+#define GE_PAT0_BUF 0x0068
+#define GE_PAT1_BUF 0x006C
+#define GE_PAT2_BUF 0x0070
+#define GE_PAT3_BUF 0x0074
+#define GE_PAT4_BUF 0x0078
+#define GE_PAT5_BUF 0x007C
+#define GE_PAT6_BUF 0x0080
+#define GE_PAT7_BUF 0x0084
+#define GE_PAT0_COLOR 0x0088
+#define GE_PAT1_COLOR 0x008C
+#define GE_PAT2_COLOR 0x0090
+#define GE_PAT3_COLOR 0x0094
+#define GE_PAT4_COLOR 0x0098
+#define GE_PAT5_COLOR 0x009C
+#define GE_PAT6_COLOR 0x00A0
+#define GE_PAT7_COLOR 0x00A4
+#define GE_PAT8_COLOR 0x00A8
+#define GE_PAT9_COLOR 0x00AC
+#define GE_PAT10_COLOR 0x00B0
+#define GE_PAT11_COLOR 0x00B4
+#define GE_PAT12_COLOR 0x00B8
+#define GE_PAT13_COLOR 0x00BC
+#define GE_PAT14_COLOR 0x00C0
+#define GE_PAT15_COLOR 0x00C4
+#define GE_CK_SEL 0x00C8
+#define GE_SRC_CK 0x00CC
+#define GE_DES_CK 0x00D0
+#define GE_ALPHA_SEL 0x00D4
+#define GE_BITBLT_ALPHA 0x00D8
+#define GE_DES_PATH_EN 0x00DC
+#define GE_ROTATE_MODE 0x00E0
+#define GE_MIRROR_MODE 0x00E4
+#define GE_GE_DELAY 0x00E8
+#define GE_ENABLE 0x00EC
+#define GE_INT_EN 0x00F0
+#define GE_INT_FLAG 0x00F4
+#define GE_STATUS 0x00F8
+#define GE_SWID 0x00FC
+#define GE_LN_X_START 0x0100
+#define GE_LN_X_END 0x0104
+#define GE_LN_Y_START 0x0108
+#define GE_LN_Y_END 0x0110
+#define GE_LN_TCK 0x0114
+#define GE_AMX_CSC_BYPASS 0x0118
+#define GE_C1_COEF 0x011C
+#define GE_LN_STL_TB 0x0120
+#define GE_LN_STL_RTN 0x0124
+#define GE_LN_STL_DATA 0x0128
+#define GE_LN_STL_APA 0x012C
+#define GE_BC_P1X 0x0130
+#define GE_BC_P1Y 0x0134
+#define GE_BC_P2X 0x0138
+#define GE_BC_P2Y 0x013C
+#define GE_BC_P3X 0x0140
+#define GE_BC_P3Y 0x0144
+#define GE_BC_COLOR 0x0148
+#define GE_BC_ALPHA 0x014C
+#define GE_BC_DELTA_T 0x0150
+#define GE_BC_L_STL 0x0154
+#define GE_BC_L_STL_RTN 0x0158
+#define GE_C2_COEF 0x015C
+#define GE_C3_COEF 0x0160
+#define GE_C4_COEF 0x0164
+#define GE_C5_COEF 0x0168
+#define GE_C6_COEF 0x016C
+#define GE_C7_COEF 0x0170
+#define GE_C8_COEF 0x0174
+#define GE_YUV2_Y_BADDR 0x0178
+#define GE_YUV2_C_BADDR 0x017C
+#define GE_VQ_EN 0x0180
+#define GE_VQ_SIZE 0x0184
+#define GE_VQ_UDPTR 0x0188
+#define GE_VQ_BASEADDR 0x018C
+#define GE_VQ_WRSIZE 0x0190
+#define GE_VQ_STADDRW 0x0194
+#define GE_VQ_THR 0x0198
+#define GE_VQ_YUV2_Y_FBW 0x019C
+#define GE_ROP4_EN 0x01A0
+#define GE_ALPHA_PLANE_EN 0x01A4
+#define GE_MASK_BADDR 0x01A8
+#define GE_MASK_DISP_W 0x01AC
+#define GE_MASK_DISP_H 0x01B0
+#define GE_MASK_X_START 0x01B4
+#define GE_MASK_Y_START 0x01B8
+#define GE_MASK_WIDTH 0x01BC
+#define GE_MASK_HEIGHT 0x01C0
+#define GE_DW_MASK_BADDR 0x01C4
+#define GE_ALPHA_PLANE_WBE 0x01C8
+#define GE_YUV2_C_FBW 0x01CC
+#define GE_ADAP_BLEND_EN 0x01D0
+#define GE_SRC_ALPHA_SEL 0x01D4
+#define GE_SRC_BLEND_APA 0x01D8
+#define GE_DES_ALPHA_SEL 0x01DC
+#define GE_DES_BLEND_APA 0x01E0
+#define GE_ADAP_CLAMP_EN 0x01E4
+#define GE_YUV2_C_BLEND_SEL 0x01E8
+#define GE_SRC_INDEP_MODE 0x01EC
+#define GE_C9_COEF 0x01F0
+#define GE_COEF_I 0x01F4
+#define GE_COEF_J 0x01F8
+#define GE_COEF_K 0x01FC
+#define GE_G1_CD 0x0200
+#define GE_G2_CD 0x0204
+#define GE_G1_FG_ADDR 0x0210
+#define GE_G1_BG_ADDR 0x0214
+#define GE_G1_FB_SEL 0x0218
+#define GE_G2_FG_ADDR 0x021C
+#define GE_G2_BG_ADDR 0x0220
+#define GE_G2_FB_SEL 0x0224
+#define GE_G1_X_START 0x0230
+#define GE_G1_X_END 0x0234
+#define GE_G1_Y_START 0x0238
+#define GE_G1_Y_END 0x023C
+#define GE_G2_X_START 0x0240
+#define GE_G2_X_END 0x0244
+#define GE_G2_Y_START 0x0248
+#define GE_G2_Y_END 0x024C
+#define GE_DISP_X_END 0x0250
+#define GE_DISP_Y_END 0x0254
+#define GE_AMX_CB 0x0258
+#define GE_G1_YUV_MODE_EN 0x025C
+#define GE_G2_YUV_MODE_EN 0x0260
+#define GE_G1_YUV_FMT_SEL 0x0264
+#define GE_G1_YUV_OUTP_SEL 0x0268
+#define GE_G2_YUV_FMT_SEL 0x026C
+#define GE_G2_YUV_OUTP_SEL 0x0270
+#define GE_AMX_CSC_CFG 0x0274
+#define GE_AMX_CSC_MODE 0x0278
+#define GE_AMX_Y_SUB_16_EN 0x027C
+#define GE_G1_YUV_ADDR 0x0280
+#define GE_G2_YUV_ADDR 0x0284
+#define GE_G1_CK_EN 0x0298
+#define GE_G2_CK_EN 0x029C
+#define GE_G1_C_KEY 0x02A0
+#define GE_G2_C_KEY 0x02A4
+#define GE_G1_AMX_EN 0x02A8
+#define GE_G2_AMX_EN 0x02AC
+#define GE_CK2_APA 0x02B0
+#define GE_AMX_CTL 0x02B4
+#define GE_CK_APA 0x02B8
+#define GE_FIX_APA 0x02BC
+#define GE_G1_AMX_HM 0x02C0
+#define GE_G2_AMX_HM 0x02C4
+#define GE_NH_DATA 0x02C8
+#define GE_VSYNC_STS 0x02CC
+#define GE_REG_UPD 0x02D0
+#define GE_REG_SEL 0x02D4
+#define GE_REG_AMX2_CTL 0x02D8
+#define GE_FIX2_APA 0x02DC
+#define GE_G1_H_SCALE 0x02E0
+#define GE_G2_H_SCALE 0x02E4
+#define GE_G1_FBW 0x02E8
+#define GE_G1_VCROP 0x02EC
+#define GE_G1_HCROP 0x02F0
+#define GE_G2_FBW 0x02F4
+#define GE_G2_VCROP 0x02F8
+#define GE_G2_HCROP 0x02FC
static void __iomem *regbase;
@@ -65,20 +225,20 @@ void wmt_ge_fillrect(struct fb_info *p, const struct fb_fillrect *rect)
p->fbops->fb_sync(p);
writel(p->var.bits_per_pixel = 32 ? 3 :
- (p->var.bits_per_pixel = 8 ? 0 : 1), regbase + GE_DEPTH_OFF);
- writel(p->var.bits_per_pixel = 15 ? 1 : 0, regbase + GE_HIGHCOLOR_OFF);
- writel(p->fix.smem_start, regbase + GE_DESTBASE_OFF);
- writel(p->var.xres_virtual - 1, regbase + GE_DESTDISPW_OFF);
- writel(p->var.yres_virtual - 1, regbase + GE_DESTDISPH_OFF);
- writel(rect->dx, regbase + GE_DESTAREAX_OFF);
- writel(rect->dy, regbase + GE_DESTAREAY_OFF);
- writel(rect->width - 1, regbase + GE_DESTAREAW_OFF);
- writel(rect->height - 1, regbase + GE_DESTAREAH_OFF);
-
- writel(pat, regbase + GE_PAT0C_OFF);
- writel(1, regbase + GE_COMMAND_OFF);
- writel(rect->rop = ROP_XOR ? 0x5a : 0xf0, regbase + GE_ROPCODE_OFF);
- writel(1, regbase + GE_FIRE_OFF);
+ (p->var.bits_per_pixel = 8 ? 0 : 1), regbase + GE_COLOR_DEPTH);
+ writel(p->var.bits_per_pixel = 15 ? 1 : 0, regbase + GE_HM_SEL);
+ writel(p->fix.smem_start, regbase + GE_DES_BADDR);
+ writel(p->var.xres_virtual - 1, regbase + GE_DES_DISP_W);
+ writel(p->var.yres_virtual - 1, regbase + GE_DES_DISP_H);
+ writel(rect->dx, regbase + GE_DES_X_START);
+ writel(rect->dy, regbase + GE_DES_Y_START);
+ writel(rect->width - 1, regbase + GE_DES_WIDTH);
+ writel(rect->height - 1, regbase + GE_DES_HEIGHT);
+
+ writel(pat, regbase + GE_PAT0_COLOR);
+ writel(1, regbase + GE_COMMAND);
+ writel(rect->rop = ROP_XOR ? 0x5a : 0xf0, regbase + GE_ROP_CODE);
+ writel(1, regbase + GE_FIRE);
}
EXPORT_SYMBOL_GPL(wmt_ge_fillrect);
@@ -91,34 +251,34 @@ void wmt_ge_copyarea(struct fb_info *p, const struct fb_copyarea *area)
p->fbops->fb_sync(p);
writel(p->var.bits_per_pixel > 16 ? 3 :
- (p->var.bits_per_pixel > 8 ? 1 : 0), regbase + GE_DEPTH_OFF);
-
- writel(p->fix.smem_start, regbase + GE_SRCBASE_OFF);
- writel(p->var.xres_virtual - 1, regbase + GE_SRCDISPW_OFF);
- writel(p->var.yres_virtual - 1, regbase + GE_SRCDISPH_OFF);
- writel(area->sx, regbase + GE_SRCAREAX_OFF);
- writel(area->sy, regbase + GE_SRCAREAY_OFF);
- writel(area->width - 1, regbase + GE_SRCAREAW_OFF);
- writel(area->height - 1, regbase + GE_SRCAREAH_OFF);
-
- writel(p->fix.smem_start, regbase + GE_DESTBASE_OFF);
- writel(p->var.xres_virtual - 1, regbase + GE_DESTDISPW_OFF);
- writel(p->var.yres_virtual - 1, regbase + GE_DESTDISPH_OFF);
- writel(area->dx, regbase + GE_DESTAREAX_OFF);
- writel(area->dy, regbase + GE_DESTAREAY_OFF);
- writel(area->width - 1, regbase + GE_DESTAREAW_OFF);
- writel(area->height - 1, regbase + GE_DESTAREAH_OFF);
-
- writel(0xcc, regbase + GE_ROPCODE_OFF);
- writel(1, regbase + GE_COMMAND_OFF);
- writel(1, regbase + GE_FIRE_OFF);
+ (p->var.bits_per_pixel > 8 ? 1 : 0), regbase + GE_COLOR_DEPTH);
+
+ writel(p->fix.smem_start, regbase + GE_SRC_BADDR);
+ writel(p->var.xres_virtual - 1, regbase + GE_SRC_DISP_W);
+ writel(p->var.yres_virtual - 1, regbase + GE_SRC_DISP_H);
+ writel(area->sx, regbase + GE_SRC_X_START);
+ writel(area->sy, regbase + GE_SRC_Y_START);
+ writel(area->width - 1, regbase + GE_SRC_WIDTH);
+ writel(area->height - 1, regbase + GE_SRC_HEIGHT);
+
+ writel(p->fix.smem_start, regbase + GE_DES_BADDR);
+ writel(p->var.xres_virtual - 1, regbase + GE_DES_DISP_W);
+ writel(p->var.yres_virtual - 1, regbase + GE_DES_DISP_H);
+ writel(area->dx, regbase + GE_DES_X_START);
+ writel(area->dy, regbase + GE_DES_Y_START);
+ writel(area->width - 1, regbase + GE_DES_WIDTH);
+ writel(area->height - 1, regbase + GE_DES_HEIGHT);
+
+ writel(0xcc, regbase + GE_ROP_CODE);
+ writel(1, regbase + GE_COMMAND);
+ writel(1, regbase + GE_FIRE);
}
EXPORT_SYMBOL_GPL(wmt_ge_copyarea);
int wmt_ge_sync(struct fb_info *p)
{
int loops = 5000000;
- while ((readl(regbase + GE_STATUS_OFF) & 4) && --loops)
+ while ((readl(regbase + GE_STATUS) & 4) && --loops)
cpu_relax();
return loops > 0 ? 0 : -EBUSY;
}
@@ -146,7 +306,7 @@ static int wmt_ge_rops_probe(struct platform_device *pdev)
return -EBUSY;
}
- writel(1, regbase + GE_ENABLE_OFF);
+ writel(1, regbase + GE_ENABLE);
printk(KERN_INFO "Enabled support for WMT GE raster acceleration\n");
return 0;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/4] fb: vt8500: Move register defines inside driver
From: Tony Prisk @ 2013-05-18 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1368868514-18975-1-git-send-email-linux@prisktech.co.nz>
The #defines in wm8505fb_regs.h are only used in the wm8505fb driver,
and don't need to be visible outside.
Move the defines into the driver and remove the header.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
drivers/video/wm8505fb.c | 25 +++++++++++++-
drivers/video/wm8505fb_regs.h | 76 -----------------------------------------
2 files changed, 24 insertions(+), 77 deletions(-)
delete mode 100644 drivers/video/wm8505fb_regs.h
diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
index 01f9ace..f824af8 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -34,11 +34,34 @@
#include <linux/wait.h>
#include <video/of_display_timing.h>
-#include "wm8505fb_regs.h"
#include "wmt_ge_rops.h"
#define DRIVER_NAME "wm8505-fb"
+#define WMT_GOVR_COLORSPACE1 0x030
+#define WMT_GOVR_MIF_ENABLE 0x080
+#define WMT_GOVR_FBADDR 0x090
+#define WMT_GOVR_FBADDR1 0x094
+#define WMT_GOVR_XRES 0x098
+#define WMT_GOVR_XRES_VIRTUAL 0x09c
+#define WMT_GOVR_YPAN 0x0a0
+#define WMT_GOVR_XPAN 0x0a4
+#define WMT_GOVR_FHI 0x0a8
+#define WMT_GOVR_REG_UPDATE 0x0e4
+#define WMT_GOVR_TG 0x100
+#define WMT_GOVR_TIMING_H_ALL 0x108
+#define WMT_GOVR_TIMING_V_ALL 0x10c
+#define WMT_GOVR_TIMING_V_START 0x110
+#define WMT_GOVR_TIMING_V_END 0x114
+#define WMT_GOVR_TIMING_H_START 0x118
+#define WMT_GOVR_TIMING_H_END 0x11c
+#define WMT_GOVR_TIMING_V_SYNC 0x128
+#define WMT_GOVR_TIMING_H_SYNC 0x12c
+#define WMT_GOVR_DVO_SET 0x148
+#define WMT_GOVR_CONTRAST 0x1b8
+#define WMT_GOVR_BRGHTNESS 0x1bc
+#define WMT_GOVR_COLORSPACE 0x1e4
+
#define to_wm8505fb_info(__info) container_of(__info, \
struct wm8505fb_info, fb)
struct wm8505fb_info {
diff --git a/drivers/video/wm8505fb_regs.h b/drivers/video/wm8505fb_regs.h
deleted file mode 100644
index 4dd4166..0000000
--- a/drivers/video/wm8505fb_regs.h
+++ /dev/null
@@ -1,76 +0,0 @@
-/*
- * GOVR registers list for WM8505 chips
- *
- * Copyright (C) 2010 Ed Spiridonov <edo.rus@gmail.com>
- * Based on VIA/WonderMedia wm8510-govrh-reg.h
- * http://github.com/projectgus/kernel_wm8505/blob/wm8505_2.6.29/
- * drivers/video/wmt/register/wm8510/wm8510-govrh-reg.h
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- */
-
-#ifndef _WM8505FB_REGS_H
-#define _WM8505FB_REGS_H
-
-/*
- * Color space select register, default value 0x1c
- * BIT0 GOVRH_DVO_YUV2RGB_ENABLE
- * BIT1 GOVRH_VGA_YUV2RGB_ENABLE
- * BIT2 GOVRH_RGB_MODE
- * BIT3 GOVRH_DAC_CLKINV
- * BIT4 GOVRH_BLANK_ZERO
- */
-#define WMT_GOVR_COLORSPACE 0x1e4
-/*
- * Another colorspace select register, default value 1
- * BIT0 GOVRH_DVO_RGB
- * BIT1 GOVRH_DVO_YUV422
- */
-#define WMT_GOVR_COLORSPACE1 0x30
-
-#define WMT_GOVR_CONTRAST 0x1b8
-#define WMT_GOVR_BRGHTNESS 0x1bc /* incompatible with RGB? */
-
-/* Framubeffer address */
-#define WMT_GOVR_FBADDR 0x90
-#define WMT_GOVR_FBADDR1 0x94 /* UV offset in YUV mode */
-
-/* Offset of visible window */
-#define WMT_GOVR_XPAN 0xa4
-#define WMT_GOVR_YPAN 0xa0
-
-#define WMT_GOVR_XRES 0x98
-#define WMT_GOVR_XRES_VIRTUAL 0x9c
-
-#define WMT_GOVR_MIF_ENABLE 0x80
-#define WMT_GOVR_FHI 0xa8
-#define WMT_GOVR_REG_UPDATE 0xe4
-
-/*
- * BIT0 GOVRH_DVO_OUTWIDTH
- * BIT1 GOVRH_DVO_SYNC_POLAR
- * BIT2 GOVRH_DVO_ENABLE
- */
-#define WMT_GOVR_DVO_SET 0x148
-
-/* Timing generator? */
-#define WMT_GOVR_TG 0x100
-
-/* Timings */
-#define WMT_GOVR_TIMING_H_ALL 0x108
-#define WMT_GOVR_TIMING_V_ALL 0x10c
-#define WMT_GOVR_TIMING_V_START 0x110
-#define WMT_GOVR_TIMING_V_END 0x114
-#define WMT_GOVR_TIMING_H_START 0x118
-#define WMT_GOVR_TIMING_H_END 0x11c
-#define WMT_GOVR_TIMING_V_SYNC 0x128
-#define WMT_GOVR_TIMING_H_SYNC 0x12c
-
-#endif /* _WM8505FB_REGS_H */
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/4] FB updates for 3.11
From: Tony Prisk @ 2013-05-18 9:15 UTC (permalink / raw)
To: linux-arm-kernel
Patch #1 - Move register defines inside the driver and drop the header.
Patch #2 - Convert the register defines to use the vendor preferred names.
Patch #3 - Add a device clock to wm8505fb. Without it, only the uboot
initialized resolution is supported.
Patch #4 - Add support for the VGA output found on the APC8750 board.
Tony Prisk (4):
fb: vt8500: Move register defines inside driver
fb: vt8500: Convert to use vendor register names
fb: vt8500: Require a device clock for wm8505fb driver
fb: vt8500: Add VGA output support to wm8505fb driver.
.../devicetree/bindings/video/wm,wm8505-fb.txt | 9 +-
drivers/video/wm8505fb.c | 195 ++++++++++++--
drivers/video/wm8505fb_regs.h | 76 ------
drivers/video/wmt_ge_rops.c | 280 +++++++++++++++-----
4 files changed, 394 insertions(+), 166 deletions(-)
delete mode 100644 drivers/video/wm8505fb_regs.h
--
1.7.9.5
^ permalink raw reply
* [PATCH v7, part3 07/16] mm, acornfb: use free_reserved_area() to simplify code
From: Jiang Liu @ 2013-05-17 15:45 UTC (permalink / raw)
To: Andrew Morton
Cc: Jiang Liu, David Rientjes, Wen Congyang, Mel Gorman, Minchan Kim,
KAMEZAWA Hiroyuki, Michal Hocko, James Bottomley, Sergei Shtylyov,
David Howells, Mark Salter, Jianguo Wu, linux-mm, linux-arch,
linux-kernel, Florian Tobias Schandinat, linux-fbdev
In-Reply-To: <1368805518-2634-1-git-send-email-jiang.liu@huawei.com>
Use common help function free_reserved_area() to simplify code.
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/video/acornfb.c | 28 ++--------------------------
1 file changed, 2 insertions(+), 26 deletions(-)
diff --git a/drivers/video/acornfb.c b/drivers/video/acornfb.c
index 6488a73..344f2bb 100644
--- a/drivers/video/acornfb.c
+++ b/drivers/video/acornfb.c
@@ -1188,32 +1188,8 @@ static int acornfb_detect_monitortype(void)
static inline void
free_unused_pages(unsigned int virtual_start, unsigned int virtual_end)
{
- int mb_freed = 0;
-
- /*
- * Align addresses
- */
- virtual_start = PAGE_ALIGN(virtual_start);
- virtual_end = PAGE_ALIGN(virtual_end);
-
- while (virtual_start < virtual_end) {
- struct page *page;
-
- /*
- * Clear page reserved bit,
- * set count to 1, and free
- * the page.
- */
- page = virt_to_page(virtual_start);
- ClearPageReserved(page);
- init_page_count(page);
- free_page(virtual_start);
-
- virtual_start += PAGE_SIZE;
- mb_freed += PAGE_SIZE / 1024;
- }
-
- printk("acornfb: freed %dK memory\n", mb_freed);
+ free_reserved_area(virtual_start, PAGE_ALIGN(virtual_end),
+ -1, "acornfb");
}
static int acornfb_probe(struct platform_device *dev)
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH 1/2] video: exynos_dp: Add parsing of gpios pins to exynos-dp driver
From: Tomasz Figa @ 2013-05-17 12:29 UTC (permalink / raw)
To: jg1.han
Cc: Vikas Sajjan, linux-samsung-soc@vger.kernel.org,
김국진, devicetree-discuss@lists.ozlabs.org,
patches@linaro.org, linaro-kernel@lists.linaro.org,
rpurdie@rpsys.net, FlorianSchandinat@gmx.de,
linux-fbdev@vger.kernel.org
In-Reply-To: <26364319.123371368669839202.JavaMail.weblogic@epml12>
Hi Jingoo,
On Thursday 16 of May 2013 02:03:59 한진구 wrote:
> Tuesday, May 14, 2013 11:17 PM, Vikas Sajjan wrote:
>
> >
> > Hi Vikas,
> >
> > On Tuesday 14 of May 2013 18:25:51 Vikas Sajjan wrote:
> >
> > > Adds GPIO parsing functionality for "LCD backlight" and "LCD enable"
> > > GPIO pins of exynos dp controller.
> > >
> > >
> > >
> > > Signed-off-by: Vikas Sajjan <vikas.sajjan@linaro.org>
> > > ---
> > >
> > > drivers/video/exynos/exynos_dp_core.c | 45
> > >
> > > +++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+)
> > >
> > >
> >
> >
> > I don't think that Exynos DP driver is right place for such code.
> > Backlight
and LCD drivers are responsible for backlight and LCD power
> > control using backlight and LCD subsystems.
> >
> > IMHO the correct solution would be to either extend existing
> > backlight/lcd
> > drivers found in drivers/video/backlight to support direct GPIO control
> > and
parse GPIO pins from device tree or create new gpio_bl and gpio_lcd
> > drivers.
>
> Hi Vikas Sajian,
>
> I agree with Tomasz Figa's opinion.
> Backlight/LCD framework should be used.
> eDP panel backlight on SMDK5210 board can be controlled by PWM;
> thus, pwm-backlight driver should be used.
> Also, eDP panel reset pin should be controlled by using
> platform-lcd driver.
>
>
> >
> > CCing Richard, Florian and linux-fbdev.
>
>
> Also, I have been doing backlight reviews instead of Richard,
> please do CC'ing me.
OK. I used get_maintainers script, but it seems like the result was a bit off
in this case. Will remember for future.
Best regards,
--
Tomasz Figa
Linux Kernel Developer
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* Re: Introduce a new helper framework for buffer synchronization
From: Daniel Vetter @ 2013-05-17 4:19 UTC (permalink / raw)
To: Rob Clark
Cc: Inki Dae, linux-fbdev, YoungJun Cho, Kyungmin Park, myungjoo.ham,
DRI mailing list, linux-arm-kernel@lists.infradead.org,
linux-media@vger.kernel.org
In-Reply-To: <CAF6AEGuBexKUpTwm9cjGjkxCTKgEaDhAakeP0RN=rtLS6Qy=Mg@mail.gmail.com>
On Wed, May 15, 2013 at 4:06 PM, Rob Clark <robdclark@gmail.com> wrote:
> So while it seems nice and orthogonal/clean to couple cache and
> synchronization and handle dma->cpu and cpu->cpu and cpu->dma in the
> same generic way, but I think in practice we have to make things more
> complex than they otherwise need to be to do this. Otherwise I think
> we'll be having problems with badly behaved or crashing userspace.
I haven't read through the entire thread careful but imo this is very
important. If we add a fence interface which allows userspace to block
dma this is a no-go. The only thing we need is to sync up with all
outstanding dma operations and flush caches for cpu access. If broken
userspace starts to issue new dma (or multiple thread stomp onto each
another) that's not a problem dma fences/syncpoints should try to
solve. This way we can concentrate on solving the (already
challenging) device-to-device sync issues without additional
complexities which cpu->cpu sync would impose.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH v3 6/9] radeon: Switch to arch_phys_wc_add and add a missing ..._del
From: Andy Lutomirski @ 2013-05-16 21:00 UTC (permalink / raw)
To: Jerome Glisse
Cc: Alex Deucher, linux-kernel, dri-devel, linux-fbdev, Daniel Vetter,
Dave Airlie
In-Reply-To: <CAH3drwY0vVGnf05v-coSmS4OQyHuufycLojEn9que6iL_r3AUw@mail.gmail.com>
On Thu, May 16, 2013 at 6:50 AM, Jerome Glisse <j.glisse@gmail.com> wrote:
> On Wed, May 15, 2013 at 2:22 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Wed, May 15, 2013 at 7:49 AM, Jerome Glisse <j.glisse@gmail.com> wrote:
>>> On Tue, May 14, 2013 at 5:35 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>>> On Tue, May 14, 2013 at 6:37 AM, Jerome Glisse <j.glisse@gmail.com> wrote:
>>>>> On Tue, May 14, 2013 at 8:58 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
>>>>>> On Mon, May 13, 2013 at 7:58 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>>>>>> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>>>>>>> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
>>>>>>
>>>>>> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>>>>>
>>>>> I believe it will break something but we could deal with the fallout
>>>>> once it happens.
>>>>
>>>> FWIW, I'm running with this code on my machine right now using the
>>>> radeon driver. Everything seems fine. If I build without MTRRs and
>>>> without PAT, though, graphics are slow (as expected). So I think
>>>> everything's okay.
>>>>
>>>> --Andy
>>>
>>> I am worried on p4 where i last see issue with that notably with agp.
>>
>> Do you remember any details? It looks like PAT is enabled on Pentium
>> 4 (i.e. famliy 0xF).
>>
>> --Andy
>
> No i don't, i think it was some pat errata on those about non real ram
> address and with agp. Memory is fuzzy. I might have time in couple of
> week to plug back my p4 and see how it behave.
Hmm. I couldn't find any PAT errata related to AGP.
Is it possible that the issue was that, if there was no MTRR covering
the AGP aperture, that the mapping ended up as writeback? If so, I
fixed that in this series.
In any case, if you see any problems, please let me know.
--Andy
^ permalink raw reply
* Re: [PATCH v3 6/9] radeon: Switch to arch_phys_wc_add and add a missing ..._del
From: Jerome Glisse @ 2013-05-16 13:50 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Alex Deucher, linux-kernel, dri-devel, linux-fbdev, Daniel Vetter,
Dave Airlie
In-Reply-To: <CALCETrXA-nbdDEv1TyU9e4mcGZzAoCTTDX33M1o31rZkgHHTFg@mail.gmail.com>
On Wed, May 15, 2013 at 2:22 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Wed, May 15, 2013 at 7:49 AM, Jerome Glisse <j.glisse@gmail.com> wrote:
>> On Tue, May 14, 2013 at 5:35 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>> On Tue, May 14, 2013 at 6:37 AM, Jerome Glisse <j.glisse@gmail.com> wrote:
>>>> On Tue, May 14, 2013 at 8:58 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
>>>>> On Mon, May 13, 2013 at 7:58 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>>>>> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>>>>>> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
>>>>>
>>>>> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>>>>
>>>> I believe it will break something but we could deal with the fallout
>>>> once it happens.
>>>
>>> FWIW, I'm running with this code on my machine right now using the
>>> radeon driver. Everything seems fine. If I build without MTRRs and
>>> without PAT, though, graphics are slow (as expected). So I think
>>> everything's okay.
>>>
>>> --Andy
>>
>> I am worried on p4 where i last see issue with that notably with agp.
>
> Do you remember any details? It looks like PAT is enabled on Pentium
> 4 (i.e. famliy 0xF).
>
> --Andy
No i don't, i think it was some pat errata on those about non real ram
address and with agp. Memory is fuzzy. I might have time in couple of
week to plug back my p4 and see how it behave.
Cheers,
Jerome
^ permalink raw reply
* [PATCH 2/2] videomode: implement public of_get_display_timing()
From: Tomi Valkeinen @ 2013-05-16 13:00 UTC (permalink / raw)
To: linux-fbdev, dri-devel; +Cc: Tomi Valkeinen, Steffen Trumtrar, Laurent Pinchart
In-Reply-To: <1368709202-1056-1-git-send-email-tomi.valkeinen@ti.com>
The current of_get_display_timings() reads multiple display timings,
allocating memory for the entries. However, most of the time when
parsing display timings from DT data is needed, there's only one display
timing as it's not common for a LCD panel to support multiple videomodes.
This patch creates a new function:
int of_get_display_timing(struct device_node *np, const char *name,
struct display_timing *dt);
which can be used to parse a single display timing entry from the given
node name.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
---
drivers/video/of_display_timing.c | 33 ++++++++++++++++++++++++++++++---
include/video/of_display_timing.h | 2 ++
2 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/drivers/video/of_display_timing.c b/drivers/video/of_display_timing.c
index 0e81023..9c0f17b 100644
--- a/drivers/video/of_display_timing.c
+++ b/drivers/video/of_display_timing.c
@@ -53,10 +53,10 @@ static int parse_timing_property(struct device_node *np, const char *name,
}
/**
- * of_get_display_timing - parse display_timing entry from device_node
+ * of_parse_display_timing - parse display_timing entry from device_node
* @np: device_node with the properties
**/
-static int of_get_display_timing(struct device_node *np,
+static int of_parse_display_timing(struct device_node *np,
struct display_timing *dt)
{
u32 val = 0;
@@ -103,6 +103,33 @@ static int of_get_display_timing(struct device_node *np,
}
/**
+ * of_get_display_timing - parse a display_timing entry
+ * @np: device_node with the timing subnode
+ * @name: name of the timing node
+ * @dt: display_timing struct to fill
+ **/
+int of_get_display_timing(struct device_node *np, const char *name,
+ struct display_timing *dt)
+{
+ struct device_node *timing_np;
+
+ if (!np) {
+ pr_err("%s: no devicenode given\n", of_node_full_name(np));
+ return -EINVAL;
+ }
+
+ timing_np = of_find_node_by_name(np, name);
+ if (!timing_np) {
+ pr_err("%s: could not find node '%s'\n",
+ of_node_full_name(np), name);
+ return -ENOENT;
+ }
+
+ return of_parse_display_timing(timing_np, dt);
+}
+EXPORT_SYMBOL_GPL(of_get_display_timing);
+
+/**
* of_get_display_timings - parse all display_timing entries from a device_node
* @np: device_node with the subnodes
**/
@@ -177,7 +204,7 @@ struct display_timings *of_get_display_timings(struct device_node *np)
goto timingfail;
}
- r = of_get_display_timing(entry, dt);
+ r = of_parse_display_timing(entry, dt);
if (r) {
/*
* to not encourage wrong devicetrees, fail in case of
diff --git a/include/video/of_display_timing.h b/include/video/of_display_timing.h
index 8016eb7..6562ad9 100644
--- a/include/video/of_display_timing.h
+++ b/include/video/of_display_timing.h
@@ -14,6 +14,8 @@ struct display_timings;
#define OF_USE_NATIVE_MODE -1
+int of_get_display_timing(struct device_node *np, const char *name,
+ struct display_timing *dt);
struct display_timings *of_get_display_timings(struct device_node *np);
int of_display_timings_exist(struct device_node *np);
--
1.8.1.2
^ permalink raw reply related
* [PATCH 1/2] videomode: don't allocate mem in of_get_display_timing()
From: Tomi Valkeinen @ 2013-05-16 13:00 UTC (permalink / raw)
To: linux-fbdev, dri-devel; +Cc: Tomi Valkeinen, Steffen Trumtrar, Laurent Pinchart
Move the allocation of display_timing memory from of_get_display_timing() to
of_get_display_timings(). This allows us to use of_get_display_timing()
in a way that doesn't require dynamic memory allocation.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
---
drivers/video/of_display_timing.c | 26 ++++++++++++++------------
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/video/of_display_timing.c b/drivers/video/of_display_timing.c
index 56009bc..0e81023 100644
--- a/drivers/video/of_display_timing.c
+++ b/drivers/video/of_display_timing.c
@@ -56,18 +56,13 @@ static int parse_timing_property(struct device_node *np, const char *name,
* of_get_display_timing - parse display_timing entry from device_node
* @np: device_node with the properties
**/
-static struct display_timing *of_get_display_timing(struct device_node *np)
+static int of_get_display_timing(struct device_node *np,
+ struct display_timing *dt)
{
- struct display_timing *dt;
u32 val = 0;
int ret = 0;
- dt = kzalloc(sizeof(*dt), GFP_KERNEL);
- if (!dt) {
- pr_err("%s: could not allocate display_timing struct\n",
- of_node_full_name(np));
- return NULL;
- }
+ memset(dt, 0, sizeof(*dt));
ret |= parse_timing_property(np, "hback-porch", &dt->hback_porch);
ret |= parse_timing_property(np, "hfront-porch", &dt->hfront_porch);
@@ -101,11 +96,10 @@ static struct display_timing *of_get_display_timing(struct device_node *np)
if (ret) {
pr_err("%s: error reading timing properties\n",
of_node_full_name(np));
- kfree(dt);
- return NULL;
+ return -EINVAL;
}
- return dt;
+ return 0;
}
/**
@@ -174,9 +168,17 @@ struct display_timings *of_get_display_timings(struct device_node *np)
for_each_child_of_node(timings_np, entry) {
struct display_timing *dt;
+ int r;
- dt = of_get_display_timing(entry);
+ dt = kzalloc(sizeof(*dt), GFP_KERNEL);
if (!dt) {
+ pr_err("%s: could not allocate display_timing struct\n",
+ of_node_full_name(np));
+ goto timingfail;
+ }
+
+ r = of_get_display_timing(entry, dt);
+ if (r) {
/*
* to not encourage wrong devicetrees, fail in case of
* an error
--
1.8.1.2
^ permalink raw reply related
* RE: fb driver for logiCVC
From: Davor Joja @ 2013-05-16 11:51 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Bruno Prémont, linux-kernel, Linux Fbdev development list
In-Reply-To: <CAMuHMdUW-tVY6=Bu9mabKrkNJsTxJM+Umo6jjcnXpWpzh_5AVw@mail.gmail.com>
VGhhbmtzIEdlZXJ0IQ0KDQpSZWdhcmRzLA0KRGF2b3INCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS0NCkZyb206IGdlZXJ0LnV5dHRlcmhvZXZlbkBnbWFpbC5jb20gW21haWx0bzpnZWVydC51
eXR0ZXJob2V2ZW5AZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgR2VlcnQgVXl0dGVyaG9ldmVuDQpT
ZW50OiBUaHVyc2RheSwgTWF5IDE2LCAyMDEzIDE6MjMgUE0NClRvOiBEYXZvciBKb2phDQpDYzog
QnJ1bm8gUHLDqW1vbnQ7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IExpbnV4IEZiZGV2
IGRldmVsb3BtZW50IGxpc3QNClN1YmplY3Q6IFJlOiBmYiBkcml2ZXIgZm9yIGxvZ2lDVkMNCg0K
T24gVGh1LCBNYXkgMTYsIDIwMTMgYXQgMTI6MzUgUE0sIERhdm9yIEpvamEgPERhdm9yLkpvamFA
bG9naWNicmlja3MuY29tPiB3cm90ZToNCj4gVW5mb3J0dW5hdGVseSwgSSBoYXZlIHRoaXMgZHJp
dmVyIG9uIG1lbnRpb25lZCBnaXQgb25seSBmb3IgZmV3IHdlZWtzLCBzbyB0aGVyZSBpcyBubyB1
c2FibGUgaGlzdG9yeS4NCj4gU2luY2UgdGhpcyBpcyBuZXcgZHJpdmVyLCB0ZXN0ZWQgYW5kIGZ1
bmN0aW9uYWwgKG9uIGtlcm5lbCAzLjgpLCB3aXRob3V0IGdpdCBoaXN0b3J5IGFzIHN0YXRlZCBh
Ym92ZSwgZG8geW91IGhhdmUgaWRlYSBob3cgdG8gYnJlYWsgaXQgdG8gc21hbGxlciBwaWVjZXM/
IEkgY2FuIG9ubHkgdGhpbmsgb2ZmIGFzIG9uZSBiaWcgcGF0Y2ggYWdhaW5zdCAzLjgueCB2ZXJz
aW9uLg0KPiBUaGF0IGNvdWxkIGJlIGFjY2VwdGVkIGZvciBuZXcgZHJpdmVyPw0KDQpBIHNpbmds
ZSBwYXRjaCBpcyBPSyBmb3IgYSBuZXcgZHJpdmVyLg0KDQpHcntvZXRqZSxlZXRpbmd9cywNCg0K
ICAgICAgICAgICAgICAgICAgICAgICAgR2VlcnQNCg0KLS0NCkdlZXJ0IFV5dHRlcmhvZXZlbiAt
LSBUaGVyZSdzIGxvdHMgb2YgTGludXggYmV5b25kIGlhMzIgLS0gZ2VlcnRAbGludXgtbTY4ay5v
cmcNCg0KSW4gcGVyc29uYWwgY29udmVyc2F0aW9ucyB3aXRoIHRlY2huaWNhbCBwZW9wbGUsIEkg
Y2FsbCBteXNlbGYgYSBoYWNrZXIuIEJ1dCB3aGVuIEknbSB0YWxraW5nIHRvIGpvdXJuYWxpc3Rz
IEkganVzdCBzYXkgInByb2dyYW1tZXIiIG9yIHNvbWV0aGluZyBsaWtlIHRoYXQuDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIC0tIExpbnVzIFRvcnZhbGRzDQo
^ permalink raw reply
* Re: fb driver for logiCVC
From: Geert Uytterhoeven @ 2013-05-16 11:23 UTC (permalink / raw)
To: Davor Joja
Cc: Bruno Prémont, linux-kernel@vger.kernel.org,
Linux Fbdev development list
In-Reply-To: <ABCSCiTtUDvkm6WeI5J00000073@abc.logicbricks.com>
On Thu, May 16, 2013 at 12:35 PM, Davor Joja <Davor.Joja@logicbricks.com> wrote:
> Unfortunately, I have this driver on mentioned git only for few weeks, so there is no usable history.
> Since this is new driver, tested and functional (on kernel 3.8), without git history as stated above, do you have idea how to break it to smaller pieces? I can only think off as one big patch against 3.8.x version.
> That could be accepted for new driver?
A single patch is OK for a new driver.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
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