* Re: [PATCH] video: xilinxfb: Fix compilation warning
From: Michal Simek @ 2013-07-24 8:24 UTC (permalink / raw)
To: Jingoo Han
Cc: 'Michal Simek',
'Jean-Christophe Plagniol-Villard',
'Tomi Valkeinen', linux-fbdev, linux-kernel,
'Stepan Moskovchenko'
In-Reply-To: <003a01ce8845$06df46e0$149dd4a0$@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 3494 bytes --]
On 07/24/2013 10:08 AM, Jingoo Han wrote:
> On Wednesday, July 24, 2013 4:42 PM, Michal Simek wrote:
>> On 07/24/2013 09:18 AM, Michal Simek wrote:
>>> On 07/24/2013 08:00 AM, Jingoo Han wrote:
>>>> On Wednesday, July 24, 2013 2:32 PM, Michal Simek wrote:
>>>>>
>>>>> regs_phys is phys_addr_t (u32 or u64).
>>>>> Lets retype it to u64.
>>>>>
>>>>> Fixes compilation warning introduced by:
>>>>> video: xilinxfb: Use drvdata->regs_phys instead of physaddr
>>>>> (sha1: c88fafef0135e1e1c3e23c3e32ccbeeabc587f81)
>>>>
>>>> CC'ed Stepan Moskovchenko
>>>>
>>>>
>>>> phys_addr_t is defined as below:
>>>>
>>>> #ifdef CONFIG_PHYS_ADDR_T_64BIT
>>>> typedef u64 phys_addr_t;
>>>> #else
>>>> typedef u32 phys_addr_t;
>>>> #endif
>>>>
>>>> According to 'Documentation/printk-formats.txt',
>>>> Physical addresses:
>>>> %pa 0x01234567 or 0x0123456789abcdef
>>>> For printing a phys_addr_t type (and its derivatives, such as
>>>> resource_size_t) which can vary based on build options, regardless of
>>>> the width of the CPU data path. Passed by reference.
>>>>
>>>> Thus, '%pa' option looks proper, instead of casting (unsigned long long).
>>>>
>>>> dev_dbg(dev, "regs: phys=%pa, virt=%p\n", drvdata->regs_phys,
>>>> drvdata->regs);
>>>>
>>>
>>> Ah. Wasn't aware about that.
>>> Will retest.
>>
>> On ppc44x_defconfig
>>
>> $ powerpc-unknown-linux-gnu-gcc --version
>> powerpc-unknown-linux-gnu-gcc (crosstool-NG-svn_unknown@20110406.104745) 4.3.2
>>
>> This fix
>> diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
>> index 79175a6..a9a1167 100644
>> --- a/drivers/video/xilinxfb.c
>> +++ b/drivers/video/xilinxfb.c
>> @@ -341,12 +341,12 @@ static int xilinxfb_assign(struct platform_device *pdev,
>>
>> if (drvdata->flags & BUS_ACCESS_FLAG) {
>> /* Put a banner in the log (for DEBUG) */
>> - dev_dbg(dev, "regs: phys=%llx, virt=%p\n",
>> - (unsigned long long)drvdata->regs_phys, drvdata->regs);
>> + dev_dbg(dev, "regs: phys=%pa, virt=%p\n",
>> + drvdata->regs_phys, drvdata->regs);
>> }
>> /* Put a banner in the log (for DEBUG) */
>> - dev_dbg(dev, "fb: phys=%llx, virt=%p, size=%x\n",
>> - (unsigned long long)drvdata->fb_phys, drvdata->fb_virt, fbsize);
>> + dev_dbg(dev, "fb: phys=%pa, virt=%p, size=%x\n",
>> + drvdata->fb_phys, drvdata->fb_virt, fbsize);
>>
>
> Hi Michal Simek,
>
> Just now, I tested that the same problem happens on ARM config.
> Also, I solved it by adding '&' operator.
>
> '&' operator is necessary as below:
>
> dev_dbg(dev, "regs: phys=%pa, virt=%p\n",
> &drvdata->regs_phys, drvdata->regs);
> ^^^
>
> dev_dbg(dev, "fb: phys=%pa, virt=%p, size=%x\n",
> &drvdata->fb_phys, drvdata->fb_virt, fbsize);
> ^^^
ok.
The truth is as I said there are just 5 files in the whole kernel
which are using %pa and if %pa is right way to go we should
probably fix all off them.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply
* Re: [PATCH 01/15] drivers: phy: add generic PHY framework
From: Arnd Bergmann @ 2013-07-24 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5977067.8rykRgjgre@flatron>
On Tuesday 23 July 2013, Tomasz Figa wrote:
> On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote:
> > On Tue, 23 Jul 2013, Tomasz Figa wrote:
> > > Where would you want to have those phy_address arrays stored? There
> > > are no board files when booting with DT. Not even saying that you
> > > don't need to use any hacky schemes like this when you have DT that
> > > nicely specifies relations between devices.
> >
> > If everybody agrees DT has a nice scheme for specifying relations
> > between devices, why not use that same scheme in the PHY core?
>
> It is already used, for cases when consumer device has a DT node attached.
> In non-DT case this kind lookup translates loosely to something that is
> being done in regulator framework - you can't bind devices by pointers,
> because you don't have those pointers, so you need to use device names.
>
Sorry for jumping in to the middle of the discussion, but why does a *new*
framework even bother defining an interface for board files?
Can't we just drop any interfaces for platform data passing in the phy
framework and put the burden of adding those to anyone who actually needs
them? All the platforms we are concerned with here (exynos and omap,
plus new platforms) can be booted using DT anyway.
Arnd
^ permalink raw reply
* [PATCH] driver/vga16fb.c: remove the unused variable "dev" of function vga16fb_destroy()
From: Gu Zheng @ 2013-07-25 3:37 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen; +Cc: linux-fbdev, linux-kernel
Commit e21d2170f36602ae2708 removed the unnecessary platform_set_drvdata(),
but left the variable "dev" unused, delete it.
Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
---
drivers/video/vga16fb.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/video/vga16fb.c b/drivers/video/vga16fb.c
index 830ded4..2827333 100644
--- a/drivers/video/vga16fb.c
+++ b/drivers/video/vga16fb.c
@@ -1265,7 +1265,6 @@ static void vga16fb_imageblit(struct fb_info *info, const struct fb_image *image
static void vga16fb_destroy(struct fb_info *info)
{
- struct platform_device *dev = container_of(info->device, struct platform_device, dev);
iounmap(info->screen_base);
fb_dealloc_cmap(&info->cmap);
/* XXX unshare VGA regions */
--
1.7.7
^ permalink raw reply related
* Re: [PATCH 01/15] drivers: phy: add generic PHY framework
From: Arnd Bergmann @ 2013-07-25 7:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51F0B373.5050907@ti.com>
On Thursday 25 July 2013, Kishon Vijay Abraham I wrote:
> On Thursday 25 July 2013 12:02 AM, Arnd Bergmann wrote:
> > On Tuesday 23 July 2013, Tomasz Figa wrote:
> >> On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote:
> >>> On Tue, 23 Jul 2013, Tomasz Figa wrote:
> >>>> Where would you want to have those phy_address arrays stored? There
> >>>> are no board files when booting with DT. Not even saying that you
> >>>> don't need to use any hacky schemes like this when you have DT that
> >>>> nicely specifies relations between devices.
> >>>
> >>> If everybody agrees DT has a nice scheme for specifying relations
> >>> between devices, why not use that same scheme in the PHY core?
> >>
> >> It is already used, for cases when consumer device has a DT node attached.
> >> In non-DT case this kind lookup translates loosely to something that is
> >> being done in regulator framework - you can't bind devices by pointers,
> >> because you don't have those pointers, so you need to use device names.
> >>
> >
> > Sorry for jumping in to the middle of the discussion, but why does a new
> > framework even bother defining an interface for board files?
> >
> > Can't we just drop any interfaces for platform data passing in the phy
> > framework and put the burden of adding those to anyone who actually needs
> > them? All the platforms we are concerned with here (exynos and omap,
> > plus new platforms) can be booted using DT anyway.
>
> The OMAP3 platforms still needs to be supported for non-dt :-s
Can't you leave the existing PHY handling for legacy OMAP3 USB PHY
until they are all converted? I don't expect that to take a long time
now that the OMAP4 board files have been removed. Are there still
drivers without DT bindings that hold up the removal of the OMAP3
board files?
Otherwise I'd suggest delaying the phy subsystem by another merge window,
until that is resolved.
Arnd
^ permalink raw reply
* Re: [PATCH 01/15] drivers: phy: add generic PHY framework
From: Sylwester Nawrocki @ 2013-07-25 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201307242032.03597.arnd@arndb.de>
On 07/24/2013 08:32 PM, Arnd Bergmann wrote:
> On Tuesday 23 July 2013, Tomasz Figa wrote:
>> On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote:
>>> On Tue, 23 Jul 2013, Tomasz Figa wrote:
>>>> Where would you want to have those phy_address arrays stored? There
>>>> are no board files when booting with DT. Not even saying that you
>>>> don't need to use any hacky schemes like this when you have DT that
>>>> nicely specifies relations between devices.
>>>
>>> If everybody agrees DT has a nice scheme for specifying relations
>>> between devices, why not use that same scheme in the PHY core?
>>
>> It is already used, for cases when consumer device has a DT node attached.
>> In non-DT case this kind lookup translates loosely to something that is
>> being done in regulator framework - you can't bind devices by pointers,
>> because you don't have those pointers, so you need to use device names.
>>
>
> Sorry for jumping in to the middle of the discussion, but why does a *new*
> framework even bother defining an interface for board files?
>
> Can't we just drop any interfaces for platform data passing in the phy
> framework and put the burden of adding those to anyone who actually needs
> them? All the platforms we are concerned with here (exynos and omap,
> plus new platforms) can be booted using DT anyway.
Indeed, I was also a bit surprised we still need non-dt support, since
migration to this generic PHY framework in case of exynos was solely
part of migration of the whole platform to DT.
Two of the drivers that are being converted are also used on s5pv210,
but there is currently no boards in mainline that would use devices
covered by those drivers and s5pv210 will very likely get DT support
in v3.13 anyway.
But it seems omap still needs non-dt support in the PHY framework.
---
Thanks,
Sylwester
^ permalink raw reply
* Re: [PATCH 01/15] drivers: phy: add generic PHY framework
From: Mark Brown @ 2013-07-25 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201307242032.03597.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 850 bytes --]
On Wed, Jul 24, 2013 at 08:32:03PM +0200, Arnd Bergmann wrote:
> Sorry for jumping in to the middle of the discussion, but why does a *new*
> framework even bother defining an interface for board files?
> Can't we just drop any interfaces for platform data passing in the phy
> framework and put the burden of adding those to anyone who actually needs
> them? All the platforms we are concerned with here (exynos and omap,
> plus new platforms) can be booted using DT anyway.
There's a bunch of non-DT architectures that are in active use (blackfin
for example) and I'd really hope that this is useful for some of them.
The pushback here was about the fact that the subsystem was doing odd
things with selecting device names which is odd in itself, I don't know
if that had bled over into the DT bindings but it sounded like it
might've done so.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] driver/vga16fb.c: remove the unused variable "dev" of function vga16fb_destroy()
From: Geert Uytterhoeven @ 2013-07-25 9:58 UTC (permalink / raw)
To: Gu Zheng
Cc: Jean-Christophe PLAGNIOL-VILLARD, Tomi Valkeinen,
Linux Fbdev development list, linux-kernel
In-Reply-To: <51F09D5E.70304@cn.fujitsu.com>
On Thu, Jul 25, 2013 at 5:37 AM, Gu Zheng <guz.fnst@cn.fujitsu.com> wrote:
> Commit e21d2170f36602ae2708 removed the unnecessary platform_set_drvdata(),
> but left the variable "dev" unused, delete it.
When referring to another commit, please also include the oneline summary of
the commit, to make it easier for people to see what it's about.
E.g. "Commit e21d2170f36602ae2708 ("video: remove unnecessary
platform_set_drvdata()") removed the unnecessary platform_set_drvdata(),
but left the variable "dev" unused, delete it."
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] driver/vga16fb.c: remove the unused variable "dev" of function vga16fb_destroy()
From: Gu Zheng @ 2013-07-25 10:02 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Jean-Christophe PLAGNIOL-VILLARD, Tomi Valkeinen,
Linux Fbdev development list, linux-kernel
In-Reply-To: <CAMuHMdVxXLrUXQno+vtHQrT_mmc9C6q42HZ6F1TujLBeEZt+Mw@mail.gmail.com>
On 07/25/2013 05:58 PM, Geert Uytterhoeven wrote:
> On Thu, Jul 25, 2013 at 5:37 AM, Gu Zheng <guz.fnst@cn.fujitsu.com> wrote:
>> Commit e21d2170f36602ae2708 removed the unnecessary platform_set_drvdata(),
>> but left the variable "dev" unused, delete it.
>
> When referring to another commit, please also include the oneline summary of
> the commit, to make it easier for people to see what it's about.
Got it, thanks for your reminder.:)
>
> E.g. "Commit e21d2170f36602ae2708 ("video: remove unnecessary
> platform_set_drvdata()") removed the unnecessary platform_set_drvdata(),
> but left the variable "dev" unused, delete it."
This is easier reading. I'll update it.
Regards,
Gu
>
> Thanks!
>
> 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
* [PATCH V2] driver/vga16fb.c: remove the unused variable "dev" of function vga16fb_destroy()
From: Gu Zheng @ 2013-07-25 10:06 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen; +Cc: linux-fbdev, linux-kernel, Geert Uytterhoeven
Commit e21d2170f36602ae2708 ("video: remove unnecessary
platform_set_drvdata()") removed the unnecessary platform_set_drvdata(),
but left the variable "dev" unused, delete it.
v2:
Following Geert's suggestion to make change log easier reading.
Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
---
drivers/video/vga16fb.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/video/vga16fb.c b/drivers/video/vga16fb.c
index 830ded4..2827333 100644
--- a/drivers/video/vga16fb.c
+++ b/drivers/video/vga16fb.c
@@ -1265,7 +1265,6 @@ static void vga16fb_imageblit(struct fb_info *info, const struct fb_image *image
static void vga16fb_destroy(struct fb_info *info)
{
- struct platform_device *dev = container_of(info->device, struct platform_device, dev);
iounmap(info->screen_base);
fb_dealloc_cmap(&info->cmap);
/* XXX unshare VGA regions */
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply related
* Re: [PATCH] video: xilinxfb: Fix compilation warning
From: Geert Uytterhoeven @ 2013-07-25 10:09 UTC (permalink / raw)
To: Michal Simek
Cc: Jingoo Han, Michal Simek, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, Linux Fbdev development list,
linux-kernel@vger.kernel.org, Stepan Moskovchenko
In-Reply-To: <51EF8F27.3030003@monstr.eu>
On Wed, Jul 24, 2013 at 10:24 AM, Michal Simek <monstr@monstr.eu> wrote:
>> Just now, I tested that the same problem happens on ARM config.
>> Also, I solved it by adding '&' operator.
>>
>> '&' operator is necessary as below:
>>
>> dev_dbg(dev, "regs: phys=%pa, virt=%p\n",
>> &drvdata->regs_phys, drvdata->regs);
>> ^^^
>>
>> dev_dbg(dev, "fb: phys=%pa, virt=%p, size=%x\n",
>> &drvdata->fb_phys, drvdata->fb_virt, fbsize);
>> ^^^
>
> ok.
>
> The truth is as I said there are just 5 files in the whole kernel
> which are using %pa and if %pa is right way to go we should
> probably fix all off them.
"%pa" is a quite recent addition (v3.9).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH V2] driver/vga16fb.c: remove the unused variable "dev" of function vga16fb_destroy()
From: Geert Uytterhoeven @ 2013-07-25 10:11 UTC (permalink / raw)
To: Gu Zheng
Cc: Jean-Christophe PLAGNIOL-VILLARD, Tomi Valkeinen,
Linux Fbdev development list, linux-kernel
In-Reply-To: <51F0F88D.8060903@cn.fujitsu.com>
On Thu, Jul 25, 2013 at 12:06 PM, Gu Zheng <guz.fnst@cn.fujitsu.com> wrote:
> Commit e21d2170f36602ae2708 ("video: remove unnecessary
> platform_set_drvdata()") removed the unnecessary platform_set_drvdata(),
> but left the variable "dev" unused, delete it.
>
> v2:
> Following Geert's suggestion to make change log easier reading.
>
> Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
> ---
Please send a v3, which has the version info under the above "---",
instead of making it a part of the patch description to be committed.
Thanks again!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 01/15] drivers: phy: add generic PHY framework
From: Laurent Pinchart @ 2013-07-25 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201307242032.03597.arnd@arndb.de>
Hi Arnd,
On Wednesday 24 July 2013 20:32:03 Arnd Bergmann wrote:
> On Tuesday 23 July 2013, Tomasz Figa wrote:
> > On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote:
> > > On Tue, 23 Jul 2013, Tomasz Figa wrote:
> > > > Where would you want to have those phy_address arrays stored? There
> > > > are no board files when booting with DT. Not even saying that you
> > > > don't need to use any hacky schemes like this when you have DT that
> > > > nicely specifies relations between devices.
> > >
> > > If everybody agrees DT has a nice scheme for specifying relations
> > > between devices, why not use that same scheme in the PHY core?
> >
> > It is already used, for cases when consumer device has a DT node attached.
> > In non-DT case this kind lookup translates loosely to something that is
> > being done in regulator framework - you can't bind devices by pointers,
> > because you don't have those pointers, so you need to use device names.
>
> Sorry for jumping in to the middle of the discussion, but why does a *new*
> framework even bother defining an interface for board files?
>
> Can't we just drop any interfaces for platform data passing in the phy
> framework and put the burden of adding those to anyone who actually needs
> them? All the platforms we are concerned with here (exynos and omap, plus
> new platforms) can be booted using DT anyway.
What about non-DT architectures such as MIPS (still widely used in consumer
networking equipments from what I've heard) ?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] driver/vga16fb.c: remove the unused variable "dev" of function vga16fb_destroy()
From: Luis Henriques @ 2013-07-25 10:20 UTC (permalink / raw)
To: Gu Zheng; +Cc: plagnioj, tomi.valkeinen, linux-fbdev, linux-kernel
In-Reply-To: <51F09D5E.70304@cn.fujitsu.com>
Hi,
Gu Zheng <guz.fnst@cn.fujitsu.com> writes:
> Commit e21d2170f36602ae2708 removed the unnecessary platform_set_drvdata(),
> but left the variable "dev" unused, delete it.
>
> Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
> ---
> drivers/video/vga16fb.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/vga16fb.c b/drivers/video/vga16fb.c
> index 830ded4..2827333 100644
> --- a/drivers/video/vga16fb.c
> +++ b/drivers/video/vga16fb.c
> @@ -1265,7 +1265,6 @@ static void vga16fb_imageblit(struct fb_info *info, const struct fb_image *image
>
> static void vga16fb_destroy(struct fb_info *info)
> {
> - struct platform_device *dev = container_of(info->device, struct platform_device, dev);
> iounmap(info->screen_base);
> fb_dealloc_cmap(&info->cmap);
> /* XXX unshare VGA regions */
I'm not sure if this fix isn't already queued as I sent a similar
patch a few days ago:
https://lkml.org/lkml/2013/7/10/524
Cheers,
--
Luis
^ permalink raw reply
* Re: [PATCH V2] driver/vga16fb.c: remove the unused variable "dev" of function vga16fb_destroy()
From: Paul Bolle @ 2013-07-25 10:22 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Gu Zheng, Jean-Christophe PLAGNIOL-VILLARD, Tomi Valkeinen,
Linux Fbdev development list, linux-kernel
In-Reply-To: <CAMuHMdXWpdTD4sHat9sm5pvXVeGNNKMF6eEN=bUK4qU0H6i1Aw@mail.gmail.com>
On Thu, 2013-07-25 at 12:11 +0200, Geert Uytterhoeven wrote:
> Please send a v3, which has the version info under the above "---",
> instead of making it a part of the patch description to be committed.
Grepping through my mail tells me this is the fourth time a patch has
been submitted to fix this trivial issue. Perhaps (one of) the
maintainers can indicate which patch, if any, the maintainers have taken
or will be taking.
Paul Bolle
^ permalink raw reply
* Re: [PATCH 01/15] drivers: phy: add generic PHY framework
From: Arnd Bergmann @ 2013-07-25 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2174304.5JlzJ583hP@avalon>
On Thursday 25 July 2013, Laurent Pinchart wrote:
> On Wednesday 24 July 2013 20:32:03 Arnd Bergmann wrote:
> > On Tuesday 23 July 2013, Tomasz Figa wrote:
> > > On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote:
> > > > On Tue, 23 Jul 2013, Tomasz Figa wrote:
> > > > > Where would you want to have those phy_address arrays stored? There
> > > > > are no board files when booting with DT. Not even saying that you
> > > > > don't need to use any hacky schemes like this when you have DT that
> > > > > nicely specifies relations between devices.
> > > >
> > > > If everybody agrees DT has a nice scheme for specifying relations
> > > > between devices, why not use that same scheme in the PHY core?
> > >
> > > It is already used, for cases when consumer device has a DT node attached.
> > > In non-DT case this kind lookup translates loosely to something that is
> > > being done in regulator framework - you can't bind devices by pointers,
> > > because you don't have those pointers, so you need to use device names.
> >
> > Sorry for jumping in to the middle of the discussion, but why does a new
> > framework even bother defining an interface for board files?
> >
> > Can't we just drop any interfaces for platform data passing in the phy
> > framework and put the burden of adding those to anyone who actually needs
> > them? All the platforms we are concerned with here (exynos and omap, plus
> > new platforms) can be booted using DT anyway.
>
> What about non-DT architectures such as MIPS (still widely used in consumer
> networking equipments from what I've heard) ?
* Vendors of such equipment have started moving on to ARM (e.g. Broadcom bcm47xx)
* Some of the modern MIPS platforms are now using DT
* Legacy platforms probably won't migrate to either DT or the generic PHY framework
I'm not saying that we can't support legacy board files with the common
PHY framework, but I'd expect things to be much easier if we focus on those
platforms that are actively being worked on for now, to bring an end to the
pointless API discussion.
Arnd
^ permalink raw reply
* Re: [V3 0/7] Enhance mmp display driver
From: jett zhou @ 2013-07-25 11:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACDDiy8OwYHbmYGwc0FV2NLVfu1BiUL9GYCmA2QEVVB5isFJGQ@mail.gmail.com>
Hi Jean
Does apply patch1~patch3 and patch6~patch7 have issue on your side? :)
Thanks
2013/7/14 jett zhou <jett.zhou@gmail.com>:
> Hi Jean
> As I checked the for-next branch, found patch4 and patch5 are
> already applied.
> As checked on my side, only apply patch1~patch3 and
> patch6~patch7 is ok, so think you can apply them except for patch4/5.
> If there is still problem, please let me know, I will check it then.
> Thanks
>
> 2013/7/9 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>:
>> HI,
>>
>> please rebase on the for-next branch as it does not apply
>>
>> Best Regards,
>> J.
>> On 19:27 Thu 27 Jun , Jett.Zhou wrote:
>>> Changelog:
>>> 1 Add more comments for the mmp_display rbswap usage
>>> according to Daniel's comments;
>>> 2 Add fix patch for ttc_dkb on rbswap;
>>> 3 Add more comments on the pitch usage and definition;
>>> 4 Combine the modification on pitch of graphic and video layer
>>> in one patch.
>>>
>>> Guoqing Li (2):
>>> video: mmp: rb swap setting update for mmp display
>>> video: mmp: optimize some register setting code
>>>
>>> Jett.Zhou (1):
>>> ARM: mmp: remove the legacy rbswap setting for ttc_dkb platform
>>>
>>> Jing Xiang (4):
>>> video: mmp: fix graphics/video layer enable/mask issue
>>> video: mmp: fix memcpy wrong size for mmp_addr issue
>>> video: mmp: calculate pitch value when fb set win
>>> video: mmp: add pitch info in mmp_win structure
>>>
>>> arch/arm/mach-mmp/ttc_dkb.c | 4 +-
>>> drivers/video/mmp/fb/mmpfb.c | 34 +++++++++++------
>>> drivers/video/mmp/hw/mmp_ctrl.c | 79 ++++++++++++++++++++++-----------------
>>> drivers/video/mmp/hw/mmp_ctrl.h | 5 ++
>>> include/video/mmp_disp.h | 6 +++
>>> 5 files changed, 79 insertions(+), 49 deletions(-)
>>>
>
>
>
> --
>
> ----------------------------------
> Best Regards
> Jett Zhou
--
----------------------------------
Best Regards
Jett Zhou
^ permalink raw reply
* Re: [PATCH 01/15] drivers: phy: add generic PHY framework
From: Laurent Pinchart @ 2013-07-25 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201307251300.49282.arnd@arndb.de>
Hi Arnd,
On Thursday 25 July 2013 13:00:49 Arnd Bergmann wrote:
> On Thursday 25 July 2013, Laurent Pinchart wrote:
> > On Wednesday 24 July 2013 20:32:03 Arnd Bergmann wrote:
> > > On Tuesday 23 July 2013, Tomasz Figa wrote:
> > > > On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote:
> > > > > On Tue, 23 Jul 2013, Tomasz Figa wrote:
> > > > > > Where would you want to have those phy_address arrays stored?
> > > > > > There are no board files when booting with DT. Not even saying
> > > > > > that you don't need to use any hacky schemes like this when you
> > > > > > have DT that nicely specifies relations between devices.
> > > > >
> > > > > If everybody agrees DT has a nice scheme for specifying relations
> > > > > between devices, why not use that same scheme in the PHY core?
> > > >
> > > > It is already used, for cases when consumer device has a DT node
> > > > attached. In non-DT case this kind lookup translates loosely to
> > > > something that is being done in regulator framework - you can't bind
> > > > devices by pointers, because you don't have those pointers, so you
> > > > need to use device names.
> > >
> > > Sorry for jumping in to the middle of the discussion, but why does a new
> > > framework even bother defining an interface for board files?
> > >
> > > Can't we just drop any interfaces for platform data passing in the phy
> > > framework and put the burden of adding those to anyone who actually
> > > needs them? All the platforms we are concerned with here (exynos and
> > > omap, plus new platforms) can be booted using DT anyway.
> >
> > What about non-DT architectures such as MIPS (still widely used in
> > consumer networking equipments from what I've heard) ?
>
> * Vendors of such equipment have started moving on to ARM (e.g. Broadcom
> bcm47xx)
> * Some of the modern MIPS platforms are now using DT
> * Legacy platforms probably won't migrate to either DT or the generic PHY
> framework
>
> I'm not saying that we can't support legacy board files with the common PHY
> framework, but I'd expect things to be much easier if we focus on those
> platforms that are actively being worked on for now, to bring an end to the
> pointless API discussion.
Fair enough :-)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v2] video: xilinxfb: Fix compilation warning
From: Michal Simek @ 2013-07-25 11:21 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Jingoo Han, Geert Uytterhoeven
Cc: Michal Simek, Tomi Valkeinen, linux-fbdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]
regs_phys is phys_addr_t (u32 or u64).
Lets retype it to u64.
Fixes compilation warning introduced by:
video: xilinxfb: Use drvdata->regs_phys instead of physaddr
(sha1: c88fafef0135e1e1c3e23c3e32ccbeeabc587f81)
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
Changes in v2:
- Use %pa instead of casting
ppc44x_defconfig
Fixes regressions in v3.11-rc2
---
drivers/video/xilinxfb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index f3d4a69..6629b29 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -341,8 +341,8 @@ static int xilinxfb_assign(struct platform_device *pdev,
if (drvdata->flags & BUS_ACCESS_FLAG) {
/* Put a banner in the log (for DEBUG) */
- dev_dbg(dev, "regs: phys=%x, virt=%p\n", drvdata->regs_phys,
- drvdata->regs);
+ dev_dbg(dev, "regs: phys=%pa, virt=%p\n",
+ &drvdata->regs_phys, drvdata->regs);
}
/* Put a banner in the log (for DEBUG) */
dev_dbg(dev, "fb: phys=%llx, virt=%p, size=%x\n",
--
1.8.2.3
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related
* Re: [PATCH 01/15] drivers: phy: add generic PHY framework
From: Mark Brown @ 2013-07-25 12:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201307251300.49282.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 395 bytes --]
On Thu, Jul 25, 2013 at 01:00:49PM +0200, Arnd Bergmann wrote:
> I'm not saying that we can't support legacy board files with the common
> PHY framework, but I'd expect things to be much easier if we focus on those
> platforms that are actively being worked on for now, to bring an end to the
> pointless API discussion.
Well, it seemed like Greg's concerns had already been addressed anyway.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: kmemleak warning in efifb_probe
From: Catalin Marinas @ 2013-07-25 12:18 UTC (permalink / raw)
To: Alexandra N. Kossovsky
Cc: Peter Jones, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
linux-fbdev, Linux Kernel Mailing List
In-Reply-To: <20130721151151.GK24717@sanechka.spb.ru>
On 21 July 2013 16:11, Alexandra N. Kossovsky
<Alexandra.Kossovsky@oktetlabs.ru> wrote:
> I am running linux-3.10.0 with kmemleak and see following warnings
> in /sys/kernel/debug/kmemleak:
>
> unreferenced object 0xffff880216fcfe00 (size 512):
> comm "swapper/0", pid 1, jiffies 4294895429 (age 1415.320s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 aa aa aa aa aa aa aa aa ................
> 55 55 55 55 55 55 55 55 ff ff ff ff ff ff ff ff UUUUUUUU........
> backtrace:
> [<ffffffff813e415c>] kmemleak_alloc+0x21/0x3e
> [<ffffffff8111c17f>] kmemleak_alloc_recursive.constprop.57+0x16/0x18
> [<ffffffff8111e63b>] __kmalloc+0xf9/0x144
> [<ffffffff8123d9cf>] fb_alloc_cmap_gfp+0x47/0xe1
> [<ffffffff8123da77>] fb_alloc_cmap+0xe/0x10
> [<ffffffff81aff40a>] efifb_probe+0x3e9/0x48f
> [<ffffffff812c566f>] platform_drv_probe+0x34/0x5e
> [<ffffffff812c3e6d>] driver_probe_device+0x98/0x1b4
> [<ffffffff812c3fd7>] __driver_attach+0x4e/0x6f
> [<ffffffff812c25bf>] bus_for_each_dev+0x57/0x8a
> [<ffffffff812c3984>] driver_attach+0x19/0x1b
> [<ffffffff812c362b>] bus_add_driver+0xde/0x201
> [<ffffffff812c453f>] driver_register+0x8c/0x110
> [<ffffffff812c510d>] platform_driver_register+0x41/0x43
> [<ffffffff812c5127>] platform_driver_probe+0x18/0x8a
> [<ffffffff81aff002>] efifb_init+0x276/0x295
Does the efifb driver has any way to deallocate the cmap? I don't see
any explicit call to fb_dealloc_cmap() apart from the error handling.
My theory is that the efifb driver gets deregistered via
do_remove_conflicting_framebuffers(). I'm not familiar with this code,
just commenting from a kmemleak perspective.
--
Catalin
^ permalink raw reply
* [PATCHv2 0/3] Few ignored framebuffer fixes/additions
From: Maxime Ripard @ 2013-07-25 13:05 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This is the v2 of a set of patches that got forgotten.
These have been around for a while without any functionnal comments recently,
so I guess we should be pretty close to merge them.
It would be great if we could have comments from the maintainer on these
patches though.
Thanks,
Maxime
Changes from v1:
- Fix line wrapping in patch 2
- Added some comments on the msleep in patch 3
Alexandre Belloni (1):
fb: backlight: HX8357: Add HX8369 support
Hector Palacios (1):
video: mxsfb: fix color settings for 18bit data bus and 32bpp
Maxime Ripard (1):
video: hx8357: Make IM pins optional
drivers/video/backlight/hx8357.c | 272 +++++++++++++++++++++++++++++++++------
drivers/video/mxsfb.c | 26 ----
2 files changed, 236 insertions(+), 62 deletions(-)
--
1.8.3.2
^ permalink raw reply
* [PATCHv2 1/3] video: mxsfb: fix color settings for 18bit data bus and 32bpp
From: Maxime Ripard @ 2013-07-25 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1374757513-2253-1-git-send-email-maxime.ripard@free-electrons.com>
From: Hector Palacios <hector.palacios@digi.com>
For a combination of 18bit LCD data bus width and a color
mode of 32bpp, the driver was setting the color mapping to
rgb666, which is wrong, as the color in memory realy has an
rgb888 layout.
This patch also removes the setting of flag CTRL_DF24 that
makes the driver dimiss the upper 2 bits when handling 32/24bpp
colors in a diplay with 18bit data bus width. This flag made
true color images display wrong in such configurations.
Finally, the color mapping rgb666 has also been removed as nobody
is using it and high level applications like Qt5 cannot work
with it either.
Reference: https://lkml.org/lkml/2013/5/23/220
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
Acked-by: Juergen Beisert <jbe@pengutronix.de>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/video/mxsfb.c | 26 --------------------------
1 file changed, 26 deletions(-)
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index 3ba3771..dc09ebe 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -239,24 +239,6 @@ static const struct fb_bitfield def_rgb565[] = {
}
};
-static const struct fb_bitfield def_rgb666[] = {
- [RED] = {
- .offset = 16,
- .length = 6,
- },
- [GREEN] = {
- .offset = 8,
- .length = 6,
- },
- [BLUE] = {
- .offset = 0,
- .length = 6,
- },
- [TRANSP] = { /* no support for transparency */
- .length = 0,
- }
-};
-
static const struct fb_bitfield def_rgb888[] = {
[RED] = {
.offset = 16,
@@ -309,9 +291,6 @@ static int mxsfb_check_var(struct fb_var_screeninfo *var,
break;
case STMLCDIF_16BIT:
case STMLCDIF_18BIT:
- /* 24 bit to 18 bit mapping */
- rgb = def_rgb666;
- break;
case STMLCDIF_24BIT:
/* real 24 bit */
rgb = def_rgb888;
@@ -453,11 +432,6 @@ static int mxsfb_set_par(struct fb_info *fb_info)
return -EINVAL;
case STMLCDIF_16BIT:
case STMLCDIF_18BIT:
- /* 24 bit to 18 bit mapping */
- ctrl |= CTRL_DF24; /* ignore the upper 2 bits in
- * each colour component
- */
- break;
case STMLCDIF_24BIT:
/* real 24 bit */
break;
--
1.8.3.2
^ permalink raw reply related
* [PATCHv2 2/3] video: hx8357: Make IM pins optional
From: Maxime Ripard @ 2013-07-25 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1374757513-2253-1-git-send-email-maxime.ripard@free-electrons.com>
The IM pins of the HX8357 controller are used to define the interface
used to feed pixel stream to the LCD panel.
Most of the time, these pins are directly routed to either the ground or
the VCC to set their values.
Remove the need to assign GPIOs to these pins when we are in such a case.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/video/backlight/hx8357.c | 53 +++++++++++++++++++++++-----------------
1 file changed, 31 insertions(+), 22 deletions(-)
diff --git a/drivers/video/backlight/hx8357.c b/drivers/video/backlight/hx8357.c
index a0482b5..00614ce 100644
--- a/drivers/video/backlight/hx8357.c
+++ b/drivers/video/backlight/hx8357.c
@@ -76,6 +76,7 @@ struct hx8357_data {
unsigned reset;
struct spi_device *spi;
int state;
+ bool use_im_pins;
};
static u8 hx8357_seq_power[] = {
@@ -250,9 +251,11 @@ static int hx8357_lcd_init(struct lcd_device *lcdev)
* Set the interface selection pins to SPI mode, with three
* wires
*/
- gpio_set_value_cansleep(lcd->im_pins[0], 1);
- gpio_set_value_cansleep(lcd->im_pins[1], 0);
- gpio_set_value_cansleep(lcd->im_pins[2], 1);
+ if (lcd->use_im_pins) {
+ gpio_set_value_cansleep(lcd->im_pins[0], 1);
+ gpio_set_value_cansleep(lcd->im_pins[1], 0);
+ gpio_set_value_cansleep(lcd->im_pins[2], 1);
+ }
/* Reset the screen */
gpio_set_value(lcd->reset, 1);
@@ -424,26 +427,32 @@ static int hx8357_probe(struct spi_device *spi)
return -EINVAL;
}
- for (i = 0; i < HX8357_NUM_IM_PINS; i++) {
- lcd->im_pins[i] = of_get_named_gpio(spi->dev.of_node,
- "im-gpios", i);
- if (lcd->im_pins[i] = -EPROBE_DEFER) {
- dev_info(&spi->dev, "GPIO requested is not here yet, deferring the probe\n");
- return -EPROBE_DEFER;
- }
- if (!gpio_is_valid(lcd->im_pins[i])) {
- dev_err(&spi->dev, "Missing dt property: im-gpios\n");
- return -EINVAL;
+ if (of_find_property(spi->dev.of_node, "im-gpios", NULL)) {
+ lcd->use_im_pins = 1;
+
+ for (i = 0; i < HX8357_NUM_IM_PINS; i++) {
+ lcd->im_pins[i] = of_get_named_gpio(spi->dev.of_node,
+ "im-gpios", i);
+ if (lcd->im_pins[i] = -EPROBE_DEFER) {
+ dev_info(&spi->dev, "GPIO requested is not here yet, deferring the probe\n");
+ return -EPROBE_DEFER;
+ }
+ if (!gpio_is_valid(lcd->im_pins[i])) {
+ dev_err(&spi->dev, "Missing dt property: im-gpios\n");
+ return -EINVAL;
+ }
+
+ ret = devm_gpio_request_one(&spi->dev, lcd->im_pins[i],
+ GPIOF_OUT_INIT_LOW,
+ "im_pins");
+ if (ret) {
+ dev_err(&spi->dev, "failed to request gpio %d: %d\n",
+ lcd->im_pins[i], ret);
+ return -EINVAL;
+ }
}
-
- ret = devm_gpio_request_one(&spi->dev, lcd->im_pins[i],
- GPIOF_OUT_INIT_LOW, "im_pins");
- if (ret) {
- dev_err(&spi->dev, "failed to request gpio %d: %d\n",
- lcd->im_pins[i], ret);
- return -EINVAL;
- }
- }
+ } else
+ lcd->use_im_pins = 0;
lcdev = lcd_device_register("mxsfb", &spi->dev, lcd, &hx8357_ops);
if (IS_ERR(lcdev)) {
--
1.8.3.2
^ permalink raw reply related
* [PATCHv2 3/3] fb: backlight: HX8357: Add HX8369 support
From: Maxime Ripard @ 2013-07-25 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1374757513-2253-1-git-send-email-maxime.ripard@free-electrons.com>
From: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Add support for the Himax HX8369 controller as it is quite similar to the
hx8357.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/backlight/hx8357.c | 221 ++++++++++++++++++++++++++++++++++++---
1 file changed, 206 insertions(+), 15 deletions(-)
diff --git a/drivers/video/backlight/hx8357.c b/drivers/video/backlight/hx8357.c
index 00614ce..58ed4c1 100644
--- a/drivers/video/backlight/hx8357.c
+++ b/drivers/video/backlight/hx8357.c
@@ -71,6 +71,18 @@
#define HX8357_SET_POWER_NORMAL 0xd2
#define HX8357_SET_PANEL_RELATED 0xe9
+#define HX8369_SET_DISPLAY_BRIGHTNESS 0x51
+#define HX8369_WRITE_CABC_DISPLAY_VALUE 0x53
+#define HX8369_WRITE_CABC_BRIGHT_CTRL 0x55
+#define HX8369_WRITE_CABC_MIN_BRIGHTNESS 0x5e
+#define HX8369_SET_POWER 0xb1
+#define HX8369_SET_DISPLAY_MODE 0xb2
+#define HX8369_SET_DISPLAY_WAVEFORM_CYC 0xb4
+#define HX8369_SET_VCOM 0xb6
+#define HX8369_SET_EXTENSION_COMMAND 0xb9
+#define HX8369_SET_GIP 0xd5
+#define HX8369_SET_GAMMA_CURVE_RELATED 0xe0
+
struct hx8357_data {
unsigned im_pins[HX8357_NUM_IM_PINS];
unsigned reset;
@@ -144,6 +156,61 @@ static u8 hx8357_seq_display_mode[] = {
HX8357_SET_DISPLAY_MODE_RGB_INTERFACE,
};
+static u8 hx8369_seq_write_CABC_min_brightness[] = {
+ HX8369_WRITE_CABC_MIN_BRIGHTNESS, 0x00,
+};
+
+static u8 hx8369_seq_write_CABC_control[] = {
+ HX8369_WRITE_CABC_DISPLAY_VALUE, 0x24,
+};
+
+static u8 hx8369_seq_set_display_brightness[] = {
+ HX8369_SET_DISPLAY_BRIGHTNESS, 0xFF,
+};
+
+static u8 hx8369_seq_write_CABC_control_setting[] = {
+ HX8369_WRITE_CABC_BRIGHT_CTRL, 0x02,
+};
+
+static u8 hx8369_seq_extension_command[] = {
+ HX8369_SET_EXTENSION_COMMAND, 0xff, 0x83, 0x69,
+};
+
+static u8 hx8369_seq_display_related[] = {
+ HX8369_SET_DISPLAY_MODE, 0x00, 0x2b, 0x03, 0x03, 0x70, 0x00,
+ 0xff, 0x00, 0x00, 0x00, 0x00, 0x03, 0x03, 0x00, 0x01,
+};
+
+static u8 hx8369_seq_panel_waveform_cycle[] = {
+ HX8369_SET_DISPLAY_WAVEFORM_CYC, 0x0a, 0x1d, 0x80, 0x06, 0x02,
+};
+
+static u8 hx8369_seq_set_address_mode[] = {
+ HX8357_SET_ADDRESS_MODE, 0x00,
+};
+
+static u8 hx8369_seq_vcom[] = {
+ HX8369_SET_VCOM, 0x3e, 0x3e,
+};
+
+static u8 hx8369_seq_gip[] = {
+ HX8369_SET_GIP, 0x00, 0x01, 0x03, 0x25, 0x01, 0x02, 0x28, 0x70,
+ 0x11, 0x13, 0x00, 0x00, 0x40, 0x26, 0x51, 0x37, 0x00, 0x00, 0x71,
+ 0x35, 0x60, 0x24, 0x07, 0x0f, 0x04, 0x04,
+};
+
+static u8 hx8369_seq_power[] = {
+ HX8369_SET_POWER, 0x01, 0x00, 0x34, 0x03, 0x00, 0x11, 0x11, 0x32,
+ 0x2f, 0x3f, 0x3f, 0x01, 0x3a, 0x01, 0xe6, 0xe6, 0xe6, 0xe6, 0xe6,
+};
+
+static u8 hx8369_seq_gamma_curve_related[] = {
+ HX8369_SET_GAMMA_CURVE_RELATED, 0x00, 0x0d, 0x19, 0x2f, 0x3b, 0x3d,
+ 0x2e, 0x4a, 0x08, 0x0e, 0x0f, 0x14, 0x16, 0x14, 0x14, 0x14, 0x1e,
+ 0x00, 0x0d, 0x19, 0x2f, 0x3b, 0x3d, 0x2e, 0x4a, 0x08, 0x0e, 0x0f,
+ 0x14, 0x16, 0x14, 0x14, 0x14, 0x1e,
+};
+
static int hx8357_spi_write_then_read(struct lcd_device *lcdev,
u8 *txbuf, u16 txlen,
u8 *rxbuf, u16 rxlen)
@@ -220,6 +287,10 @@ static int hx8357_enter_standby(struct lcd_device *lcdev)
if (ret < 0)
return ret;
+ /*
+ * The controller needs 120ms when entering in sleep mode before we can
+ * send the command to go off sleep mode
+ */
msleep(120);
return 0;
@@ -233,6 +304,10 @@ static int hx8357_exit_standby(struct lcd_device *lcdev)
if (ret < 0)
return ret;
+ /*
+ * The controller needs 120ms when exiting from sleep mode before we
+ * can send the command to enter in sleep mode
+ */
msleep(120);
ret = hx8357_spi_write_byte(lcdev, HX8357_SET_DISPLAY_ON);
@@ -242,6 +317,21 @@ static int hx8357_exit_standby(struct lcd_device *lcdev)
return 0;
}
+static void hx8357_lcd_reset(struct lcd_device *lcdev)
+{
+ struct hx8357_data *lcd = lcd_get_data(lcdev);
+
+ /* Reset the screen */
+ gpio_set_value(lcd->reset, 1);
+ usleep_range(10000, 12000);
+ gpio_set_value(lcd->reset, 0);
+ usleep_range(10000, 12000);
+ gpio_set_value(lcd->reset, 1);
+
+ /* The controller needs 120ms to recover from reset */
+ msleep(120);
+}
+
static int hx8357_lcd_init(struct lcd_device *lcdev)
{
struct hx8357_data *lcd = lcd_get_data(lcdev);
@@ -257,14 +347,6 @@ static int hx8357_lcd_init(struct lcd_device *lcdev)
gpio_set_value_cansleep(lcd->im_pins[2], 1);
}
- /* Reset the screen */
- gpio_set_value(lcd->reset, 1);
- usleep_range(10000, 12000);
- gpio_set_value(lcd->reset, 0);
- usleep_range(10000, 12000);
- gpio_set_value(lcd->reset, 1);
- msleep(120);
-
ret = hx8357_spi_write_array(lcdev, hx8357_seq_power,
ARRAY_SIZE(hx8357_seq_power));
if (ret < 0)
@@ -344,6 +426,9 @@ static int hx8357_lcd_init(struct lcd_device *lcdev)
if (ret < 0)
return ret;
+ /*
+ * The controller needs 120ms to fully recover from exiting sleep mode
+ */
msleep(120);
ret = hx8357_spi_write_byte(lcdev, HX8357_SET_DISPLAY_ON);
@@ -359,6 +444,98 @@ static int hx8357_lcd_init(struct lcd_device *lcdev)
return 0;
}
+static int hx8369_lcd_init(struct lcd_device *lcdev)
+{
+ int ret;
+
+ ret = hx8357_spi_write_array(lcdev, hx8369_seq_extension_command,
+ ARRAY_SIZE(hx8369_seq_extension_command));
+ if (ret < 0)
+ return ret;
+ usleep_range(10000, 12000);
+
+ ret = hx8357_spi_write_array(lcdev, hx8369_seq_display_related,
+ ARRAY_SIZE(hx8369_seq_display_related));
+ if (ret < 0)
+ return ret;
+
+ ret = hx8357_spi_write_array(lcdev, hx8369_seq_panel_waveform_cycle,
+ ARRAY_SIZE(hx8369_seq_panel_waveform_cycle));
+ if (ret < 0)
+ return ret;
+
+ ret = hx8357_spi_write_array(lcdev, hx8369_seq_set_address_mode,
+ ARRAY_SIZE(hx8369_seq_set_address_mode));
+ if (ret < 0)
+ return ret;
+
+ ret = hx8357_spi_write_array(lcdev, hx8369_seq_vcom,
+ ARRAY_SIZE(hx8369_seq_vcom));
+ if (ret < 0)
+ return ret;
+
+ ret = hx8357_spi_write_array(lcdev, hx8369_seq_gip,
+ ARRAY_SIZE(hx8369_seq_gip));
+ if (ret < 0)
+ return ret;
+
+ ret = hx8357_spi_write_array(lcdev, hx8369_seq_power,
+ ARRAY_SIZE(hx8369_seq_power));
+ if (ret < 0)
+ return ret;
+
+ ret = hx8357_spi_write_byte(lcdev, HX8357_EXIT_SLEEP_MODE);
+ if (ret < 0)
+ return ret;
+
+ /*
+ * The controller needs 120ms to fully recover from exiting sleep mode
+ */
+ msleep(120);
+
+ ret = hx8357_spi_write_array(lcdev, hx8369_seq_gamma_curve_related,
+ ARRAY_SIZE(hx8369_seq_gamma_curve_related));
+ if (ret < 0)
+ return ret;
+
+ ret = hx8357_spi_write_byte(lcdev, HX8357_EXIT_SLEEP_MODE);
+ if (ret < 0)
+ return ret;
+ usleep_range(1000, 1200);
+
+ ret = hx8357_spi_write_array(lcdev, hx8369_seq_write_CABC_control,
+ ARRAY_SIZE(hx8369_seq_write_CABC_control));
+ if (ret < 0)
+ return ret;
+ usleep_range(10000, 12000);
+
+ ret = hx8357_spi_write_array(lcdev,
+ hx8369_seq_write_CABC_control_setting,
+ ARRAY_SIZE(hx8369_seq_write_CABC_control_setting));
+ if (ret < 0)
+ return ret;
+
+ ret = hx8357_spi_write_array(lcdev,
+ hx8369_seq_write_CABC_min_brightness,
+ ARRAY_SIZE(hx8369_seq_write_CABC_min_brightness));
+ if (ret < 0)
+ return ret;
+ usleep_range(10000, 12000);
+
+ ret = hx8357_spi_write_array(lcdev, hx8369_seq_set_display_brightness,
+ ARRAY_SIZE(hx8369_seq_set_display_brightness));
+ if (ret < 0)
+ return ret;
+
+ ret = hx8357_spi_write_byte(lcdev, HX8357_SET_DISPLAY_ON);
+ if (ret < 0)
+ return ret;
+
+ msleep(100);
+
+ return 0;
+}
+
#define POWER_IS_ON(pwr) ((pwr) <= FB_BLANK_NORMAL)
static int hx8357_set_power(struct lcd_device *lcdev, int power)
@@ -391,10 +568,24 @@ static struct lcd_ops hx8357_ops = {
.get_power = hx8357_get_power,
};
+static const struct of_device_id hx8357_dt_ids[] = {
+ {
+ .compatible = "himax,hx8357",
+ .data = hx8357_lcd_init,
+ },
+ {
+ .compatible = "himax,hx8369",
+ .data = hx8369_lcd_init,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, hx8357_dt_ids);
+
static int hx8357_probe(struct spi_device *spi)
{
struct lcd_device *lcdev;
struct hx8357_data *lcd;
+ const struct of_device_id *match;
int i, ret;
lcd = devm_kzalloc(&spi->dev, sizeof(*lcd), GFP_KERNEL);
@@ -411,6 +602,10 @@ static int hx8357_probe(struct spi_device *spi)
lcd->spi = spi;
+ match = of_match_device(hx8357_dt_ids, &spi->dev);
+ if (!match || !match->data)
+ return -EINVAL;
+
lcd->reset = of_get_named_gpio(spi->dev.of_node, "gpios-reset", 0);
if (!gpio_is_valid(lcd->reset)) {
dev_err(&spi->dev, "Missing dt property: gpios-reset\n");
@@ -461,7 +656,9 @@ static int hx8357_probe(struct spi_device *spi)
}
spi_set_drvdata(spi, lcdev);
- ret = hx8357_lcd_init(lcdev);
+ hx8357_lcd_reset(lcdev);
+
+ ret = ((int (*)(struct lcd_device *))match->data)(lcdev);
if (ret) {
dev_err(&spi->dev, "Couldn't initialize panel\n");
goto init_error;
@@ -484,12 +681,6 @@ static int hx8357_remove(struct spi_device *spi)
return 0;
}
-static const struct of_device_id hx8357_dt_ids[] = {
- { .compatible = "himax,hx8357" },
- {},
-};
-MODULE_DEVICE_TABLE(of, hx8357_dt_ids);
-
static struct spi_driver hx8357_driver = {
.probe = hx8357_probe,
.remove = hx8357_remove,
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH v2] video: xilinxfb: Fix compilation warning
From: Geert Uytterhoeven @ 2013-07-25 13:36 UTC (permalink / raw)
To: Michal Simek
Cc: Jean-Christophe Plagniol-Villard, Jingoo Han, Michal Simek,
Tomi Valkeinen, Linux Fbdev development list,
linux-kernel@vger.kernel.org
In-Reply-To: <204d93f8a9dffef6ff00d961f91be0b465f21841.1374751310.git.michal.simek@xilinx.com>
On Thu, Jul 25, 2013 at 1:21 PM, Michal Simek <michal.simek@xilinx.com> wrote:
> regs_phys is phys_addr_t (u32 or u64).
> Lets retype it to u64.
This no longer matches the actual patch?
> Fixes compilation warning introduced by:
> video: xilinxfb: Use drvdata->regs_phys instead of physaddr
> (sha1: c88fafef0135e1e1c3e23c3e32ccbeeabc587f81)
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> ---
> Changes in v2:
> - Use %pa instead of casting
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