Re: [Intel-gfx] [PATCH v2 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.
EC_MKBP_EVENT_SYSRQ = 6,
>
> + /* Notify the AP that something happened on CEC */
> + EC_MKBP_CEC_EVENT = 8,
> +
> + /* Send an incoming CEC message to the AP */
> + EC_MKBP_EVENT_CEC_MESSAGE = 9,
> +
> /* Number of MKBP events */
> EC_MKBP_EVENT_COUNT,
> };
> @@ -2093,12 +2101,31 @@ union ec_response_get_next_data {
> uint32_t sysrq;
> } __packed;
>
> +union ec_response_get_next_data_v1 {
> + uint8_t key_matrix[16];
> +
> + /* Unaligned */
> + uint32_t host_event;
> +
> + uint32_t buttons;
> + uint32_t switches;
> + uint32_t sysrq;
> + uint32_t cec_events;
> + uint8_tcec_message[16];
> +} __packed;
> +
> struct ec_response_get_next_event {
> uint8_t event_type;
> /* Followed by event data if any */
> union ec_response_get_next_data data;
> } __packed;
>
> +struct ec_response_get_next_event_v1 {
> + uint8_t event_type;
> + /* Followed by event data if any */
> + union ec_response_get_next_data_v1 data;
> +} __packed;
> +
> /* Bit indices for buttons and switches.*/
> /* Buttons */
> #define EC_MKBP_POWER_BUTTON 0
> @@ -2828,6 +2855,59 @@ struct ec_params_reboot_ec {
> /* Current version of ACPI memory address space */
> #define EC_ACPI_MEM_VERSION_CURRENT 1
>
> +/*/
> +/*
> + * HDMI CEC commands
> + *
> + * These commands are for sending and receiving message via HDMI CEC
> + */
> +#define MAX_CEC_MSG_LEN 16
> +
> +/* CEC message from the AP to be written on the CEC bus */
> +#define EC_CMD_CEC_WRITE_MSG 0x00B8
> +
> +/* Message to write to the CEC bus */
> +struct ec_params_cec_write {
> + uint8_t msg[MAX_CEC_MSG_LEN];
> +} __packed;
> +
> +/* Set various CEC parameters */
> +#define EC_CMD_CEC_SET 0x00BA
> +
> +struct ec_params_cec_set {
> + uint8_t cmd; /* enum cec_command */
> + union {
> + uint8_t enable;
> + uint8_t address;
> + };
> +} __packed;
> +
> +/* Read various CEC parameters */
> +#define EC_CMD_CEC_GET 0x00BB
> +
> +struct ec_params_cec_get {
> + uint8_t cmd; /* enum cec_command */
> +} __packed;
> +
> +struct ec_response_cec_get {
> + union {
> + uint8_t enable;
> + uint8_t address;
> + };
> +} __packed;
> +
> +enum cec_command {
> + /* CEC reading, writing and events enable */
> + CEC_CMD_ENABLE,
> + /* CEC logical address */
> + CEC_CMD_LOGICAL_ADDRESS,
> +};
> +
> +/* Events from CEC to AP */
> +enum mkbp_cec_event {
> + EC_MKBP_CEC_SEND_OK = 1 << 0,
> + EC_MKBP_CEC_SEND_FAILED = 1 << 1,
> +};
>
>
> /*/
> /*
> --
> 2.7.4
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/dp: Add DP_DPCD_REV_XX to drm_dp_helper
On Fri, May 04, 2018 at 03:17:59PM -0700, matthew.s.atw...@intel.com wrote: > From: Matt Atwood > > As more differentation occurs between DP spec. Its useful to have these > as macros in a drm_dp_helper. > > v2: DPCD_REV_XX to DP_DPCD_REV_XX > > Signed-off-by: Matt Atwood Tested-by: Benson Leung > --- > include/drm/drm_dp_helper.h | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index 91c9bcd4196f..96dcef479ed6 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -64,6 +64,11 @@ > /* AUX CH addresses */ > /* DPCD */ > #define DP_DPCD_REV 0x000 > +# define DP_DPCD_REV_10 0x10 > +# define DP_DPCD_REV_11 0x11 > +# define DP_DPCD_REV_12 0x12 > +# define DP_DPCD_REV_13 0x13 > +# define DP_DPCD_REV_14 0x14 > > #define DP_MAX_LINK_RATE0x001 > > -- > 2.17.0 > -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4
On Thu, Mar 15, 2018 at 02:08:51PM -0700, matthew.s.atw...@intel.com wrote: > From: Matt Atwood > > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8 > bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended > receiver capabilities. For panels that use this new feature wait interval > would be increased by 512 ms, when spec is max 16 ms. This behavior is > described in table 2-158 of DP 1.4 spec address eh. > > With the introduction of DP 1.4 spec main link clock recovery was > standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value. > > To avoid breaking panels that are not spec compiant we now warn on > invalid values. > > V2: commit title/message, masking all 7 bits, warn on out of spec values. > V3: commit message, make link train clock recovery follow DP 1.4 spec. > V4: style changes > V5: typo > V6: print statement revisions, DP_REV to DPCD_REV, comment correction > V7: typo > V8: Style > > Signed-off-by: Matt Atwood Tested-by: Benson Leung This version still passes link training on the panel with 8th bit set in DPCD 0x000e. Thanks, Benson -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: make edp optimize config
Hi Matt, Minor commit message nits. On Thu, Mar 08, 2018 at 05:17:38PM -0800, matthew.s.atw...@intel.com wrote: > From: Matt Atwood > > Previously it was assumed that eDP panels would advertise the lowest link > rate required for their singular mode to function. With the introduction > of more advanced features there are advantages to a panel advertising a > higher rate then s/then/than > it needs for a its given mode. Don't need "its" here. > For panels that did, the > driver previously used a higher rate then necessary for that mode. > s/then/than > Signed-off-by: Matt Atwood Tested-by: Benson Leung Tested this on a panel and system with the following source and sink rates: [1.623225] [drm:intel_dp_print_rates] source rates: 162000, 216000, 27, 324000, 432000, 54 [1.623230] [drm:intel_dp_print_rates] sink rates: 162000, 216000, 243000, 27, 324000, 432000, 54 [1.623234] [drm:intel_dp_print_rates] common rates: 162000, 216000, 27, 324000, 432000, 54 Prior to this patch, the driver would pick and train at 54: [2.865653] [drm:intel_dp_start_link_train] [CONNECTOR:76:eDP-1] Link Training Passed at Link Rate = 54, Lane count = 4 After this patch, the driver picks and trains at 324000, which is enough for the panel's native mode: [5.359499] [drm:intel_dp_start_link_train] [CONNECTOR:76:eDP-1] Link Training Passed at Link Rate = 324000, Lane count = 4 Thanks! Benson -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4
Hi Matt, On Wed, Mar 07, 2018 at 04:28:51PM -0800, matthew.s.atw...@intel.com wrote: > From: Matt Atwood > > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8 > bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended > receiver capabilities. For panels that use this new feature wait interval > would be increased by 512 ms, when spec is max 16 ms. This behavior is > described in table 2-158 of DP 1.4 spec address eh. > > With the introduction of DP 1.4 spec main link clock recovery was > standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value. > > To avoid breaking panels that are not spec compiant we now warn on > invalid values. > > V2: commit title/message, masking all 7 bits, warn on out of spec values. > V3: commit message, make link train clock recovery follow DP 1.4 spec. > V4: style changes > V5: typo > > Signed-off-by: Matt Atwood Tested-by: Benson Leung V5 passes link training on that same panel from before with 8th bit set in DPCD 0x000e. Thanks, Benson -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4
Hey Matt,
Your patch doesn't build. Missing semicolon, dude.
On Wed, Mar 07, 2018 at 04:13:58PM -0800, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood
>
> DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
> bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
> receiver capabilities. For panels that use this new feature wait interval
> would be increased by 512 ms, when spec is max 16 ms. This behavior is
> described in table 2-158 of DP 1.4 spec address eh.
>
> With the introduction of DP 1.4 spec main link clock recovery was
> standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.
>
> To avoid breaking panels that are not spec compiant we now warn on
> invalid values.
>
> V2: commit title/message, masking all 7 bits, warn on out of spec values.
> V3: commit message, make link train clock recovery follow DP 1.4 spec.
> V4: style changes
>
> Signed-off-by: Matt Atwood
> ---
> drivers/gpu/drm/drm_dp_helper.c | 18 ++
> include/drm/drm_dp_helper.h | 6 ++
> 2 files changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index adf79be..6985ff3 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8
> link_status[DP_LINK_STATUS_SI
> EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
>
> void drm_dp_link_train_clock_recovery_delay(const u8
> dpcd[DP_RECEIVER_CAP_SIZE]) {
> - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> DP_TRAINING_AUX_RD_MASK;
> +
> + if (rd_interval > 4)
> + DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)",
> rd_interval);
> +
> + if (rd_interval == 0 || (dpcd[DP_DPCD_REV] >= DP_REV_14))
> udelay(100);
> else
> - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> + mdelay(rd_interval * 4)
Need a semicolon here.
/mnt/host/source/src/third_party/kernel/v4.14/drivers/gpu/drm/drm_dp_helper.c:
In function 'drm_dp_link_train_clock_recovery_delay':
/mnt/host/source/src/third_party/kernel/v4.14/drivers/gpu/drm/drm_dp_helper.c:131:1:
error: expected ';' before '}' token
}
^
make[4]: ***
[/mnt/host/source/src/third_party/kernel/v4.14/scripts/Makefile.build:320:
drivers/gpu/drm/drm_dp_helper.o] Error 1
Thanks,
Benson
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] v3.9-rc1 instability on Chromebook Pixel with gmbus irq
Hi Daniel, I've just tried drm-intel-fixes merged into v3.9-rc1, and so far it's looking good. No suspicious timeouts. Thanks for the quick response! Benson On Wed, Mar 6, 2013 at 12:14 AM, Daniel Vetter wrote: > On Wed, Mar 6, 2013 at 3:35 AM, Benson Leung wrote: >> I'm working on touch devices Chromium OS, and I've noticed a >> regression between 3.8 and 3.9-rc1, which was posted yesterday. >> >> The hardware in question is a Chromebook Pixel. For this device, we >> have i2c input devices: atmel mxt224s touchpad and atmel mxt1664s >> touchscreen. The touchpad is on bus 1, "i915 gmbus vga" at 1-004b. The >> touchscreen is on bus 2, "i915 gmbus panel" at 2-004a. >> >> I was testing v3.9-rc1 on the Pixel and the touchscreen driver is >> being returned -110 (-ETIMEDOUT) on an i2c_transfer after several >> seconds of both touch devices working correctly. At the time of the >> failure, there are no error messages from GMBUS that I can see, but >> the bus never recovers. I can keep interacting with the touchscreen or >> touchpad, and the interrupts trigger reads, but all subsequent reads >> return -110. >> >> I noticed that between 3.8 and 3.9-rc1, your patch series to add gmbus >> irq support was merged. After bisecting, I found that this commit >> seems to be causing the timeout problem. Reverting it makes the >> problem go away, and the bus is stable. > > Can you please retest with latest drm-intel-fixes merged into -rc1? > Paulo's patch fixes a race in handling PCH interrupts (where the gmbus > hw is) which matches rather well with your description here. > > Thanks, Daniel > >> commit 2c438c0273b76d6cb158f8bdd0aa3ebf66e48a28 >> Author: Daniel Vetter >> Date: Sat Dec 1 13:53:46 2012 +0100 >> >> drm/i915: use gmbus irq to wait for gmbus idle >> >> GMBUS_ACTIVE has inverted sense and so doesn't fit into the >> wait_hw_status helper, hence create a new gmbus_wait_idle functions. >> Also, we only care about the idle irq event and nothing else, which >> allows us to use the wait_event_timeout helper directly without >> jumping through hoops to catch NAKs. >> >> Since gen2/3 don't have gmbus interrupts, handle them separately with >> the old wait_for macro. >> >> This shaves another few ms off reading EDID from a hdmi screen on my >> testbox here. EDID reading with interrupt driven gmbus is now as fast >> as with busy-looping gmbus at 28 ms here (with negligible cpu >> overhead). >> >> Reviewed-by: Imre Deak >> Signed-off-by: Daniel Vetter >> >> >> Is there anything I can do to help debug this some more? >> >> -- >> Benson Leung >> Software Engineer, Chrom* OS >> ble...@chromium.org > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Benson Leung Software Engineer, Chrom* OS ble...@chromium.org ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
