pch_uart and pch_phub clock selection

From f83fa6cb575844d8e37f136890fe32258eb88dd2 Mon Sep 17 00:00:00 2001

I'm working on a tunnel creek (atom e6xx + topcliff PCH) development platform that uses a 48MHz or 64MHz clock to drive the pch_uart. I've found that if I force the uart_clock to 48MHz (or 64MHz on the latest rev) I can get the kernel messages and getty on the serial port.

I see that the the CM-iTC board is special-cased to set a 192MHz uart_clock. This is done in pch_uart.c code, but there is some register manipulation done in the pch_phub.c driver and I don't understand the connection. How are the two related?

Is the pch_phub.c register manipulation required for proper related? It seems to work without touching those registers if I just force the clock.

The device I'm working with is EFI, and the dmi_get_system_info(DMI_BOARD_NAME) returns "(null)", so I can't use the same test to identify this board. Is there another common mechanism I might be able to use?

The following patch (by way of example, not meant for inclusion) gets things working for this particular board with this command line:

console=ttyPCH1,115200 pch_uart.clock_param=48000000

I believe the right thing to do here is to discover a way to identify the board and special case the clock as is done for the CM-iTC, but I would like to understand the purpose of the pch_phub register manipulation code. Does this make sense?

Thanks,

Darren

Quoted 1 line

From f83fa6cb575844d8e37f136890fe32258eb88dd2 Mon Sep 17 00:00:00 2001

Message-Id: <f83fa6cb575844d8e37f136890fe32258eb88dd2.1329439822.git.dvhart@linux.intel.com>
From: Darren Hart <[email protected]>
Date: Wed, 15 Feb 2012 15:44:18 -0800
Subject: [PATCH] pch_uart: Add clock parameter

Allow for the specification of the clock as a module parameter. This is useful when a board uses a non-standard clock, or when different versions of a board use different clocks, and that board name or the version are not available to the kernel.

I'm working on a tunnel creek (atom e6xx + topcliff PCH) development platform that uses a 48MHz or 64MHz clock to drive the pch_uart. I've found that if I force the uart_clock to 48MHz (or 64MHz on the latest rev) I can get the kernel messages and getty on the serial port.

I see that the the CM-iTC board is special-cased to set a 192MHz uart_clock. This is done in pch_uart.c code, but there is some register manipulation done in the pch_phub.c driver and I don't understand the connection. How are the two related?

From 091952dc27d3bf76e28b2afbc2fb36f0d6caada1 Mon Sep 17 00:00:00 2001

Is the pch_phub.c register manipulation required for proper related? It seems to work without touching those registers if I just force the clock.

The device I'm working with is EFI, and the dmi_get_system_info(DMI_BOARD_NAME) returns "(null)", so I can't use the same test to identify this board. Is there another common mechanism I might be able to use?

The following patch (by way of example, not meant for inclusion) gets things working for this particular board with this command line:

console=ttyPCH1,115200 pch_uart.clock_param=48000000

I believe the right thing to do here is to discover a way to identify the board and special case the clock as is done for the CM-iTC, but I would like to understand the purpose of the pch_phub register manipulation code. Does this make sense?

Thanks,

Darren

I see that the the CM-iTC board is special-cased to set a 192MHz uart_clock. This is done in pch_uart.c code, but there is some register manipulation done in the pch_phub.c driver and I don't understand the connection. How are the two related?

Tomoya, do you know if we can also set it to 192MHz for ML7223 IOH Bus-m/n?

Hi

2012年2月17日16:28 Feng Tang <[email protected]>:

Quoted 4 lines

I see that the the CM-iTC board is special-cased to set a 192MHz uart_clock. This is done in pch_uart.c code, but there is some register manipulation done in the pch_phub.c driver and I don't understand the connection. How are the two related?

According to your use, need to configure clock registers which are in pch_phub . Upstreamed version, UART_CLK can be used directly(neither multiple nor division) as UART clock.

You can get clock configuration information from SourceForge.
(http://sourceforge.net/projects/ml7213/files/Kernel%202.6.37/Release/Ver1.2.0/EG20TPCH_ML7213_ML7223_ML7831_linux-2.6.37_v120_20110930.tar.bz2/
and extract pch_phub. you can find readme.)
I extract it and show below.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<Configuration>
=======================

1. Over 115K baud rate UART settings
By default, UART can communicate less than 115Kbps.
In case you want UART to work more than 115Kbps, the following
clock configuration is necessary.
- Clock setting
Set BAUDSEL = usb_48mhz
Set PLL2VCO = "x 8" the clock
Set BAUDDIV = "x 1/6" the clock
Set UARTCLKSEL = PLL2 output
For details, please refer to ML7213/ML7223 EDS "5 Chip Configuration"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In case we want UART to work high baud rate(e.g.4Mbps), we set like above. and execute "setserial /dev/ttyPCH0 baud_base 4000000".
I can see PCH_UART with 4Mbps works well.

Darren, is this answer for your question ?

Quoted 2 lines

Tomoya, do you know if we can also set it to 192MHz for ML7223 IOH Bus-m/n?

Yes, you can.

Quoted 13 lines · Darren Hart

I'm working on a tunnel creek (atom e6xx + topcliff PCH) development platform that uses a 48MHz or 64MHz clock to drive the pch_uart. I've found that if I force the uart_clock to 48MHz (or 64MHz on the latest rev) I can get the kernel messages and getty on the serial port.

I see that the the CM-iTC board is special-cased to set a 192MHz uart_clock. This is done in pch_uart.c code, but there is some register manipulation done in the pch_phub.c driver and I don't understand the connection. How are the two related?

Is the pch_phub.c register manipulation required for proper related? It seems to work without touching those registers if I just force the clock.

Quoted 3 lines

The device I'm working with is EFI, and the dmi_get_system_info(DMI_BOARD_NAME) returns "(null)", so I can't use the same test to identify this board. Is there another common mechanism I might be able to use?

There's no relevant DMI information for the board at all? What does:

	grep . /sys/class/dmi/id/*

show?

Quoted 23 lines

The following patch (by way of example, not meant for inclusion) gets things working for this particular board with this command line:

console=ttyPCH1,115200 pch_uart.clock_param=48000000

I believe the right thing to do here is to discover a way to identify the board and special case the clock as is done for the CM-iTC, but I would like to understand the purpose of the pch_phub register manipulation code. Does this make sense?

Thanks,

Darren

Quoted 1 line

From f83fa6cb575844d8e37f136890fe32258eb88dd2 Mon Sep 17 00:00:00 2001

Message-Id: <f83fa6cb575844d8e37f136890fe32258eb88dd2.1329439822.git.dvhart@linux.intel.com>
From: Darren Hart <[email protected]>
Date: Wed, 15 Feb 2012 15:44:18 -0800
Subject: [PATCH] pch_uart: Add clock parameter

Quoted 4 lines

Allow for the specification of the clock as a module parameter. This is useful when a board uses a non-standard clock, or when different versions of a board use different clocks, and that board name or the version are not available to the kernel.

You also rename base_baud to uart_clock here, so you might want to mention it in the changelog entry :)

greg k-h

Quoted 10 lines

Hi

2012年2月17日16:28 Feng Tang <[email protected]>:

Quoted 4 lines

I see that the the CM-iTC board is special-cased to set a 192MHz uart_clock. This is done in pch_uart.c code, but there is some register manipulation done in the pch_phub.c driver and I don't understand the connection. How are the two related?

According to your use, need to configure clock registers which are in pch_phub . Upstreamed version, UART_CLK can be used directly(neither multiple nor division) as UART clock.

I'm not following. I think you are saying that I need to configure the clock registers - but in my patch I don't touch them and it works. Are the registers intended to be read so I can determine HOW the device is configured, are they intended to be written in order to change how it is configured, or both.

Firmware sets up some initial state and this has been what I'm trying to match in order to get an early serial console.

Quoted 22 lines

You can get clock configuration information from SourceForge.
(http://sourceforge.net/projects/ml7213/files/Kernel%202.6.37/Release/Ver1.2.0/EG20TPCH_ML7213_ML7223_ML7831_linux-2.6.37_v120_20110930.tar.bz2/
and extract pch_phub. you can find readme.)
I extract it and show below.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<Configuration>
=======================

1. Over 115K baud rate UART settings
By default, UART can communicate less than 115Kbps.
In case you want UART to work more than 115Kbps, the following
clock configuration is necessary.
- Clock setting
Set BAUDSEL = usb_48mhz
Set PLL2VCO = "x 8" the clock
Set BAUDDIV = "x 1/6" the clock
Set UARTCLKSEL = PLL2 output
For details, please refer to ML7213/ML7223 EDS "5 Chip Configuration"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Quoted 5 lines

In case we want UART to work high baud rate(e.g.4Mbps), we set like above. and execute "setserial /dev/ttyPCH0 baud_base 4000000".
I can see PCH_UART with 4Mbps works well.

Darren, is this answer for your question ?

Not quite. I need to be able to use the UART at boot as an early serial console. So I believe I need to match the firmware UART configuration early on (well before we could call setserial).

Quoted 4 lines

Quoted 2 lines

Tomoya, do you know if we can also set it to 192MHz for ML7223 IOH Bus-m/n?

Yes, you can.

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Hi

Considering Feng's/Darren's proposal/question,
I should have set 192MHz as default uart clock setting. So, I created the following patch. (not formal patch but for review) Let me know your opinion.

---
 drivers/misc/pch_phub.c       |   17 ++++++-----------
 drivers/tty/serial/pch_uart.c |   15 +++++++--------
 2 files changed, 13 insertions(+), 19 deletions(-)

drivers/misc/pch_phub.c +1 -6

index 10fc478..8f9c1db 100644
@@ -55,7 +55,7 @@
 #define CLKCFG_CANCLK_MASK 0xFF000000
 #define CLKCFG_UART_MASK			0xFFFFFF
 
-/* CM-iTC */
+/* 192MHz Clock configuration. USB_48MHz / 2 * 8 = 192 */
 #define CLKCFG_UART_48MHZ			(1 << 16)
 #define CLKCFG_BAUDDIV				(2 << 20)
 #define CLKCFG_PLL2VCO				(8 << 9)

@@ -715,8 +715,6 @@ static int __devinit pch_phub_probe(struct pci_dev *pdev,
 	chip->pdev = pdev; /* Save pci device struct */
 
 	if (id->driver_data == 1) { /* EG20T PCH */
-		const char *board_name;
-
 		retval = sysfs_create_file(&pdev->dev.kobj,
 					   &dev_attr_pch_mac.attr);
 		if (retval)

@@ -731,14 +729,11 @@ static int __devinit pch_phub_probe(struct pci_dev *pdev,
 					       CLKCFG_CAN_50MHZ,
 					       CLKCFG_CANCLK_MASK);
 
-		/* quirk for CM-iTC board */
-		board_name = dmi_get_system_info(DMI_BOARD_NAME);
-		if (board_name && strstr(board_name, "CM-iTC"))

Can we also set ML7213/7223's
default clk to 192MHz? 192MHz works fine on my ML7213 board. And using an unified default clock rate for all EG20T compatible IOHs will save extra effort of setting the uart clock.

2012年2月20日13:43 Feng Tang <[email protected]>:

Quoted 5 lines

Can we also set ML7213/7223's
default clk to 192MHz? 192MHz works fine on my ML7213 board. And using an unified default clock rate for all EG20T compatible IOHs will save extra effort of setting the uart clock.

Yes, you can also use 192MHz for both ML7213 and ML7223. In fact, we've already confirmed 192MHz works fine. (Windows driver). thanks,

---
ROHM Co., Ltd.
tomoya

Great! and glad to hear that. Could you update your patch which only touches the EG20T UART clock setting? like taking the register setting code out of the "switch/case" loop. something like: