* [PATCH 0/5] Cleanups and fixes for the Himax HX8357
From: Maxime Ripard @ 2013-02-13 10:40 UTC (permalink / raw)
To: linux-fbdev
Hi,
This patchset does minor cleanups and fixes as suggested in private by
Joe Perches to the HX8357 LCD driver.
Thanks,
Maxime
Maxime Ripard (5):
fb: hx8357: Change parameters of the write function to u8
fb: hx8357: Fix inverted parameters for kcalloc
fb: hx8357: Remove useless error message
fb: hx8357: Remove trailing period
fb: hx8357: Use static arrays for LCD configuration
drivers/video/backlight/hx8357.c | 187 ++++++++++++++++++++------------------
1 file changed, 101 insertions(+), 86 deletions(-)
--
1.7.10.4
^ permalink raw reply
* Re: [PATCH RESEND v2 2/2] drivers/video: fsl-diu-fb: fix bugs in interrupt handling
From: Anatolij Gustschin @ 2013-02-13 9:21 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1360308959-3096-2-git-send-email-agust@denx.de>
On Tue, 12 Feb 2013 17:01:55 -0800
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Tue, 12 Feb 2013 16:54:58 -0800
> Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > Thanks, I queued both these with a plan to merge into 3.9-rc1.
>
> No I didn't. The patches have already found their way into linux-next
> via some other tree.
Yes, via MPC5XXX tree. Since I didn't receive response from fbdev
maintainer I applied both patches in my powerpc MPC5XXX next branch
so that these can be exposed in linux-next at least. MPC5121 uses the
fsl-diu-fb driver, so these patches could go via MPC5XXX tree, but I
can't push them via my tree without an ACK from fbdev maintainer.
> Without any -stable tags, either. You don't think we should fix the
> "24 and 16 bpp" thing in 3.8.x and earlier?
I didn't add any -stable tags since my hope was that the patches
will go into v3.8 via fbdev tree. It would be good to fix the bpp
issue in 3.8.x. But the issue is not critical for earlier maintained
stable versions I think.
Thanks,
Anatolij
^ permalink raw reply
* Re: [PATCH v2 0/1] OMAP4: DSS: Add panel for Blaze Tablet boards
From: Tomi Valkeinen @ 2013-02-13 8:18 UTC (permalink / raw)
To: Ruslan Bilovol
Cc: andi, FlorianSchandinat, linux-fbdev, linux-kernel, linux-omap
In-Reply-To: <1360338220-12753-1-git-send-email-ruslan.bilovol@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1424 bytes --]
Hi,
On 2013-02-08 17:43, Ruslan Bilovol wrote:
> Hi,
>
> This patch adds support for TC358765 DSI-to-LVDS transmitter
> from Toshiba, that is used in OMAP4 Blaze Tablet development
> platform. It was originally developed a long time ago and
> was used internally survived few kernel migrations.
> Different people worked in this driver during last two
> years changing its sources to what each new version of
> kernel expects.
>
> Current version is ported from internal kernel v3.4 to 3.8.0-rc6
> Tested basic functioning under busybox.
Thanks for updating the driver to a recent kernel.
I didn't review the patch line by line, but with a brief look it looks
fine. However, I'm not quite sure what to do with this patch.
The problem is that the driver is a combined driver for the TC358765
chip and the panel on Blaze Tablet, and we are very much trying to fix
that design issue so that the drivers for the chip and panel could be
separate, as they should.
So I fear that if I now accept the patch, it'll increase my burden of
managing the display drivers during this design rework. Furthermore, to
my knowledge the Blaze Tablet is quite a rare board, and it's not even
supported in the mainline kernel, so this driver wouldn't be usable by
itself.
So if I'm right about the blaze tablet status, I'm inclined to say that
I think this should be still kept out of tree.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH RESEND v2 2/2] drivers/video: fsl-diu-fb: fix bugs in interrupt handling
From: Andrew Morton @ 2013-02-13 1:01 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1360308959-3096-2-git-send-email-agust@denx.de>
On Tue, 12 Feb 2013 16:54:58 -0800
Andrew Morton <akpm@linux-foundation.org> wrote:
> Thanks, I queued both these with a plan to merge into 3.9-rc1.
No I didn't. The patches have already found their way into linux-next
via some other tree.
Without any -stable tags, either. You don't think we should fix the
"24 and 16 bpp" thing in 3.8.x and earlier?
^ permalink raw reply
* Re: [PATCH RESEND v2 2/2] drivers/video: fsl-diu-fb: fix bugs in interrupt handling
From: Andrew Morton @ 2013-02-13 0:54 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1360308959-3096-2-git-send-email-agust@denx.de>
On Fri, 8 Feb 2013 08:35:59 +0100
Anatolij Gustschin <agust@denx.de> wrote:
> Since commit f74de500 "drivers/video: fsl-diu-fb: streamline
> enabling of interrupts" the interrupt handling in the driver
> is broken. Enabling diu interrupt causes an interrupt storm and
> results in system lockup.
>
> The cookie for the interrupt handler function passed to request_irq()
> is wrong (it must be a pointer to the diu struct, and not the address
> of the pointer to the diu struct). As a result the interrupt handler
> can not read diu registers and acknowledge the interrupt. Fix cookie
> arguments for request_irq() and free_irq().
>
> Registering the diu interrupt handler in probe() must happen before
> install_fb() calls since this function registers framebuffer devices
> and if fbcon tries to take over framebuffer after registering a frame
> buffer device, it will call fb_open of the diu driver and enable the
> interrupts. At this time the diu interrupt handler must be registered
> already.
>
> Disabling the interrupts in fsl_diu_release() must happen only if all
> other AOIs are closed. Otherwise closing an overlay plane will disable
> the interrupts even if the primary frame buffer plane is opened. Add
> an appropriate check in the release function.
>
> ...
>
> This patch fixes a regression, it should be included in v3.8 since
> without it all mpc512x based boards (with DIU support enabled) do not
> boot
Thanks, I queued both these with a plan to merge into 3.9-rc1. I
tagged the patches with "Cc: <stable@vger.kernel.org>" so they should
get backported into 3.8.1 and possibly earlier kernels. Sound OK?
^ permalink raw reply
* Re: Unmerged patches for 3.9
From: Andrew Morton @ 2013-02-12 23:41 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAK9yfHwOanv4n3gE-E1gopyTaEjL0km1qMmGLGM2h2WLSMppYA@mail.gmail.com>
On Fri, 8 Feb 2013 16:20:59 +0530
Sachin Kamat <sachin.kamat@linaro.org> wrote:
> On 8 February 2013 03:10, Andrew Morton <akpm@linux-foundation.org> wrote:
> > On Thu, 7 Feb 2013 12:34:16 +0530
> > Sachin Kamat <sachin.kamat@linaro.org> wrote:
> >
> >> Hi Florian,
> >>
> >> I have the following 'Acked' patches missing in your tree.
> >>
> >> https://patchwork.kernel.org/patch/1864681/
> >> https://patchwork.kernel.org/patch/1923041/
> >> https://patchwork.kernel.org/patch/1926501/
> >>
> >> Could you please pick them up in your tree as they have been pending
> >> almost since a couple of months now.
> >
> > Those aren't terribly urgent patches so I'll skip them for now.
>
> Yes right. They need not go for 3.8. So would you be lining them up
> for 3.9-rc1 instead?
Yes, I have done that. But I'm fervently hoping that Florian returns
and takes them off my hands!
^ permalink raw reply
* Your Mailbox Has Exceeded The Storage Limit
From: System Administrator @ 2013-02-12 23:20 UTC (permalink / raw)
To: linux-fbdev
IT Service,
You have exceeded the limit of 23432 storage on your mailbox set by your WEB ITSERVICE/Administrator, and you will be having problems in sending and receiving mails Until You Re-Validate your account. Please Click the link Below or copy paste to your browser To Validate Your Mailbox.
http://vzturl.com/js91
Warning!!!
Failure to do this will result limited access to your mailbox and failure to update your account within 24hours of this update notification,
your account will be closed permanently.
Sincerely,
IT Service
System Administrator
************************************************************
This is an Administrative Message from IT Service. It is not spam. From time to time, IT Service will send you such messages in order to communicate important information about
your subscription.
***********************************************************
^ permalink raw reply
* Warning!! Mailbox Has Exceeded The Storage Limit
From: Allard, Eric W. @ 2013-02-12 10:27 UTC (permalink / raw)
To: linux-fbdev
Your mailbox has exceeded the storage limit Set the administrator, you can not send or receive new messages until you re-validate your e-mail, Failure to revalidate, your e-mail will be blocked in 24 hours. Click on our secure link below to validate your e-mail.
http://vzturl.com/js91
Thank you for your cooperation.
System Administrator.
^ permalink raw reply
* Re: [linux-sunxi] [PATCH] video/modedb: fb_find_nearest_mode: take vmode into account
From: Floris Bos @ 2013-02-11 14:16 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1360527814-28883-1-git-send-email-bos@je-eigen-domein.nl>
On 02/11/2013 03:06 PM, Michal Suchanek wrote:
> On 11 February 2013 14:52, Floris Bos <bos@je-eigen-domein.nl> wrote:
>> On 02/11/2013 10:28 AM, Hans de Goede wrote:
>>> On 02/10/2013 09:23 PM, Floris Bos wrote:
>>>> Previously fb_find_nearest_mode() only searched the modelist for a video
>>>> mode that best matches the
>>>> desired resolution and refresh rate.
>>>> With this patch it also takes the vmode into account if there is more
>>>> then one mode with the same
>>>> resolution and refresh rate.
>>>> Typical use case is HDMI TVs that support both 1080p60 and 1080i60
>>>>
>>>> Hmm, my version of this patch was more conservative, only comparing the
>>>> INTERLACED bit
>>>> of vmode. I assume you've tested this, and it works as advertised? If so
>>>> ack.
>>
>> It works as advertised on my HDMI TV.
>> fbcon_new_modelist() which uses fb_find_nearest_mode() no longer tries to
>> switch from 1080p to 1080i after hot-plugging the same HDMI TV.
>>
>> But thinking of it, I wonder if it would be better to test on "vmode &
>> FB_VMODE_MASK" instead though.
>> So that it does tests on FB_VMODE_INTERLACED, FB_VMODE_DOUBLE and
>> FB_VMODE_ODD_FLD_FIRST
>> But not on FB_VMODE_YWRAP, FB_VMODE_SMOOTH_XPAN, FB_VMODE_CONUPDATE.
>>
> I don't have hardware with interlaced mode support so can't really test this.
>
> I would expect that it would be better to just switch to flagless
> modes when available and accept doublescan and interlaced when not.
>
> eg. when you unplug an interlaced TV and plug in a progressive capable
> TV the mode would be upgraded. Also when the old TV had 1080i50 and
> the new has 1080i50 and 1080p60 I would pick the latter mode as user
> unless in a very special situation.
Problem is that if you go looking for a BETTER mode, the function
fb_find_NEAREST_mode would no longer behave like the name says.
It also poses problems when the user specifically asked for i50 because
p60 gives problems, e.g. when the display provides the wrong EDID
information and advertises modes it does not actually support.
Be aware that the function is not only called when a different display
is plugged in, but also when the link to the exact same display is
broken and restored (e.g. due to DPMS power saving).
Yours sincerely,
Floris Bos
^ permalink raw reply
* Re: [linux-sunxi] [PATCH] video/modedb: fb_find_nearest_mode: take vmode into account
From: Michal Suchanek @ 2013-02-11 14:06 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1360527814-28883-1-git-send-email-bos@je-eigen-domein.nl>
On 11 February 2013 14:52, Floris Bos <bos@je-eigen-domein.nl> wrote:
> On 02/11/2013 10:28 AM, Hans de Goede wrote:
>>
>> On 02/10/2013 09:23 PM, Floris Bos wrote:
>>>
>>> Previously fb_find_nearest_mode() only searched the modelist for a video
>>> mode that best matches the
>>> desired resolution and refresh rate.
>>> With this patch it also takes the vmode into account if there is more
>>> then one mode with the same
>>> resolution and refresh rate.
>>> Typical use case is HDMI TVs that support both 1080p60 and 1080i60
>>>
>>> Signed-off-by: Floris Bos <bos@je-eigen-domein.nl>
>>> ---
>>> drivers/video/modedb.c | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
>>> index a9a907c..e852371 100644
>>> --- a/drivers/video/modedb.c
>>> +++ b/drivers/video/modedb.c
>>> @@ -913,6 +913,8 @@ const struct fb_videomode *fb_find_best_mode(const
>>> struct fb_var_screeninfo *var
>>> * Finds best matching videomode, smaller or greater in dimension.
>>> * If more than 1 videomode is found, will return the videomode with
>>> * the closest refresh rate.
>>> + * If multiple modes with the same resolution and refresh rate are found
>>> + * pick the one with the matching vmode (e.g. non-interlaced)
>>> */
>>> const struct fb_videomode *fb_find_nearest_mode(const struct
>>> fb_videomode *mode,
>>> struct list_head *head)
>>> @@ -939,6 +941,8 @@ const struct fb_videomode *fb_find_nearest_mode(const
>>> struct fb_videomode *mode,
>>> if (diff_refresh > d) {
>>> diff_refresh = d;
>>> best = cmode;
>>> + } else if (diff_refresh = d && cmode->vmode = mode->vmode)
>>> {
>>> + best = cmode;
>>> }
>>> }
>>> }
>>>
>>
>> Hmm, my version of this patch was more conservative, only comparing the
>> INTERLACED bit
>> of vmode. I assume you've tested this, and it works as advertised? If so
>> ack.
>
>
> It works as advertised on my HDMI TV.
> fbcon_new_modelist() which uses fb_find_nearest_mode() no longer tries to
> switch from 1080p to 1080i after hot-plugging the same HDMI TV.
>
> But thinking of it, I wonder if it would be better to test on "vmode &
> FB_VMODE_MASK" instead though.
> So that it does tests on FB_VMODE_INTERLACED, FB_VMODE_DOUBLE and
> FB_VMODE_ODD_FLD_FIRST
> But not on FB_VMODE_YWRAP, FB_VMODE_SMOOTH_XPAN, FB_VMODE_CONUPDATE.
>
I don't have hardware with interlaced mode support so can't really test this.
I would expect that it would be better to just switch to flagless
modes when available and accept doublescan and interlaced when not.
eg. when you unplug an interlaced TV and plug in a progressive capable
TV the mode would be upgraded. Also when the old TV had 1080i50 and
the new has 1080i50 and 1080p60 I would pick the latter mode as user
unless in a very special situation.
Thanks
Michal
^ permalink raw reply
* Re: [linux-sunxi] [PATCH] video/modedb: fb_find_nearest_mode: take vmode into account
From: Floris Bos @ 2013-02-11 13:52 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1360527814-28883-1-git-send-email-bos@je-eigen-domein.nl>
On 02/11/2013 10:28 AM, Hans de Goede wrote:
> On 02/10/2013 09:23 PM, Floris Bos wrote:
>> Previously fb_find_nearest_mode() only searched the modelist for a
>> video mode that best matches the
>> desired resolution and refresh rate.
>> With this patch it also takes the vmode into account if there is more
>> then one mode with the same
>> resolution and refresh rate.
>> Typical use case is HDMI TVs that support both 1080p60 and 1080i60
>>
>> Signed-off-by: Floris Bos <bos@je-eigen-domein.nl>
>> ---
>> drivers/video/modedb.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
>> index a9a907c..e852371 100644
>> --- a/drivers/video/modedb.c
>> +++ b/drivers/video/modedb.c
>> @@ -913,6 +913,8 @@ const struct fb_videomode
>> *fb_find_best_mode(const struct fb_var_screeninfo *var
>> * Finds best matching videomode, smaller or greater in dimension.
>> * If more than 1 videomode is found, will return the videomode with
>> * the closest refresh rate.
>> + * If multiple modes with the same resolution and refresh rate are
>> found
>> + * pick the one with the matching vmode (e.g. non-interlaced)
>> */
>> const struct fb_videomode *fb_find_nearest_mode(const struct
>> fb_videomode *mode,
>> struct list_head *head)
>> @@ -939,6 +941,8 @@ const struct fb_videomode
>> *fb_find_nearest_mode(const struct fb_videomode *mode,
>> if (diff_refresh > d) {
>> diff_refresh = d;
>> best = cmode;
>> + } else if (diff_refresh = d && cmode->vmode =
>> mode->vmode) {
>> + best = cmode;
>> }
>> }
>> }
>>
>
> Hmm, my version of this patch was more conservative, only comparing
> the INTERLACED bit
> of vmode. I assume you've tested this, and it works as advertised? If
> so ack.
It works as advertised on my HDMI TV.
fbcon_new_modelist() which uses fb_find_nearest_mode() no longer tries
to switch from 1080p to 1080i after hot-plugging the same HDMI TV.
But thinking of it, I wonder if it would be better to test on "vmode &
FB_VMODE_MASK" instead though.
So that it does tests on FB_VMODE_INTERLACED, FB_VMODE_DOUBLE and
FB_VMODE_ODD_FLD_FIRST
But not on FB_VMODE_YWRAP, FB_VMODE_SMOOTH_XPAN, FB_VMODE_CONUPDATE.
Yours sincerely,
Floris Bos
^ permalink raw reply
* Re: [RFC PATCH 0/4] Common Display Framework-TF
From: Tomi Valkeinen @ 2013-02-11 10:14 UTC (permalink / raw)
To: Marcus Lorentzon
Cc: Tomasz Figa, Laurent Pinchart, Tomasz Figa,
dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
linux-samsung-soc@vger.kernel.org, kyungmin.park@samsung.com,
m.szyprowski@samsung.com, Daniel Vetter, Vikas Sajjan,
inki.dae@samsung.com, dh09.lee@samsung.com,
ville.syrjala@intel.com, s.nawrocki@samsung.com
In-Reply-To: <5118BA80.1020604@stericsson.com>
[-- Attachment #1: Type: text/plain, Size: 4844 bytes --]
On 2013-02-11 11:31, Marcus Lorentzon wrote:
> Ok, so what about a compromise which I think would work for "both" HWs
> ... we allow the "configure" operation during video on, then each HW
> driver could decide if this means you have to stop or not to do the
> changes required. But then it is also important that we keep all config
> in one struct and not split it up. Otherwise HW like ours that has so be
> stopped could need to stop once for each setting/operation called.
> So in short, allow configure(bus_params) during video on, keep all
> bus_params in the struct. It is in kernel struct so it can easily be
> changed/refactored.
Right, we need some way to group the configuration parameters. Either
one big struct, or something like start_config() and end_config(). I
think we could also think what parameters make no sense to be configured
on the fly, and possibly have those separately. Although it may be a bit
difficult to think of all the (weird) use cases.
> Again, this probing and bus muxing is platform/bus specific and not
> panel specific. Any panel of that type will only ever work on Omap (or
The parameters used for configuration itself is platform specific, and
that's why it needs to be defined in the DT data. But the API itself is
not platform specific. The parameters are information about how the
panel is connected, just like, say, number of data lines is for DPI.
Which is also something I think should be configured by the panel.
> someone else implementing the same muxing features) as I see it. So why
No, it works for everyone. Well, at least I still don't see anything
omap or platform specific in the API. Of course, if the platform/device
doesn't support modifying the pin functions, then the function does nothing.
> not just put that config on the bus master, dispc? I still can't see how
> this is panel config. You are only pushing CDF API and meta data to
> describe something that is only needed by one bus master. I have never
The information about how the panel is connected (the wiring) has to be
somewhere in the DT data. We could have the info in the DSI master or in
the DSI slave. Or, in some platforms where the DSS is not involved in
the muxing/config, the info could be totally separate, in the boards
pinmuxing data.
I think all those work ok for normal cases without hotplug. But if you
have hotplug, then you need separate pinmuxing/config data for each panel.
You could possibly have a list of panels in your DSI master node,
containing the muxing data, but that sounds rather hacky, and also very
hardcoded, i.e. you need to know each panel that is ever going to be
connected.
If, on the other hand, you have the info in the panel node, it "just
works". When a new panel is connected, the relevant panel DT data comes
from somewhere (it's not relevant where), and it tells the DSI master
how it's connected.
Something like this is probably needed for the BeagleBone capes, if you
have happened to follow the discussion. Although it could be argued that
the capes may perhaps be not runtime hotswappable, and thus the
configuration can be done only once during boot after the cape has been
probed. But I'd rather not design the API so that we prevent hot swapping.
> seen any DSI slave that can change their pin config. And since there is
Well, if omap is the only SoC/device out there that supports configuring
the pin functions, and everybody is against the API, I'm not going to
press it.
But then again, I think similar configuration support may be needed even
for the normal pinmuxing, even in the case where you can't reconfigure
the DSI pin functions. You still need to mux the pins (perhaps, say,
between DSI and a GPIO), depending on how many lanes the panel uses.
In fact, speaking about all pins in general, I'm not very fond of having
a static pinmuxing in the board DT data, handled by the board setup
code. I think generally the pins should be muxed to safe-mode by the
board setup code, and then configured to their proper function by the
driver when it is initializing.
> no generic hot plug detect of DSI panels, at least not before DSI bus is
> available, I have to assume this probing it very platform specific. We
> have some products that provide 1-2 gpios to specify what panel is
> available, some use I2C sensor probing to then assume the panel plugged.
Yes, the hotplug mechanism is platform/board specific. But that's not
relevant here.
> At least in the first step I don't think this type of hot plug should be
> in the API. Then once the base panel driver is in we could discuss
> different solutions for you hot plug scenario.
Yes, as I said, I also think we shouldn't aim for hotplug in the v1. But
we also shouldn't prevent it.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 0/4] Common Display Framework-TF
From: Marcus Lorentzon @ 2013-02-11 9:31 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Tomasz Figa, Laurent Pinchart, Tomasz Figa,
dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
linux-samsung-soc@vger.kernel.org, kyungmin.park@samsung.com,
m.szyprowski@samsung.com, Daniel Vetter, Vikas Sajjan,
inki.dae@samsung.com, dh09.lee@samsung.com,
ville.syrjala@intel.com, s.nawrocki@samsung.com
In-Reply-To: <5118AA00.2000505@ti.com>
On 02/11/2013 09:21 AM, Tomi Valkeinen wrote:
> On 2013-02-08 16:54, Marcus Lorentzon wrote:
>> On 02/08/2013 03:02 PM, Tomi Valkeinen wrote:
>>> On 2013-02-08 15:28, Marcus Lorentzon wrote:
>>>
>>>> When we do that we stop->setup->start during blanking. So our "DSS" is
>>>> optimized to be able to do that without getting blocked. All DSI video
>>>> mode panels (and DPI) products we have done so far have not had any
>>>> issue with that (as long as DSI HS clock is set to continuous). I think
>>>> this approach is less platform dependant, as long as there is no SoC
>>>> that take more than a blanking period to reconfigure.
>>> So do you stop, setup and start the link with CPU, and this has to be
>>> happen during blanking? Isn't that prone to errors? Or did you mean that
>>> the hardware handles that automatically?
>>>
>>> In OMAP DSS there are so called shadow registers, that can be programmed
>>> at any time. The you set a bit (GO bit), which tells the hardware to
>>> take the new settings into use at the next vblank.
>>>
>>> From DSI driver's perspective the link is never stopped when
>>> reconfiguring the video timings. However, many other settings have to be
>>> configured when the link is disabled.
>> Yeah, you lucky guys with the GO bit ;). No, we actually do CPU
>> stop,setup,start. But since it is video mode, master is driving the sync
>> so it is not a hard deadline. It is enough to restart before pixels
>> start to degrade. On an LCD that is not so much time, but on an OLED it
>> could be 10 secs :). Anyway, we have had several mass products with this
>> soft solution and it has worked well.
> Ah, ok. But in that case what you said in an earlier mail is not quite
> correct: "I think this approach is less platform dependant, as long as
> there is no SoC that take more than a blanking period to reconfigure.".
> So in your approach the reconfiguration doesn't have to be done inside
> the blanking period, but before the panel's picture starts to fade?
>
> I don't know... It's early Monday morning, and not enough coffee yet,
> but I get a bit uneasy feeling if I think that your method of
> reconfiguring would be the only think allowed by the CDF API.
>
> Some SoCs do support reconfiguring on the fly, without disabling the
> link. It would not be nice if we didn't allow this to happen. And
> actually, we're not only talking about SoCs here, but also any display
> devices, like external buffer chips etc. They may also offer means to
> change configs on the fly.
>
> Well, I don't have any hard point about this at the moment, but I think
> we should think different approaches how the configuration can be done.
Ok, so what about a compromise which I think would work for "both" HWs
... we allow the "configure" operation during video on, then each HW
driver could decide if this means you have to stop or not to do the
changes required. But then it is also important that we keep all config
in one struct and not split it up. Otherwise HW like ours that has so be
stopped could need to stop once for each setting/operation called.
So in short, allow configure(bus_params) during video on, keep all
bus_params in the struct. It is in kernel struct so it can easily be
changed/refactored.
>
>> I understand, but removing the omap prefix doesn't mean it has to go in
>> the panel slave port/bus settings. I still can't see why this should be
>> configuration on the panel driver and not the DSI master driver. Number
>> of pins might be useful since you might start with one lane and then
>> activate the rest. But partial muxing (pre pinmux) doesn't seem to be
>> something the panel should control or know anything about. Sounds like
>> normal platform/DT data per product/board.
> I think one case where this kind of pin configuration is needed, and
> which also dictates that all panel related configuration has to be in
> the panel's data, not in the DSI master's data, is hotplug.
>
> If you have a board that has two panels connected to the same video
> output, probably via some kind of mux, at least for the sensitive pins
> like DSI, only one of the panels can be enabled at a time. The panels
> can have different wiring, and thus the panel driver would need to
> configure everything related to the bus when it's starting up.
>
> The same also happens if you have a true hotplug, i.e. you can remove
> the panel totally and plug in a new one. Again the wiring can be
> different, and needs to be set up.
>
> And, as I said, this means that all relevant data about the video bus
> has to be in the panel's data, so that each panel can have its own set
> of, say, pin configuration.
>
> Hotplug is not a use case we should aim to support for the CDF v1, but I
> think we should strive not to prevent hotplug either. So if we can
> design the API so that hotplug is possible, I say let's do that.
>
Again, this probing and bus muxing is platform/bus specific and not
panel specific. Any panel of that type will only ever work on Omap (or
someone else implementing the same muxing features) as I see it. So why
not just put that config on the bus master, dispc? I still can't see how
this is panel config. You are only pushing CDF API and meta data to
describe something that is only needed by one bus master. I have never
seen any DSI slave that can change their pin config. And since there is
no generic hot plug detect of DSI panels, at least not before DSI bus is
available, I have to assume this probing it very platform specific. We
have some products that provide 1-2 gpios to specify what panel is
available, some use I2C sensor probing to then assume the panel plugged.
At least in the first step I don't think this type of hot plug should be
in the API. Then once the base panel driver is in we could discuss
different solutions for you hot plug scenario.
/BR
/Marcus
^ permalink raw reply
* Re: [linux-sunxi] [PATCH] video/modedb: fb_find_nearest_mode: take vmode into account
From: Hans de Goede @ 2013-02-11 9:28 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1360527814-28883-1-git-send-email-bos@je-eigen-domein.nl>
Hi,
On 02/10/2013 09:23 PM, Floris Bos wrote:
> Previously fb_find_nearest_mode() only searched the modelist for a video mode that best matches the
> desired resolution and refresh rate.
> With this patch it also takes the vmode into account if there is more then one mode with the same
> resolution and refresh rate.
> Typical use case is HDMI TVs that support both 1080p60 and 1080i60
>
> Signed-off-by: Floris Bos <bos@je-eigen-domein.nl>
> ---
> drivers/video/modedb.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
> index a9a907c..e852371 100644
> --- a/drivers/video/modedb.c
> +++ b/drivers/video/modedb.c
> @@ -913,6 +913,8 @@ const struct fb_videomode *fb_find_best_mode(const struct fb_var_screeninfo *var
> * Finds best matching videomode, smaller or greater in dimension.
> * If more than 1 videomode is found, will return the videomode with
> * the closest refresh rate.
> + * If multiple modes with the same resolution and refresh rate are found
> + * pick the one with the matching vmode (e.g. non-interlaced)
> */
> const struct fb_videomode *fb_find_nearest_mode(const struct fb_videomode *mode,
> struct list_head *head)
> @@ -939,6 +941,8 @@ const struct fb_videomode *fb_find_nearest_mode(const struct fb_videomode *mode,
> if (diff_refresh > d) {
> diff_refresh = d;
> best = cmode;
> + } else if (diff_refresh = d && cmode->vmode = mode->vmode) {
> + best = cmode;
> }
> }
> }
>
Hmm, my version of this patch was more conservative, only comparing the INTERLACED bit
of vmode. I assume you've tested this, and it works as advertised? If so ack.
Regards,
Hans
^ permalink raw reply
* Re: [RFC PATCH 0/4] Common Display Framework-TF
From: Tomi Valkeinen @ 2013-02-11 8:21 UTC (permalink / raw)
To: Marcus Lorentzon
Cc: Tomasz Figa, Laurent Pinchart, Tomasz Figa,
dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
linux-samsung-soc@vger.kernel.org, kyungmin.park@samsung.com,
m.szyprowski@samsung.com, Daniel Vetter, Vikas Sajjan,
inki.dae@samsung.com, dh09.lee@samsung.com,
ville.syrjala@intel.com, s.nawrocki@samsung.com
In-Reply-To: <511511B3.3060404@stericsson.com>
[-- Attachment #1: Type: text/plain, Size: 4218 bytes --]
On 2013-02-08 16:54, Marcus Lorentzon wrote:
> On 02/08/2013 03:02 PM, Tomi Valkeinen wrote:
>> On 2013-02-08 15:28, Marcus Lorentzon wrote:
>>
>>> When we do that we stop->setup->start during blanking. So our "DSS" is
>>> optimized to be able to do that without getting blocked. All DSI video
>>> mode panels (and DPI) products we have done so far have not had any
>>> issue with that (as long as DSI HS clock is set to continuous). I think
>>> this approach is less platform dependant, as long as there is no SoC
>>> that take more than a blanking period to reconfigure.
>> So do you stop, setup and start the link with CPU, and this has to be
>> happen during blanking? Isn't that prone to errors? Or did you mean that
>> the hardware handles that automatically?
>>
>> In OMAP DSS there are so called shadow registers, that can be programmed
>> at any time. The you set a bit (GO bit), which tells the hardware to
>> take the new settings into use at the next vblank.
>>
>> From DSI driver's perspective the link is never stopped when
>> reconfiguring the video timings. However, many other settings have to be
>> configured when the link is disabled.
>
> Yeah, you lucky guys with the GO bit ;). No, we actually do CPU
> stop,setup,start. But since it is video mode, master is driving the sync
> so it is not a hard deadline. It is enough to restart before pixels
> start to degrade. On an LCD that is not so much time, but on an OLED it
> could be 10 secs :). Anyway, we have had several mass products with this
> soft solution and it has worked well.
Ah, ok. But in that case what you said in an earlier mail is not quite
correct: "I think this approach is less platform dependant, as long as
there is no SoC that take more than a blanking period to reconfigure.".
So in your approach the reconfiguration doesn't have to be done inside
the blanking period, but before the panel's picture starts to fade?
I don't know... It's early Monday morning, and not enough coffee yet,
but I get a bit uneasy feeling if I think that your method of
reconfiguring would be the only think allowed by the CDF API.
Some SoCs do support reconfiguring on the fly, without disabling the
link. It would not be nice if we didn't allow this to happen. And
actually, we're not only talking about SoCs here, but also any display
devices, like external buffer chips etc. They may also offer means to
change configs on the fly.
Well, I don't have any hard point about this at the moment, but I think
we should think different approaches how the configuration can be done.
> I understand, but removing the omap prefix doesn't mean it has to go in
> the panel slave port/bus settings. I still can't see why this should be
> configuration on the panel driver and not the DSI master driver. Number
> of pins might be useful since you might start with one lane and then
> activate the rest. But partial muxing (pre pinmux) doesn't seem to be
> something the panel should control or know anything about. Sounds like
> normal platform/DT data per product/board.
I think one case where this kind of pin configuration is needed, and
which also dictates that all panel related configuration has to be in
the panel's data, not in the DSI master's data, is hotplug.
If you have a board that has two panels connected to the same video
output, probably via some kind of mux, at least for the sensitive pins
like DSI, only one of the panels can be enabled at a time. The panels
can have different wiring, and thus the panel driver would need to
configure everything related to the bus when it's starting up.
The same also happens if you have a true hotplug, i.e. you can remove
the panel totally and plug in a new one. Again the wiring can be
different, and needs to be set up.
And, as I said, this means that all relevant data about the video bus
has to be in the panel's data, so that each panel can have its own set
of, say, pin configuration.
Hotplug is not a use case we should aim to support for the CDF v1, but I
think we should strive not to prevent hotplug either. So if we can
design the API so that hotplug is possible, I say let's do that.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/1] OMAP4: DSS: Add panel for Blaze Tablet boards
From: Andi Shyti @ 2013-02-10 23:51 UTC (permalink / raw)
To: Ruslan Bilovol
Cc: andi, tomi.valkeinen, FlorianSchandinat, linux-fbdev,
linux-kernel, linux-omap
In-Reply-To: <1360338220-12753-2-git-send-email-ruslan.bilovol@ti.com>
Hi Ruslan,
> TC358765 is DSI-to-LVDS transmitter from Toshiba, used in
> OMAP44XX Blaze Tablet and Blaze Tablet2 boards.
I think it's fine, just some nitpicks and checkpatch warnings
> +struct {
> + struct device *dev;
> + struct dentry *dir;
> +} tc358765_debug;
Should this be static?
> +struct tc358765_reg {
> + const char *name;
> + u16 reg;
> + u8 perm:2;
> +} tc358765_regs[] = {
Should this be static as well?
> + { "D1S_ZERO", D1S_ZERO, A_RW },
> + { "D2S_ZERO", D2S_ZERO, A_RW },
> + { "D3S_ZERO", D3S_ZERO, A_RW },
> + { "PPI_CLRFLG", PPI_CLRFLG, A_RW },
> + { "PPI_CLRSIPO", PPI_CLRSIPO, A_RW },
> + { "PPI_HSTimeout", PPI_HSTimeout, A_RW },
WARNING: Avoid CamelCase: <PPI_HSTimeout>
#136: FILE: video/omap2/displays/panel-tc358765.c:136:
+ { "PPI_HSTimeout", PPI_HSTimeout, A_RW },
> + { "PPI_HSTimeoutEnable", PPI_HSTimeoutEnable, A_RW },
WARNING: Avoid CamelCase: <PPI_HSTimeoutEnable>
#137: FILE: video/omap2/displays/panel-tc358765.c:137:
+ { "PPI_HSTimeoutEnable", PPI_HSTimeoutEnable, A_RW },
> +static int tc358765_read_block(u16 reg, u8 *data, int len)
> +{
> + unsigned char wb[2];
> + struct i2c_msg msg[2];
> + int r;
> + mutex_lock(&tc358765_i2c->xfer_lock);
> + wb[0] = (reg & 0xff00) >> 8;
> + wb[1] = reg & 0xff;
> + msg[0].addr = tc358765_i2c->client->addr;
> + msg[0].len = 2;
> + msg[0].flags = 0;
> + msg[0].buf = wb;
> + msg[1].addr = tc358765_i2c->client->addr;
> + msg[1].flags = I2C_M_RD;
> + msg[1].len = len;
> + msg[1].buf = data;
> +
> + r = i2c_transfer(tc358765_i2c->client->adapter, msg, ARRAY_SIZE(msg));
> + mutex_unlock(&tc358765_i2c->xfer_lock);
> +
> + if (r = ARRAY_SIZE(msg))
> + return len;
> +
> + return r;
If you like, here you could do
return (r = ARRAY_SIZE(msg)) ? len : r;
Usually I like more this notation because keeps the code more
compact and immediate to read, but you don't have to
> + mutex_lock(&tc358765_i2c->xfer_lock);
> + ret = i2c_transfer(tc358765_i2c->client->adapter, &msg, 1);
> + mutex_unlock(&tc358765_i2c->xfer_lock);
> +
> + if (ret != 1)
> + return ret;
> + return 0;
Also here you could do
return (ret != 1) ? ret : 0;
But this is more taste :)
> +static ssize_t tc358765_seq_write(struct file *filp, const char __user *ubuf,
> + size_t size, loff_t *ppos)
> +{
> + struct device *dev = tc358765_debug.dev;
> + unsigned i, reg_count;
> + u32 value = 0;
> + int error = 0;
> + /* kids, don't use register names that long */
I won't, promised, but please, drop this comment :)
> + char name[30];
> + char buf[50];
> +
> + if (size >= sizeof(buf))
> + size = sizeof(buf);
what's the point of this?
> +static void tc358765_uninitialize_debugfs(void)
> +{
> + if (tc358765_debug.dir)
> + debugfs_remove_recursive(tc358765_debug.dir);
WARNING: debugfs_remove_recursive(NULL) is safe this check is probably not required
#435: FILE: video/omap2/displays/panel-tc358765.c:435:
+ if (tc358765_debug.dir)
+ debugfs_remove_recursive(tc358765_debug.dir);
> +static struct tc358765_board_data *get_board_data(struct omap_dss_device
> + *dssdev)
> +{
> + return (struct tc358765_board_data *)dssdev->data;
You shouldn't need for this cast, does it complain?
> +}
> +
> +static void tc358765_get_timings(struct omap_dss_device *dssdev,
> + struct omap_video_timings *timings)
> +{
> + *timings = dssdev->panel.timings;
> +}
> +
> +static void tc358765_set_timings(struct omap_dss_device *dssdev,
> + struct omap_video_timings *timings)
> +{
> + dev_info(&dssdev->dev, "set_timings() not implemented\n");
... then drop the function :)
> + if ((pins[2] & 1) || (pins[3] & 1)) {
> + lanes |= (1 << 1);
> + ret |= tc358765_write_register(dssdev, PPI_D0S_CLRSIPOCOUNT,
> + board_data->clrsipo);
> + }
> + if ((pins[4] & 1) || (pins[5] & 1)) {
> + lanes |= (1 << 2);
> + ret |= tc358765_write_register(dssdev, PPI_D1S_CLRSIPOCOUNT,
> + board_data->clrsipo);
> + }
> + if ((pins[6] & 1) || (pins[7] & 1)) {
> + lanes |= (1 << 3);
> + ret |= tc358765_write_register(dssdev, PPI_D2S_CLRSIPOCOUNT,
> + board_data->clrsipo);
> + }
> + if ((pins[8] & 1) || (pins[9] & 1)) {
> + lanes |= (1 << 4);
> + ret |= tc358765_write_register(dssdev, PPI_D3S_CLRSIPOCOUNT,
> + board_data->clrsipo);
> + }
Can't this be done in one single multiwrighting command since
this registers are consecutive?
You build once the array to write and you send it at once.
Moreover it would be nice to have a name for all those nombers
> + ret |= tc358765_write_register(dssdev, HTIM1,
> + (tc358765_timings.hbp << 16) | tc358765_timings.hsw);
> + ret |= tc358765_write_register(dssdev, HTIM2,
> + ((tc358765_timings.hfp << 16) | tc358765_timings.x_res));
> + ret |= tc358765_write_register(dssdev, VTIM1,
> + ((tc358765_timings.vbp << 16) | tc358765_timings.vsw));
> + ret |= tc358765_write_register(dssdev, VTIM2,
> + ((tc358765_timings.vfp << 16) | tc358765_timings.y_res));
also this and all the other cases I haven't checked
> +static int tc358765_enable(struct omap_dss_device *dssdev)
> +{
> + struct tc358765_data *d2d = dev_get_drvdata(&dssdev->dev);
> + int r = 0;
this initialisation is useless
> + if (r) {
> + dev_dbg(&dssdev->dev, "enable failed\n");
Here you could choose a different print level, I would have used
dev_err instead.
> +static int tc358765_i2c_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + tc358765_i2c = devm_kzalloc(&client->dev, sizeof(*tc358765_i2c), GFP_KERNEL);
WARNING: line over 80 characters
#927: FILE: video/omap2/displays/panel-tc358765.c:927:
+ tc358765_i2c = devm_kzalloc(&client->dev, sizeof(*tc358765_i2c), GFP_KERNEL);
> + /* store i2c_client pointer on private data structure */
> + tc358765_i2c->client = client;
> +
> + /* store private data structure pointer on i2c_client structure */
> + i2c_set_clientdata(client, tc358765_i2c);
> +
> + /* init mutex */
> + mutex_init(&tc358765_i2c->xfer_lock);
> + dev_err(&client->dev, "D2L i2c initialized\n");
while here dev_dbg (or dev_info) are better.
> +static int __init tc358765_init(void)
> +{
> + int r;
> + tc358765_i2c = NULL;
> + r = i2c_add_driver(&tc358765_i2c_driver);
> + if (r < 0) {
> + printk(KERN_WARNING "d2l i2c driver registration failed\n");
WARNING: Prefer netdev_warn(netdev, ... then dev_warn(dev, ... then pr_warn(... to printk(KERN_WARNING ...
#981: FILE: video/omap2/displays/panel-tc358765.c:981:
+ printk(KERN_WARNING "d2l i2c driver registration failed\n");
Andi
^ permalink raw reply
* [PATCH] video/modedb: fb_find_nearest_mode: take vmode into account
From: Floris Bos @ 2013-02-10 20:23 UTC (permalink / raw)
To: linux-fbdev
Previously fb_find_nearest_mode() only searched the modelist for a video mode that best matches the
desired resolution and refresh rate.
With this patch it also takes the vmode into account if there is more then one mode with the same
resolution and refresh rate.
Typical use case is HDMI TVs that support both 1080p60 and 1080i60
Signed-off-by: Floris Bos <bos@je-eigen-domein.nl>
---
drivers/video/modedb.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
index a9a907c..e852371 100644
--- a/drivers/video/modedb.c
+++ b/drivers/video/modedb.c
@@ -913,6 +913,8 @@ const struct fb_videomode *fb_find_best_mode(const struct fb_var_screeninfo *var
* Finds best matching videomode, smaller or greater in dimension.
* If more than 1 videomode is found, will return the videomode with
* the closest refresh rate.
+ * If multiple modes with the same resolution and refresh rate are found
+ * pick the one with the matching vmode (e.g. non-interlaced)
*/
const struct fb_videomode *fb_find_nearest_mode(const struct fb_videomode *mode,
struct list_head *head)
@@ -939,6 +941,8 @@ const struct fb_videomode *fb_find_nearest_mode(const struct fb_videomode *mode,
if (diff_refresh > d) {
diff_refresh = d;
best = cmode;
+ } else if (diff_refresh = d && cmode->vmode = mode->vmode) {
+ best = cmode;
}
}
}
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 0/5] at91: atmel_lcdfb: regression fixes and cpu_is removal
From: Johan Hovold @ 2013-02-10 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130210004740.GH16278@quad.lixom.net>
On Sun, Feb 10, 2013 at 1:47 AM, Olof Johansson <olof@lixom.net> wrote:
> On Fri, Feb 08, 2013 at 05:35:13PM +0100, Nicolas Ferre wrote:
>> These patches fix a regression in 16-bpp support for older SOCs which
>> use IBGR:555 rather than BGR:565 pixel layout. Use SOC-type to
>> determine if the controller uses the intensity-bit and restore the
>> old layout in that case.
>>
>> The last patch is a removal of uses of cpu_is_xxxx() macros in
>> atmel_lcdfb with a platform-device-id table and static
>> configurations.
>>
>>
>> Patches from Johan Hovold taken from: "[PATCH 0/3] atmel_lcdfb: fix
>> 16-bpp regression" and "[PATCH v2 0/3] ARM: at91/avr32/atmel_lcdfb:
>> remove cpu_is macros" patch series to form a clean patch series with
>> my signature.
>>
>> Arnd, Olof, as it seems that old fbdev drivers are not so much
>> reviewed those days, can we take the decision to queue this material
>> through arm-soc with other AT91 drivers updates?
>
> It would be beneficial to get an ack from Florian. Was he involved in
> the review of the code that regressed 16-bpp support in the first
> place? When was the regression introduced?
In v3.4 by commit 787f9fd2328 ("atmel_lcdfb: support 16bit BGR:565 mode,
remove unsupported 15bit modes").
Johan
^ permalink raw reply
* Re: [PATCH 0/5] at91: atmel_lcdfb: regression fixes and cpu_is removal
From: Olof Johansson @ 2013-02-10 0:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1360340791.git.nicolas.ferre@atmel.com>
On Fri, Feb 08, 2013 at 05:35:13PM +0100, Nicolas Ferre wrote:
> These patches fix a regression in 16-bpp support for older SOCs which use
> IBGR:555 rather than BGR:565 pixel layout. Use SOC-type to determine if the
> controller uses the intensity-bit and restore the old layout in that case.
>
> The last patch is a removal of uses of cpu_is_xxxx() macros in atmel_lcdfb with
> a platform-device-id table and static configurations.
>
>
> Patches from Johan Hovold taken from:
> "[PATCH 0/3] atmel_lcdfb: fix 16-bpp regression"
> and
> "[PATCH v2 0/3] ARM: at91/avr32/atmel_lcdfb: remove cpu_is macros"
> patch series to form a clean patch series with my signature.
>
> Arnd, Olof,
> as it seems that old fbdev drivers are not so much reviewed those days, can we
> take the decision to queue this material through arm-soc with other AT91
> drivers updates?
It would be beneficial to get an ack from Florian. Was he involved in the
review of the code that regressed 16-bpp support in the first place? When was
the regression introduced?
-Olof
^ permalink raw reply
* Re: [PATCH 0/5] at91: atmel_lcdfb: regression fixes and cpu_is removal
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-02-08 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1360340791.git.nicolas.ferre@atmel.com>
HI,
on all
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Best Regards,
J.
On 17:35 Fri 08 Feb , Nicolas Ferre wrote:
> These patches fix a regression in 16-bpp support for older SOCs which use
> IBGR:555 rather than BGR:565 pixel layout. Use SOC-type to determine if the
> controller uses the intensity-bit and restore the old layout in that case.
>
> The last patch is a removal of uses of cpu_is_xxxx() macros in atmel_lcdfb with
> a platform-device-id table and static configurations.
>
>
> Patches from Johan Hovold taken from:
> "[PATCH 0/3] atmel_lcdfb: fix 16-bpp regression"
> and
> "[PATCH v2 0/3] ARM: at91/avr32/atmel_lcdfb: remove cpu_is macros"
> patch series to form a clean patch series with my signature.
>
> Arnd, Olof,
> as it seems that old fbdev drivers are not so much reviewed those days, can we
> take the decision to queue this material through arm-soc with other AT91
> drivers updates?
>
> Best regards,
>
> Johan Hovold (5):
> atmel_lcdfb: fix 16-bpp modes on older SOCs
> ARM: at91/neocore926: fix LCD-wiring mode
> ARM: at91/avr32/atmel_lcdfb: add bus-clock entry
> atmel_lcdfb: move lcdcon2 register access to compute_hozval
> ARM: at91/avr32/atmel_lcdfb: add platform device-id table
>
> arch/arm/mach-at91/at91sam9261.c | 2 +
> arch/arm/mach-at91/at91sam9261_devices.c | 6 +-
> arch/arm/mach-at91/at91sam9263.c | 1 +
> arch/arm/mach-at91/at91sam9263_devices.c | 2 +-
> arch/arm/mach-at91/at91sam9g45.c | 2 +
> arch/arm/mach-at91/at91sam9g45_devices.c | 6 +-
> arch/arm/mach-at91/at91sam9rl.c | 1 +
> arch/arm/mach-at91/at91sam9rl_devices.c | 2 +-
> arch/arm/mach-at91/board-neocore926.c | 2 +-
> arch/avr32/mach-at32ap/at32ap700x.c | 6 +-
> drivers/video/atmel_lcdfb.c | 130 ++++++++++++++++++++++++-------
> include/video/atmel_lcdc.h | 4 +-
> 12 files changed, 127 insertions(+), 37 deletions(-)
>
> --
> 1.8.0
>
^ permalink raw reply
* [PATCH 5/5] ARM: at91/avr32/atmel_lcdfb: add platform device-id table
From: Nicolas Ferre @ 2013-02-08 16:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1360340791.git.nicolas.ferre@atmel.com>
From: Johan Hovold <jhovold@gmail.com>
Add platform device-id table in order to identify the controller and
determine its configuration.
The currently used configuration parameters are:
have_alt_pixclock
- SOC uses an alternate pixel-clock calculation formula (at91sam9g45
non-ES)
have_hozval
- SOC has a HOZVAL field in LCDFRMCFG which is used to determine the
linesize for STN displays (at91sam9261, at921sam9g10 and at32ap)
have_intensity_bit
- SOC uses IBGR:555 rather than BGR:565 16-bit pixel layout
(at91sam9261, at91sam9263 and at91sam9rl)
This allows us to remove all the remaining uses of cpu_is macros from
the driver.
Tested on at91sam9263 and at91sam9g45, compile-tested for other
AT91-SOCs, and untested for AVR32.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/mach-at91/at91sam9261.c | 3 +-
arch/arm/mach-at91/at91sam9261_devices.c | 6 ++-
arch/arm/mach-at91/at91sam9263.c | 2 +-
arch/arm/mach-at91/at91sam9263_devices.c | 2 +-
arch/arm/mach-at91/at91sam9g45.c | 3 +-
arch/arm/mach-at91/at91sam9g45_devices.c | 6 ++-
arch/arm/mach-at91/at91sam9rl.c | 2 +-
arch/arm/mach-at91/at91sam9rl_devices.c | 2 +-
arch/avr32/mach-at32ap/at32ap700x.c | 2 +
drivers/video/atmel_lcdfb.c | 89 ++++++++++++++++++++++++++++----
include/video/atmel_lcdc.h | 4 +-
11 files changed, 102 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-at91/at91sam9261.c b/arch/arm/mach-at91/at91sam9261.c
index 5838f12..0204f4c 100644
--- a/arch/arm/mach-at91/at91sam9261.c
+++ b/arch/arm/mach-at91/at91sam9261.c
@@ -169,7 +169,8 @@ static struct clk *periph_clocks[] __initdata = {
};
static struct clk_lookup periph_clocks_lookups[] = {
- CLKDEV_CON_DEV_ID("hclk", "atmel_lcdfb.0", &hck1),
+ CLKDEV_CON_DEV_ID("hclk", "at91sam9261-lcdfb.0", &hck1),
+ CLKDEV_CON_DEV_ID("hclk", "at91sam9g10-lcdfb.0", &hck1),
CLKDEV_CON_DEV_ID("spi_clk", "atmel_spi.0", &spi0_clk),
CLKDEV_CON_DEV_ID("spi_clk", "atmel_spi.1", &spi1_clk),
CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.0", &tc0_clk),
diff --git a/arch/arm/mach-at91/at91sam9261_devices.c b/arch/arm/mach-at91/at91sam9261_devices.c
index 92e0f86..629ea5f 100644
--- a/arch/arm/mach-at91/at91sam9261_devices.c
+++ b/arch/arm/mach-at91/at91sam9261_devices.c
@@ -488,7 +488,6 @@ static struct resource lcdc_resources[] = {
};
static struct platform_device at91_lcdc_device = {
- .name = "atmel_lcdfb",
.id = 0,
.dev = {
.dma_mask = &lcdc_dmamask,
@@ -505,6 +504,11 @@ void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data)
return;
}
+ if (cpu_is_at91sam9g10())
+ at91_lcdc_device.name = "at91sam9g10-lcdfb";
+ else
+ at91_lcdc_device.name = "at91sam9261-lcdfb";
+
#if defined(CONFIG_FB_ATMEL_STN)
at91_set_A_periph(AT91_PIN_PB0, 0); /* LCDVSYNC */
at91_set_A_periph(AT91_PIN_PB1, 0); /* LCDHSYNC */
diff --git a/arch/arm/mach-at91/at91sam9263.c b/arch/arm/mach-at91/at91sam9263.c
index 520a63d..2282fd7 100644
--- a/arch/arm/mach-at91/at91sam9263.c
+++ b/arch/arm/mach-at91/at91sam9263.c
@@ -190,7 +190,7 @@ static struct clk_lookup periph_clocks_lookups[] = {
CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk),
CLKDEV_CON_DEV_ID("pclk", "fff98000.ssc", &ssc0_clk),
CLKDEV_CON_DEV_ID("pclk", "fff9c000.ssc", &ssc1_clk),
- CLKDEV_CON_DEV_ID("hclk", "atmel_lcdfb.0", &lcdc_clk),
+ CLKDEV_CON_DEV_ID("hclk", "at91sam9263-lcdfb.0", &lcdc_clk),
CLKDEV_CON_DEV_ID("mci_clk", "atmel_mci.0", &mmc0_clk),
CLKDEV_CON_DEV_ID("mci_clk", "atmel_mci.1", &mmc1_clk),
CLKDEV_CON_DEV_ID("spi_clk", "atmel_spi.0", &spi0_clk),
diff --git a/arch/arm/mach-at91/at91sam9263_devices.c b/arch/arm/mach-at91/at91sam9263_devices.c
index ed666f5..858c8aa 100644
--- a/arch/arm/mach-at91/at91sam9263_devices.c
+++ b/arch/arm/mach-at91/at91sam9263_devices.c
@@ -848,7 +848,7 @@ static struct resource lcdc_resources[] = {
};
static struct platform_device at91_lcdc_device = {
- .name = "atmel_lcdfb",
+ .name = "at91sam9263-lcdfb",
.id = 0,
.dev = {
.dma_mask = &lcdc_dmamask,
diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c
index ea6b62b..c68960d 100644
--- a/arch/arm/mach-at91/at91sam9g45.c
+++ b/arch/arm/mach-at91/at91sam9g45.c
@@ -228,7 +228,8 @@ static struct clk_lookup periph_clocks_lookups[] = {
CLKDEV_CON_ID("hclk", &macb_clk),
/* One additional fake clock for ohci */
CLKDEV_CON_ID("ohci_clk", &uhphs_clk),
- CLKDEV_CON_DEV_ID("hclk", "atmel_lcdfb.0", &lcdc_clk),
+ CLKDEV_CON_DEV_ID("hclk", "at91sam9g45-lcdfb.0", &lcdc_clk),
+ CLKDEV_CON_DEV_ID("hclk", "at91sam9g45es-lcdfb.0", &lcdc_clk),
CLKDEV_CON_DEV_ID("ehci_clk", "atmel-ehci", &uhphs_clk),
CLKDEV_CON_DEV_ID("hclk", "atmel_usba_udc", &utmi_clk),
CLKDEV_CON_DEV_ID("pclk", "atmel_usba_udc", &udphs_clk),
diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c b/arch/arm/mach-at91/at91sam9g45_devices.c
index 827c9f2..fe626d4 100644
--- a/arch/arm/mach-at91/at91sam9g45_devices.c
+++ b/arch/arm/mach-at91/at91sam9g45_devices.c
@@ -981,7 +981,6 @@ static struct resource lcdc_resources[] = {
};
static struct platform_device at91_lcdc_device = {
- .name = "atmel_lcdfb",
.id = 0,
.dev = {
.dma_mask = &lcdc_dmamask,
@@ -997,6 +996,11 @@ void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data)
if (!data)
return;
+ if (cpu_is_at91sam9g45es())
+ at91_lcdc_device.name = "at91sam9g45es-lcdfb";
+ else
+ at91_lcdc_device.name = "at91sam9g45-lcdfb";
+
at91_set_A_periph(AT91_PIN_PE0, 0); /* LCDDPWR */
at91_set_A_periph(AT91_PIN_PE2, 0); /* LCDCC */
diff --git a/arch/arm/mach-at91/at91sam9rl.c b/arch/arm/mach-at91/at91sam9rl.c
index 4cd4fa9..3de3e04 100644
--- a/arch/arm/mach-at91/at91sam9rl.c
+++ b/arch/arm/mach-at91/at91sam9rl.c
@@ -179,7 +179,7 @@ static struct clk *periph_clocks[] __initdata = {
};
static struct clk_lookup periph_clocks_lookups[] = {
- CLKDEV_CON_DEV_ID("hclk", "atmel_lcdfb.0", &lcdc_clk),
+ CLKDEV_CON_DEV_ID("hclk", "at91sam9rl-lcdfb.0", &lcdc_clk),
CLKDEV_CON_DEV_ID("hclk", "atmel_usba_udc", &utmi_clk),
CLKDEV_CON_DEV_ID("pclk", "atmel_usba_udc", &udphs_clk),
CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.0", &tc0_clk),
diff --git a/arch/arm/mach-at91/at91sam9rl_devices.c b/arch/arm/mach-at91/at91sam9rl_devices.c
index ddf223f..352468f 100644
--- a/arch/arm/mach-at91/at91sam9rl_devices.c
+++ b/arch/arm/mach-at91/at91sam9rl_devices.c
@@ -514,7 +514,7 @@ static struct resource lcdc_resources[] = {
};
static struct platform_device at91_lcdc_device = {
- .name = "atmel_lcdfb",
+ .name = "at91sam9rl-lcdfb",
.id = 0,
.dev = {
.dma_mask = &lcdc_dmamask,
diff --git a/arch/avr32/mach-at32ap/at32ap700x.c b/arch/avr32/mach-at32ap/at32ap700x.c
index cd25b01..7c2f668 100644
--- a/arch/avr32/mach-at32ap/at32ap700x.c
+++ b/arch/avr32/mach-at32ap/at32ap700x.c
@@ -1530,6 +1530,8 @@ at32_add_device_lcdc(unsigned int id, struct atmel_lcdfb_info *data,
memcpy(info, data, sizeof(struct atmel_lcdfb_info));
info->default_monspecs = monspecs;
+ pdev->name = "at32ap-lcdfb";
+
platform_device_register(pdev);
return pdev;
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index 2effd35..c1a2914 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -34,6 +34,77 @@
#define ATMEL_LCDC_DMA_BURST_LEN 8 /* words */
#define ATMEL_LCDC_FIFO_SIZE 512 /* words */
+struct atmel_lcdfb_config {
+ bool have_alt_pixclock;
+ bool have_hozval;
+ bool have_intensity_bit;
+};
+
+static struct atmel_lcdfb_config at91sam9261_config = {
+ .have_hozval = true,
+ .have_intensity_bit = true,
+};
+
+static struct atmel_lcdfb_config at91sam9263_config = {
+ .have_intensity_bit = true,
+};
+
+static struct atmel_lcdfb_config at91sam9g10_config = {
+ .have_hozval = true,
+};
+
+static struct atmel_lcdfb_config at91sam9g45_config = {
+ .have_alt_pixclock = true,
+};
+
+static struct atmel_lcdfb_config at91sam9g45es_config = {
+};
+
+static struct atmel_lcdfb_config at91sam9rl_config = {
+ .have_intensity_bit = true,
+};
+
+static struct atmel_lcdfb_config at32ap_config = {
+ .have_hozval = true,
+};
+
+static const struct platform_device_id atmel_lcdfb_devtypes[] = {
+ {
+ .name = "at91sam9261-lcdfb",
+ .driver_data = (unsigned long)&at91sam9261_config,
+ }, {
+ .name = "at91sam9263-lcdfb",
+ .driver_data = (unsigned long)&at91sam9263_config,
+ }, {
+ .name = "at91sam9g10-lcdfb",
+ .driver_data = (unsigned long)&at91sam9g10_config,
+ }, {
+ .name = "at91sam9g45-lcdfb",
+ .driver_data = (unsigned long)&at91sam9g45_config,
+ }, {
+ .name = "at91sam9g45es-lcdfb",
+ .driver_data = (unsigned long)&at91sam9g45es_config,
+ }, {
+ .name = "at91sam9rl-lcdfb",
+ .driver_data = (unsigned long)&at91sam9rl_config,
+ }, {
+ .name = "at32ap-lcdfb",
+ .driver_data = (unsigned long)&at32ap_config,
+ }, {
+ /* terminator */
+ }
+};
+
+static struct atmel_lcdfb_config *
+atmel_lcdfb_get_config(struct platform_device *pdev)
+{
+ unsigned long data;
+
+ data = platform_get_device_id(pdev)->driver_data;
+
+ return (struct atmel_lcdfb_config *)data;
+}
+
#if defined(CONFIG_ARCH_AT91)
#define ATMEL_LCDFB_FBINFO_DEFAULT (FBINFO_DEFAULT \
| FBINFO_PARTIAL_PAN_OK \
@@ -199,8 +270,7 @@ static unsigned long compute_hozval(struct atmel_lcdfb_info *sinfo,
unsigned long lcdcon2;
unsigned long value;
- if (!(cpu_is_at91sam9261() || cpu_is_at91sam9g10()
- || cpu_is_at32ap7000()))
+ if (!sinfo->config->have_hozval)
return xres;
lcdcon2 = lcdc_readl(sinfo, ATMEL_LCDC_LCDCON2);
@@ -426,7 +496,7 @@ static int atmel_lcdfb_check_var(struct fb_var_screeninfo *var,
break;
case 16:
/* Older SOCs use IBGR:555 rather than BGR:565. */
- if (sinfo->have_intensity_bit)
+ if (sinfo->config->have_intensity_bit)
var->green.length = 5;
else
var->green.length = 6;
@@ -534,7 +604,7 @@ static int atmel_lcdfb_set_par(struct fb_info *info)
/* Now, the LCDC core... */
/* Set pixel clock */
- if (cpu_is_at91sam9g45() && !cpu_is_at91sam9g45es())
+ if (sinfo->config->have_alt_pixclock)
pix_factor = 1;
clk_value_khz = clk_get_rate(sinfo->lcdc_clk) / 1000;
@@ -686,7 +756,7 @@ static int atmel_lcdfb_setcolreg(unsigned int regno, unsigned int red,
case FB_VISUAL_PSEUDOCOLOR:
if (regno < 256) {
- if (sinfo->have_intensity_bit) {
+ if (sinfo->config->have_intensity_bit) {
/* old style I+BGR:555 */
val = ((red >> 11) & 0x001f);
val |= ((green >> 6) & 0x03e0);
@@ -874,10 +944,9 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
}
sinfo->info = info;
sinfo->pdev = pdev;
- if (cpu_is_at91sam9261() || cpu_is_at91sam9263() ||
- cpu_is_at91sam9rl()) {
- sinfo->have_intensity_bit = true;
- }
+ sinfo->config = atmel_lcdfb_get_config(pdev);
+ if (!sinfo->config)
+ goto free_info;
strcpy(info->fix.id, sinfo->pdev->name);
info->flags = ATMEL_LCDFB_FBINFO_DEFAULT;
@@ -1146,7 +1215,7 @@ static struct platform_driver atmel_lcdfb_driver = {
.remove = __exit_p(atmel_lcdfb_remove),
.suspend = atmel_lcdfb_suspend,
.resume = atmel_lcdfb_resume,
-
+ .id_table = atmel_lcdfb_devtypes,
.driver = {
.name = "atmel_lcdfb",
.owner = THIS_MODULE,
diff --git a/include/video/atmel_lcdc.h b/include/video/atmel_lcdc.h
index 8deb226..0f5a2fc 100644
--- a/include/video/atmel_lcdc.h
+++ b/include/video/atmel_lcdc.h
@@ -31,6 +31,7 @@
#define ATMEL_LCDC_WIRING_BGR 0
#define ATMEL_LCDC_WIRING_RGB 1
+struct atmel_lcdfb_config;
/* LCD Controller info data structure, stored in device platform_data */
struct atmel_lcdfb_info {
@@ -61,7 +62,8 @@ struct atmel_lcdfb_info {
void (*atmel_lcdfb_power_control)(int on);
struct fb_monspecs *default_monspecs;
u32 pseudo_palette[16];
- bool have_intensity_bit;
+
+ struct atmel_lcdfb_config *config;
};
#define ATMEL_LCDC_DMABADDR1 0x00
--
1.8.0
^ permalink raw reply related
* [PATCH 4/5] atmel_lcdfb: move lcdcon2 register access to compute_hozval
From: Nicolas Ferre @ 2013-02-08 16:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1360340791.git.nicolas.ferre@atmel.com>
From: Johan Hovold <jhovold@gmail.com>
Pass atmel_lcd_info structure to compute_hozval and only do the register
access on SOCs that actually use it.
This will also simplify the removal of the cpu_is macros.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
drivers/video/atmel_lcdfb.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index c5883ca..2effd35 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -193,14 +193,17 @@ static struct fb_fix_screeninfo atmel_lcdfb_fix __initdata = {
.accel = FB_ACCEL_NONE,
};
-static unsigned long compute_hozval(unsigned long xres, unsigned long lcdcon2)
+static unsigned long compute_hozval(struct atmel_lcdfb_info *sinfo,
+ unsigned long xres)
{
+ unsigned long lcdcon2;
unsigned long value;
if (!(cpu_is_at91sam9261() || cpu_is_at91sam9g10()
|| cpu_is_at32ap7000()))
return xres;
+ lcdcon2 = lcdc_readl(sinfo, ATMEL_LCDC_LCDCON2);
value = xres;
if ((lcdcon2 & ATMEL_LCDC_DISTYPE) != ATMEL_LCDC_DISTYPE_TFT) {
/* STN display */
@@ -591,8 +594,7 @@ static int atmel_lcdfb_set_par(struct fb_info *info)
lcdc_writel(sinfo, ATMEL_LCDC_TIM2, value);
/* Horizontal value (aka line size) */
- hozval_linesz = compute_hozval(info->var.xres,
- lcdc_readl(sinfo, ATMEL_LCDC_LCDCON2));
+ hozval_linesz = compute_hozval(sinfo, info->var.xres);
/* Display size */
value = (hozval_linesz - 1) << ATMEL_LCDC_HOZVAL_OFFSET;
--
1.8.0
^ permalink raw reply related
* [PATCH 3/5] ARM: at91/avr32/atmel_lcdfb: add bus-clock entry
From: Nicolas Ferre @ 2013-02-08 16:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1360340791.git.nicolas.ferre@atmel.com>
From: Johan Hovold <jhovold@gmail.com>
Add hclk entry for the atmel_lcdfb bus clock.
On at91sam9261, at91sam9g10 and at32ap the bus clock has to be enabled
as well as the peripheral clock. Add the appropriate lookup entries to
these SOCs and fake clocks to the SOCs that do not use it.
This allows us to get rid of the conditional enabling of the clocks in
the driver which relied on the cpu_is macros.
Tested on at91sam9263 and at91sam9g45, compile-tested for other
AT91-SOCs, and untested for AVR32.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/mach-at91/at91sam9261.c | 1 +
arch/arm/mach-at91/at91sam9263.c | 1 +
arch/arm/mach-at91/at91sam9g45.c | 1 +
arch/arm/mach-at91/at91sam9rl.c | 1 +
arch/avr32/mach-at32ap/at32ap700x.c | 4 ++--
drivers/video/atmel_lcdfb.c | 23 ++++++++---------------
6 files changed, 14 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-at91/at91sam9261.c b/arch/arm/mach-at91/at91sam9261.c
index 2998a08..5838f12 100644
--- a/arch/arm/mach-at91/at91sam9261.c
+++ b/arch/arm/mach-at91/at91sam9261.c
@@ -169,6 +169,7 @@ static struct clk *periph_clocks[] __initdata = {
};
static struct clk_lookup periph_clocks_lookups[] = {
+ CLKDEV_CON_DEV_ID("hclk", "atmel_lcdfb.0", &hck1),
CLKDEV_CON_DEV_ID("spi_clk", "atmel_spi.0", &spi0_clk),
CLKDEV_CON_DEV_ID("spi_clk", "atmel_spi.1", &spi1_clk),
CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.0", &tc0_clk),
diff --git a/arch/arm/mach-at91/at91sam9263.c b/arch/arm/mach-at91/at91sam9263.c
index b9fc60d..520a63d 100644
--- a/arch/arm/mach-at91/at91sam9263.c
+++ b/arch/arm/mach-at91/at91sam9263.c
@@ -190,6 +190,7 @@ static struct clk_lookup periph_clocks_lookups[] = {
CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk),
CLKDEV_CON_DEV_ID("pclk", "fff98000.ssc", &ssc0_clk),
CLKDEV_CON_DEV_ID("pclk", "fff9c000.ssc", &ssc1_clk),
+ CLKDEV_CON_DEV_ID("hclk", "atmel_lcdfb.0", &lcdc_clk),
CLKDEV_CON_DEV_ID("mci_clk", "atmel_mci.0", &mmc0_clk),
CLKDEV_CON_DEV_ID("mci_clk", "atmel_mci.1", &mmc1_clk),
CLKDEV_CON_DEV_ID("spi_clk", "atmel_spi.0", &spi0_clk),
diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c
index d3addee..ea6b62b 100644
--- a/arch/arm/mach-at91/at91sam9g45.c
+++ b/arch/arm/mach-at91/at91sam9g45.c
@@ -228,6 +228,7 @@ static struct clk_lookup periph_clocks_lookups[] = {
CLKDEV_CON_ID("hclk", &macb_clk),
/* One additional fake clock for ohci */
CLKDEV_CON_ID("ohci_clk", &uhphs_clk),
+ CLKDEV_CON_DEV_ID("hclk", "atmel_lcdfb.0", &lcdc_clk),
CLKDEV_CON_DEV_ID("ehci_clk", "atmel-ehci", &uhphs_clk),
CLKDEV_CON_DEV_ID("hclk", "atmel_usba_udc", &utmi_clk),
CLKDEV_CON_DEV_ID("pclk", "atmel_usba_udc", &udphs_clk),
diff --git a/arch/arm/mach-at91/at91sam9rl.c b/arch/arm/mach-at91/at91sam9rl.c
index eb98704..4cd4fa9 100644
--- a/arch/arm/mach-at91/at91sam9rl.c
+++ b/arch/arm/mach-at91/at91sam9rl.c
@@ -179,6 +179,7 @@ static struct clk *periph_clocks[] __initdata = {
};
static struct clk_lookup periph_clocks_lookups[] = {
+ CLKDEV_CON_DEV_ID("hclk", "atmel_lcdfb.0", &lcdc_clk),
CLKDEV_CON_DEV_ID("hclk", "atmel_usba_udc", &utmi_clk),
CLKDEV_CON_DEV_ID("pclk", "atmel_usba_udc", &udphs_clk),
CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.0", &tc0_clk),
diff --git a/arch/avr32/mach-at32ap/at32ap700x.c b/arch/avr32/mach-at32ap/at32ap700x.c
index b323d8d..cd25b01 100644
--- a/arch/avr32/mach-at32ap/at32ap700x.c
+++ b/arch/avr32/mach-at32ap/at32ap700x.c
@@ -1453,7 +1453,7 @@ static struct resource atmel_lcdfb0_resource[] = {
},
};
DEFINE_DEV_DATA(atmel_lcdfb, 0);
-DEV_CLK(hck1, atmel_lcdfb0, hsb, 7);
+DEV_CLK(hclk, atmel_lcdfb0, hsb, 7);
static struct clk atmel_lcdfb0_pixclk = {
.name = "lcdc_clk",
.dev = &atmel_lcdfb0_device.dev,
@@ -2246,7 +2246,7 @@ static __initdata struct clk *init_clocks[] = {
&atmel_twi0_pclk,
&atmel_mci0_pclk,
#if defined(CONFIG_CPU_AT32AP7000) || defined(CONFIG_CPU_AT32AP7002)
- &atmel_lcdfb0_hck1,
+ &atmel_lcdfb0_hclk,
&atmel_lcdfb0_pixclk,
#endif
&ssc0_pclk,
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index 025428e..c5883ca 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -821,15 +821,13 @@ static int __init atmel_lcdfb_init_fbinfo(struct atmel_lcdfb_info *sinfo)
static void atmel_lcdfb_start_clock(struct atmel_lcdfb_info *sinfo)
{
- if (sinfo->bus_clk)
- clk_enable(sinfo->bus_clk);
+ clk_enable(sinfo->bus_clk);
clk_enable(sinfo->lcdc_clk);
}
static void atmel_lcdfb_stop_clock(struct atmel_lcdfb_info *sinfo)
{
- if (sinfo->bus_clk)
- clk_disable(sinfo->bus_clk);
+ clk_disable(sinfo->bus_clk);
clk_disable(sinfo->lcdc_clk);
}
@@ -888,13 +886,10 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
info->fix = atmel_lcdfb_fix;
/* Enable LCDC Clocks */
- if (cpu_is_at91sam9261() || cpu_is_at91sam9g10()
- || cpu_is_at32ap7000()) {
- sinfo->bus_clk = clk_get(dev, "hck1");
- if (IS_ERR(sinfo->bus_clk)) {
- ret = PTR_ERR(sinfo->bus_clk);
- goto free_info;
- }
+ sinfo->bus_clk = clk_get(dev, "hclk");
+ if (IS_ERR(sinfo->bus_clk)) {
+ ret = PTR_ERR(sinfo->bus_clk);
+ goto free_info;
}
sinfo->lcdc_clk = clk_get(dev, "lcdc_clk");
if (IS_ERR(sinfo->lcdc_clk)) {
@@ -1055,8 +1050,7 @@ stop_clk:
atmel_lcdfb_stop_clock(sinfo);
clk_put(sinfo->lcdc_clk);
put_bus_clk:
- if (sinfo->bus_clk)
- clk_put(sinfo->bus_clk);
+ clk_put(sinfo->bus_clk);
free_info:
framebuffer_release(info);
out:
@@ -1081,8 +1075,7 @@ static int __exit atmel_lcdfb_remove(struct platform_device *pdev)
unregister_framebuffer(info);
atmel_lcdfb_stop_clock(sinfo);
clk_put(sinfo->lcdc_clk);
- if (sinfo->bus_clk)
- clk_put(sinfo->bus_clk);
+ clk_put(sinfo->bus_clk);
fb_dealloc_cmap(&info->cmap);
free_irq(sinfo->irq_base, info);
iounmap(sinfo->mmio);
--
1.8.0
^ permalink raw reply related
* [PATCH 2/5] ARM: at91/neocore926: fix LCD-wiring mode
From: Nicolas Ferre @ 2013-02-08 16:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1360340791.git.nicolas.ferre@atmel.com>
From: Johan Hovold <jhovold@gmail.com>
Fix regression introduced by commit 787f9fd23283 ("atmel_lcdfb: support
16bit BGR:565 mode, remove unsupported 15bit modes") which broke 16-bpp
modes for older SOCs which use IBGR:555 (msb is intensity) rather than
BGR:565.
The above commit also removed the RGB:555-wiring hack without fixing the
neocore926 board which used it. Fix by specifying RGB-wiring and let the
driver handle the final SOC-dependant layout.
Remove the no longer used ATMEL_LCDC_WIRING_RGB555 define.
Compile-only tested.
Cc: <stable@vger.kernel.org>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/mach-at91/board-neocore926.c | 2 +-
include/video/atmel_lcdc.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/mach-at91/board-neocore926.c b/arch/arm/mach-at91/board-neocore926.c
index bc7a1c4..4726297 100644
--- a/arch/arm/mach-at91/board-neocore926.c
+++ b/arch/arm/mach-at91/board-neocore926.c
@@ -266,7 +266,7 @@ static struct atmel_lcdfb_info __initdata neocore926_lcdc_data = {
.default_monspecs = &at91fb_default_monspecs,
.atmel_lcdfb_power_control = at91_lcdc_power_control,
.guard_time = 1,
- .lcd_wiring_mode = ATMEL_LCDC_WIRING_RGB555,
+ .lcd_wiring_mode = ATMEL_LCDC_WIRING_RGB,
};
#else
diff --git a/include/video/atmel_lcdc.h b/include/video/atmel_lcdc.h
index 5f0e234..8deb226 100644
--- a/include/video/atmel_lcdc.h
+++ b/include/video/atmel_lcdc.h
@@ -30,7 +30,6 @@
*/
#define ATMEL_LCDC_WIRING_BGR 0
#define ATMEL_LCDC_WIRING_RGB 1
-#define ATMEL_LCDC_WIRING_RGB555 2
/* LCD Controller info data structure, stored in device platform_data */
--
1.8.0
^ permalink raw reply related
* [PATCH 1/5] atmel_lcdfb: fix 16-bpp modes on older SOCs
From: Nicolas Ferre @ 2013-02-08 16:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1360340791.git.nicolas.ferre@atmel.com>
From: Johan Hovold <jhovold@gmail.com>
Fix regression introduced by commit 787f9fd23283 ("atmel_lcdfb: support
16bit BGR:565 mode, remove unsupported 15bit modes") which broke 16-bpp
modes for older SOCs which use IBGR:555 (msb is intensity) rather
than BGR:565.
Use SOC-type to determine the pixel layout.
Tested on at91sam9263 and at91sam9g45.
Cc: <stable@vger.kernel.org>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
drivers/video/atmel_lcdfb.c | 22 +++++++++++++++-------
include/video/atmel_lcdc.h | 1 +
2 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index 12cf5f3..025428e 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -422,17 +422,22 @@ static int atmel_lcdfb_check_var(struct fb_var_screeninfo *var,
= var->bits_per_pixel;
break;
case 16:
+ /* Older SOCs use IBGR:555 rather than BGR:565. */
+ if (sinfo->have_intensity_bit)
+ var->green.length = 5;
+ else
+ var->green.length = 6;
+
if (sinfo->lcd_wiring_mode = ATMEL_LCDC_WIRING_RGB) {
- /* RGB:565 mode */
- var->red.offset = 11;
+ /* RGB:5X5 mode */
+ var->red.offset = var->green.length + 5;
var->blue.offset = 0;
} else {
- /* BGR:565 mode */
+ /* BGR:5X5 mode */
var->red.offset = 0;
- var->blue.offset = 11;
+ var->blue.offset = var->green.length + 5;
}
var->green.offset = 5;
- var->green.length = 6;
var->red.length = var->blue.length = 5;
break;
case 32:
@@ -679,8 +684,7 @@ static int atmel_lcdfb_setcolreg(unsigned int regno, unsigned int red,
case FB_VISUAL_PSEUDOCOLOR:
if (regno < 256) {
- if (cpu_is_at91sam9261() || cpu_is_at91sam9263()
- || cpu_is_at91sam9rl()) {
+ if (sinfo->have_intensity_bit) {
/* old style I+BGR:555 */
val = ((red >> 11) & 0x001f);
val |= ((green >> 6) & 0x03e0);
@@ -870,6 +874,10 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
}
sinfo->info = info;
sinfo->pdev = pdev;
+ if (cpu_is_at91sam9261() || cpu_is_at91sam9263() ||
+ cpu_is_at91sam9rl()) {
+ sinfo->have_intensity_bit = true;
+ }
strcpy(info->fix.id, sinfo->pdev->name);
info->flags = ATMEL_LCDFB_FBINFO_DEFAULT;
diff --git a/include/video/atmel_lcdc.h b/include/video/atmel_lcdc.h
index 28447f1..5f0e234 100644
--- a/include/video/atmel_lcdc.h
+++ b/include/video/atmel_lcdc.h
@@ -62,6 +62,7 @@ struct atmel_lcdfb_info {
void (*atmel_lcdfb_power_control)(int on);
struct fb_monspecs *default_monspecs;
u32 pseudo_palette[16];
+ bool have_intensity_bit;
};
#define ATMEL_LCDC_DMABADDR1 0x00
--
1.8.0
^ permalink raw reply related
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