From: "Raphaël Assénat" <raph@8d.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org,
Chandrabhanu Mahapatra <cmahapatra@ti.com>
Subject: Re: [PATCH] OMAPDSS: Do not require a VDDS_DSI regulator on am35xx
Date: Tue, 31 Jul 2012 20:46:33 +0000 [thread overview]
Message-ID: <50184429.4030103@8d.com> (raw)
In-Reply-To: <1343724323.2633.22.camel@deskari>
On 31/07/12 04:45 AM, Tomi Valkeinen wrote:
> On Thu, 2012-07-19 at 16:04 -0400, Raphael Assenat wrote:
>> On our AM3505 based board, dpi.c complains that there is no VDSS_DSI regulator
>> and the framebuffer cannot be enabled. However, this check does not seem to
>> apply to AM3505/17 chips.
>>
>> I am not the first facing this issue, see this thread from Nov. 2011:
>> http://marc.info/?l=linux-omap&m\x132147745930213&w=2
>>
>> The string 'vdds_dsi' does appear once in the technical reference manual[1]
>> but there is no corresponding power pin on the package[2]. I failed to
>> locate any signal that could be an equivalent. I am trying to obtain some
>> clarifications on TI's forum[3]...
>>
>> In any case, I am currently running with the patch below. In order to keep
>> cpu_is_xx uses to a minimum, I check for am35xx once at init time and allow
>> dpi.vdds_dsi_reg to be NULL from then on, getting rid of all the other
>> cpu_is_omap34xx uses in the process.
>>
>> Your comments would be appreciated. Please also consider for merging.
>
> VDDS_DSI is used to power up some of the DSS pins on OMAP3. I don't know
> why the HW was designed like that... If you have a correct image without
> the power, then obviously it's not needed.
Yes, I confirm the image is displayed properly.
> We don't currently deal with AM3xxx SoCs in any way in the driver. It's
> difficult enough trying to handle just OMAP DSS versions, and now we
> need to add AM3xxx to the mix. Sigh =).
>
> However, I don't want to apply this patch, as we're trying to remove the
> cpu_is checks (soc_is goes in the same category).
>
> I guess we need to add entries for the AM3xxx SoCs in the
> dss_features.c.
>
> Any idea what other differences AM3xxx has compared to OMAP3?
This is the only one I am aware of.
Best regards,
Raphaël Assénat
WARNING: multiple messages have this Message-ID (diff)
From: "Raphaël Assénat" <raph@8d.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org,
Chandrabhanu Mahapatra <cmahapatra@ti.com>
Subject: Re: [PATCH] OMAPDSS: Do not require a VDDS_DSI regulator on am35xx
Date: Tue, 31 Jul 2012 16:46:33 -0400 [thread overview]
Message-ID: <50184429.4030103@8d.com> (raw)
In-Reply-To: <1343724323.2633.22.camel@deskari>
On 31/07/12 04:45 AM, Tomi Valkeinen wrote:
> On Thu, 2012-07-19 at 16:04 -0400, Raphael Assenat wrote:
>> On our AM3505 based board, dpi.c complains that there is no VDSS_DSI regulator
>> and the framebuffer cannot be enabled. However, this check does not seem to
>> apply to AM3505/17 chips.
>>
>> I am not the first facing this issue, see this thread from Nov. 2011:
>> http://marc.info/?l=linux-omap&m=132147745930213&w=2
>>
>> The string 'vdds_dsi' does appear once in the technical reference manual[1]
>> but there is no corresponding power pin on the package[2]. I failed to
>> locate any signal that could be an equivalent. I am trying to obtain some
>> clarifications on TI's forum[3]...
>>
>> In any case, I am currently running with the patch below. In order to keep
>> cpu_is_xx uses to a minimum, I check for am35xx once at init time and allow
>> dpi.vdds_dsi_reg to be NULL from then on, getting rid of all the other
>> cpu_is_omap34xx uses in the process.
>>
>> Your comments would be appreciated. Please also consider for merging.
>
> VDDS_DSI is used to power up some of the DSS pins on OMAP3. I don't know
> why the HW was designed like that... If you have a correct image without
> the power, then obviously it's not needed.
Yes, I confirm the image is displayed properly.
> We don't currently deal with AM3xxx SoCs in any way in the driver. It's
> difficult enough trying to handle just OMAP DSS versions, and now we
> need to add AM3xxx to the mix. Sigh =).
>
> However, I don't want to apply this patch, as we're trying to remove the
> cpu_is checks (soc_is goes in the same category).
>
> I guess we need to add entries for the AM3xxx SoCs in the
> dss_features.c.
>
> Any idea what other differences AM3xxx has compared to OMAP3?
This is the only one I am aware of.
Best regards,
Raphaël Assénat
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2012-07-31 20:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-19 20:04 [PATCH] OMAPDSS: Do not require a VDDS_DSI regulator on am35xx Raphael Assenat
2012-07-19 20:04 ` Raphael Assenat
2012-07-31 8:45 ` Tomi Valkeinen
2012-07-31 8:45 ` Tomi Valkeinen
2012-07-31 20:46 ` Raphaël Assénat [this message]
2012-07-31 20:46 ` Raphaël Assénat
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50184429.4030103@8d.com \
--to=raph@8d.com \
--cc=cmahapatra@ti.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=tomi.valkeinen@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.