All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org
Subject: Re: [PATCH 4/5] ARM: DT: tegra114: add KBC controller DT entry
Date: Fri, 08 Mar 2013 11:04:00 -0700	[thread overview]
Message-ID: <513A2810.1070903@wwwdotorg.org> (raw)
In-Reply-To: <1362750782-15174-5-git-send-email-ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

On 03/08/2013 06:53 AM, Laxman Dewangan wrote:
> NVIDIA's Tegra114 SoCs have the matrix keyboard controller which
> supports 11x8 type of matrix. The number of rows and columns
> are configurable.

Earlier Tegra versions supported up to a 16x8 matrix. This feeds into
the following defines in the driver:

#define KBC_MAX_GPIO    24
#define KBC_MAX_ROW     16
#define KBC_MAX_COL     8
#define KBC_MAX_KEY     (KBC_MAX_ROW * KBC_MAX_COL)

Given Tegra114 supports /fewer/ pins and rows than earlier chips, I
think that makes the HW technically incompatible, since GPIO IDs 19..23
are invalid in this HW but valid earlier.

Now in practice I suppose that with a correct DT keyboard map for a
Tegra114 device, those extra invalid GPIOs would never be referenced, so
this is a little nit-picky, but I still feel we should fix this.

So, I'd like to see the KBC driver updated to derive the values for all
the defines I listed above from the compatible value.

Technically, tegra114.dtsi should not pretend that the Tegra114 KBC is
compatible with previous generations either.

> diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi

> +	kbc {
> +		compatible = "nvidia,tegra20-kbc";

Ignoring any of the discussion above, i.e. even if the HW was 100%
identical, we should still include a Tegra114 entry in the compatible
property (compatible = "nvidia,tegra114-kbc", "nvidia,tegra20-kbc"), so
that if Tegra114-specific bugs were found in the future, any device
trees would already indicate that they describe Tegra114 HW, so the SW
could key off that to enable the workaround.

Re-stated: The rules for compatible are: Always include the exact HW
name, then optionally include any other HW names it's compatible with.

WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/5] ARM: DT: tegra114: add KBC controller DT entry
Date: Fri, 08 Mar 2013 11:04:00 -0700	[thread overview]
Message-ID: <513A2810.1070903@wwwdotorg.org> (raw)
In-Reply-To: <1362750782-15174-5-git-send-email-ldewangan@nvidia.com>

On 03/08/2013 06:53 AM, Laxman Dewangan wrote:
> NVIDIA's Tegra114 SoCs have the matrix keyboard controller which
> supports 11x8 type of matrix. The number of rows and columns
> are configurable.

Earlier Tegra versions supported up to a 16x8 matrix. This feeds into
the following defines in the driver:

#define KBC_MAX_GPIO    24
#define KBC_MAX_ROW     16
#define KBC_MAX_COL     8
#define KBC_MAX_KEY     (KBC_MAX_ROW * KBC_MAX_COL)

Given Tegra114 supports /fewer/ pins and rows than earlier chips, I
think that makes the HW technically incompatible, since GPIO IDs 19..23
are invalid in this HW but valid earlier.

Now in practice I suppose that with a correct DT keyboard map for a
Tegra114 device, those extra invalid GPIOs would never be referenced, so
this is a little nit-picky, but I still feel we should fix this.

So, I'd like to see the KBC driver updated to derive the values for all
the defines I listed above from the compatible value.

Technically, tegra114.dtsi should not pretend that the Tegra114 KBC is
compatible with previous generations either.

> diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi

> +	kbc {
> +		compatible = "nvidia,tegra20-kbc";

Ignoring any of the discussion above, i.e. even if the HW was 100%
identical, we should still include a Tegra114 entry in the compatible
property (compatible = "nvidia,tegra114-kbc", "nvidia,tegra20-kbc"), so
that if Tegra114-specific bugs were found in the future, any device
trees would already indicate that they describe Tegra114 HW, so the SW
could key off that to enable the workaround.

Re-stated: The rules for compatible are: Always include the exact HW
name, then optionally include any other HW names it's compatible with.

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren@wwwdotorg.org>
To: Laxman Dewangan <ldewangan@nvidia.com>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
	pdeschrijver@nvidia.com
Subject: Re: [PATCH 4/5] ARM: DT: tegra114: add KBC controller DT entry
Date: Fri, 08 Mar 2013 11:04:00 -0700	[thread overview]
Message-ID: <513A2810.1070903@wwwdotorg.org> (raw)
In-Reply-To: <1362750782-15174-5-git-send-email-ldewangan@nvidia.com>

On 03/08/2013 06:53 AM, Laxman Dewangan wrote:
> NVIDIA's Tegra114 SoCs have the matrix keyboard controller which
> supports 11x8 type of matrix. The number of rows and columns
> are configurable.

Earlier Tegra versions supported up to a 16x8 matrix. This feeds into
the following defines in the driver:

#define KBC_MAX_GPIO    24
#define KBC_MAX_ROW     16
#define KBC_MAX_COL     8
#define KBC_MAX_KEY     (KBC_MAX_ROW * KBC_MAX_COL)

Given Tegra114 supports /fewer/ pins and rows than earlier chips, I
think that makes the HW technically incompatible, since GPIO IDs 19..23
are invalid in this HW but valid earlier.

Now in practice I suppose that with a correct DT keyboard map for a
Tegra114 device, those extra invalid GPIOs would never be referenced, so
this is a little nit-picky, but I still feel we should fix this.

So, I'd like to see the KBC driver updated to derive the values for all
the defines I listed above from the compatible value.

Technically, tegra114.dtsi should not pretend that the Tegra114 KBC is
compatible with previous generations either.

> diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi

> +	kbc {
> +		compatible = "nvidia,tegra20-kbc";

Ignoring any of the discussion above, i.e. even if the HW was 100%
identical, we should still include a Tegra114 entry in the compatible
property (compatible = "nvidia,tegra114-kbc", "nvidia,tegra20-kbc"), so
that if Tegra114-specific bugs were found in the future, any device
trees would already indicate that they describe Tegra114 HW, so the SW
could key off that to enable the workaround.

Re-stated: The rules for compatible are: Always include the exact HW
name, then optionally include any other HW names it's compatible with.


  parent reply	other threads:[~2013-03-08 18:04 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-08 13:52 [PATCH 0/5] ARM: DT: tegra114: Add DT entry for different controller Laxman Dewangan
2013-03-08 13:52 ` Laxman Dewangan
2013-03-08 13:52 ` Laxman Dewangan
2013-03-08 13:52 ` [PATCH 1/5] ARM: DT: tegra114: add APB DMA controller DT entry Laxman Dewangan
2013-03-08 13:52   ` Laxman Dewangan
2013-03-08 13:52   ` Laxman Dewangan
     [not found]   ` <1362750782-15174-2-git-send-email-ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-03-08 17:51     ` Stephen Warren
2013-03-08 17:51       ` Stephen Warren
2013-03-08 17:51       ` Stephen Warren
2013-03-08 18:06       ` Laxman Dewangan
2013-03-08 18:06         ` Laxman Dewangan
     [not found]         ` <513A2888.5020402-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-03-08 18:41           ` Stephen Warren
2013-03-08 18:41             ` Stephen Warren
2013-03-08 18:41             ` Stephen Warren
     [not found]             ` <513A30D3.4020700-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-03-08 18:46               ` Laxman Dewangan
2013-03-08 18:46                 ` Laxman Dewangan
2013-03-08 18:46                 ` Laxman Dewangan
2013-03-08 13:52 ` [PATCH 2/5] ARM: DT: tegra114: Add i2c " Laxman Dewangan
2013-03-08 13:52   ` Laxman Dewangan
2013-03-08 13:52   ` Laxman Dewangan
2013-03-08 13:53 ` [PATCH 3/5] ARM: DT: tegra114:add aliases and DMA requestor for serial controller Laxman Dewangan
2013-03-08 13:53   ` Laxman Dewangan
2013-03-08 13:53   ` Laxman Dewangan
     [not found]   ` <1362750782-15174-4-git-send-email-ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-03-08 17:54     ` Stephen Warren
2013-03-08 17:54       ` Stephen Warren
2013-03-08 17:54       ` Stephen Warren
     [not found]       ` <513A25E4.8040504-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-03-08 18:04         ` Laxman Dewangan
2013-03-08 18:04           ` Laxman Dewangan
2013-03-08 18:04           ` Laxman Dewangan
     [not found]           ` <513A281B.9010702-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-03-08 18:40             ` Stephen Warren
2013-03-08 18:40               ` Stephen Warren
2013-03-08 18:40               ` Stephen Warren
     [not found] ` <1362750782-15174-1-git-send-email-ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-03-08 13:53   ` [PATCH 4/5] ARM: DT: tegra114: add KBC controller DT entry Laxman Dewangan
2013-03-08 13:53     ` Laxman Dewangan
2013-03-08 13:53     ` Laxman Dewangan
     [not found]     ` <1362750782-15174-5-git-send-email-ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-03-08 18:04       ` Stephen Warren [this message]
2013-03-08 18:04         ` Stephen Warren
2013-03-08 18:04         ` Stephen Warren
2013-03-08 18:14         ` Laxman Dewangan
2013-03-08 18:14           ` Laxman Dewangan
     [not found]           ` <513A2A6D.7080604-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-03-08 18:42             ` Stephen Warren
2013-03-08 18:42               ` Stephen Warren
2013-03-08 18:42               ` Stephen Warren
2013-03-08 13:53 ` [PATCH 5/5] ARM: DT: tegra114: Add spi " Laxman Dewangan
2013-03-08 13:53   ` Laxman Dewangan
2013-03-08 13:53   ` Laxman Dewangan

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=513A2810.1070903@wwwdotorg.org \
    --to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \
    --cc=ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.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 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.