From: Valentine <valentine.barshak@cogentembedded.com>
To: linux-sh@vger.kernel.org
Subject: Re: [PATCH] pinctrl: sh-pfc: pfc-r8a7790: Add full VIN1/2/3 support
Date: Mon, 09 Dec 2013 19:14:29 +0000 [thread overview]
Message-ID: <52A61695.8060209@cogentembedded.com> (raw)
In-Reply-To: <1382040403-19649-1-git-send-email-valentine.barshak@cogentembedded.com>
On 10/29/2013 10:10 PM, Laurent Pinchart wrote:
> Hi Valentine,
Hi Laurent,
sorry for delay.
>
> Thanks you for the patch.
>
> On Friday 18 October 2013 00:06:43 Valentine Barshak wrote:
>> This adds missing VIN1/2/3 pin configuration to pfc-r8a7790.
>>
>> Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com>
>> ---
>> drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 202 +++++++++++++++++++++++++++++++-
>> 1 file changed, 198 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
>> b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c index 64fcc006..9ab2f71 100644
>> --- a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
>> +++ b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
>> @@ -2996,22 +2996,168 @@ static const unsigned int vin0_clk_mux[] = {
>> VI0_CLK_MARK,
>> };
>> /* - VIN1 -------------------------------------------------------------- */
>> -static const unsigned int vin1_data_pins[] = {
>> +static const unsigned int vin1_data_g_pins[] = {
>> + RCAR_GP_PIN(1, 14), RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 17),
>> + RCAR_GP_PIN(1, 20), RCAR_GP_PIN(1, 22), RCAR_GP_PIN(1, 12),
>> + RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 7),
>> +};
>> +static const unsigned int vin1_data_g_mux[] = {
>> + VI1_G0_MARK, VI1_G1_MARK, VI1_G2_MARK,
>> + VI1_G3_MARK, VI1_G4_MARK, VI1_G5_MARK,
>> + VI1_G6_MARK, VI1_G7_MARK,
>> +};
>> +static const unsigned int vin1_data_r_pins[] = {
>> + RCAR_GP_PIN(0, 27), RCAR_GP_PIN(0, 28), RCAR_GP_PIN(0, 29),
>> + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5), RCAR_GP_PIN(1, 6),
>> + RCAR_GP_PIN(1, 10), RCAR_GP_PIN(1, 8),
>> +};
>> +static const unsigned int vin1_data_r_mux[] = {
>> + VI1_R0_MARK, VI1_R1_MARK, VI1_R2_MARK,
>> + VI1_R3_MARK, VI1_R4_MARK, VI1_R5_MARK,
>> + VI1_R6_MARK, VI1_R7_MARK,
>> +};
>> +static const unsigned int vin1_data_b_pins[] = {
>> RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11), RCAR_GP_PIN(2, 12),
>> RCAR_GP_PIN(2, 13), RCAR_GP_PIN(2, 14), RCAR_GP_PIN(2, 15),
>> RCAR_GP_PIN(2, 16), RCAR_GP_PIN(2, 17),
>> };
>> -static const unsigned int vin1_data_mux[] = {
>> +static const unsigned int vin1_data_b_mux[] = {
>> VI1_DATA0_VI1_B0_MARK, VI1_DATA1_VI1_B1_MARK, VI1_DATA2_VI1_B2_MARK,
>> VI1_DATA3_VI1_B3_MARK, VI1_DATA4_VI1_B4_MARK, VI1_DATA5_VI1_B5_MARK,
>> VI1_DATA6_VI1_B6_MARK, VI1_DATA7_VI1_B7_MARK,
>> };
>
> Given the wide variety of ways the VIN data pins can be used, I see two ways
> to group them:
>
> - List all possible combinations of data pins with a single group per
> configuration. There are 11 combinations, but due to overlap in the pins used
> the number can be reduced to 8.
>
> - List groups individually and combine them to create a valid configuration.
> We would have at least 8 groups in this case as well.
>
> Given that the number of groups would be identical, my preference would go for
> the first solution. The RGB data pin group would contain all 24 RGB pins in
> that case, and additional overlapping groups would be defined for other input
> configurations. Would you be fine with that ? VIN1 would be handled
> identically, and VIN2 would need 5 groups only. VIN3 is already defined
> correctly, as it supports a single configuration only.
I'm only adding missing stuff here. VIN0/VIN1 are identical so I'm adding VIN1
the same way VIN0 is currently grouped.
I'm generally fine with re-grouping data pins, but I think it should be a separate change.
We'd also need to choose simple names for the groups which are easily readable and show
which pins are used there. Something like:
data_r07g07b07 (24 bits for RGB24)
data_r27g27b27 (pins 2-7 for ITU-R BT.601/BT.709 RGB-666)
>
>> +static const unsigned int vin1_hsync_signal_pins[] = {
>
> I think you can drop _signal here and below.
I didn't intend to edit the existing naming. All I wanted to do is add the definitions
for the missing pins here. I think name editing should be done by a separate patch if needed.
IMHO, otherwise it would be a mess.
>
>> + RCAR_GP_PIN(1, 24),
>> +};
>> +static const unsigned int vin1_hsync_signal_mux[] = {
>> + VI1_HSYNC_N_MARK,
>> +};
>> +static const unsigned int vin1_vsync_signal_pins[] = {
>> + RCAR_GP_PIN(1, 25),
>> +};
>> +static const unsigned int vin1_vsync_signal_mux[] = {
>> + VI1_VSYNC_N_MARK,
>> +};
>
> If I'm not mistaken the hsync and vsync signals can't be used independently,
> so they should be grouped together.
I'm just using the current VIN0 layout for VIN1 here.
I'm not intending to regroup anything here. The purpose of these
changes is to add missing pins. I believe regrouping should be done
by a separate patch if needed.
[snip]
Thanks,
Val.
next prev parent reply other threads:[~2013-12-09 19:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-17 20:06 [PATCH] pinctrl: sh-pfc: pfc-r8a7790: Add full VIN1/2/3 support Valentine Barshak
2013-10-29 5:03 ` Simon Horman
2013-10-29 18:10 ` Laurent Pinchart
2013-12-09 19:14 ` Valentine [this message]
2013-12-10 1:45 ` Laurent Pinchart
2013-12-10 11:45 ` Valentine
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=52A61695.8060209@cogentembedded.com \
--to=valentine.barshak@cogentembedded.com \
--cc=linux-sh@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).