Re: [PATCH] pch_dma: Use GFP_ATOMIC because called from interrupt context
Hi
Could you review this patch ?
8 days have passed...
thanks,
tomoya
On Tue, Feb 12, 2013 at 11:25 AM, Tomoya MORINAGA wrote:
> pdc_desc_get() is called from pd_prep_slave_sg, and the function is
> called from interrupt context(e.g. Uart driver "pch_uart.c").
> In fact, I saw kernel error message.
> So, GFP_ATOMIC must be used not GFP_NOIO.
>
> Signed-off-by: Tomoya MORINAGA
> ---
> drivers/dma/pch_dma.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/dma/pch_dma.c b/drivers/dma/pch_dma.c
> index 987ab5c..d5cbd44 100644
> --- a/drivers/dma/pch_dma.c
> +++ b/drivers/dma/pch_dma.c
> @@ -476,7 +476,7 @@ static struct pch_dma_desc *pdc_desc_get(struct
> pch_dma_chan *pd_chan)
> dev_dbg(chan2dev(_chan->chan), "scanned %d descriptors\n", i);
>
> if (!ret) {
> - ret = pdc_alloc_desc(_chan->chan, GFP_NOIO);
> + ret = pdc_alloc_desc(_chan->chan, GFP_ATOMIC);
> if (ret) {
> spin_lock(_chan->lock);
> pd_chan->descs_allocated++;
> --
> 1.7.4.4
--
ROHM Co., Ltd.
tomoya
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pch_dma: Use GFP_ATOMIC because called from interrupt context
Hi
Could you review this patch ?
8 days have passed...
thanks,
tomoya
On Tue, Feb 12, 2013 at 11:25 AM, Tomoya MORINAGA tomoya.r...@gmail.com wrote:
pdc_desc_get() is called from pd_prep_slave_sg, and the function is
called from interrupt context(e.g. Uart driver pch_uart.c).
In fact, I saw kernel error message.
So, GFP_ATOMIC must be used not GFP_NOIO.
Signed-off-by: Tomoya MORINAGA tomoya.r...@gmail.com
---
drivers/dma/pch_dma.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/pch_dma.c b/drivers/dma/pch_dma.c
index 987ab5c..d5cbd44 100644
--- a/drivers/dma/pch_dma.c
+++ b/drivers/dma/pch_dma.c
@@ -476,7 +476,7 @@ static struct pch_dma_desc *pdc_desc_get(struct
pch_dma_chan *pd_chan)
dev_dbg(chan2dev(pd_chan-chan), scanned %d descriptors\n, i);
if (!ret) {
- ret = pdc_alloc_desc(pd_chan-chan, GFP_NOIO);
+ ret = pdc_alloc_desc(pd_chan-chan, GFP_ATOMIC);
if (ret) {
spin_lock(pd_chan-lock);
pd_chan-descs_allocated++;
--
1.7.4.4
--
ROHM Co., Ltd.
tomoya
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pch_dma: Use GFP_ATOMIC because called from interrupt context
pdc_desc_get() is called from pd_prep_slave_sg, and the function is
called from interrupt context(e.g. Uart driver "pch_uart.c").
In fact, I saw kernel error message.
So, GFP_ATOMIC must be used not GFP_NOIO.
Signed-off-by: Tomoya MORINAGA
---
drivers/dma/pch_dma.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/pch_dma.c b/drivers/dma/pch_dma.c
index 987ab5c..d5cbd44 100644
--- a/drivers/dma/pch_dma.c
+++ b/drivers/dma/pch_dma.c
@@ -476,7 +476,7 @@ static struct pch_dma_desc *pdc_desc_get(struct
pch_dma_chan *pd_chan)
dev_dbg(chan2dev(_chan->chan), "scanned %d descriptors\n", i);
if (!ret) {
- ret = pdc_alloc_desc(_chan->chan, GFP_NOIO);
+ ret = pdc_alloc_desc(_chan->chan, GFP_ATOMIC);
if (ret) {
spin_lock(_chan->lock);
pd_chan->descs_allocated++;
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pch_dma: Use GFP_ATOMIC because called from interrupt context
pdc_desc_get() is called from pd_prep_slave_sg, and the function is
called from interrupt context(e.g. Uart driver pch_uart.c).
In fact, I saw kernel error message.
So, GFP_ATOMIC must be used not GFP_NOIO.
Signed-off-by: Tomoya MORINAGA tomoya.r...@gmail.com
---
drivers/dma/pch_dma.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/pch_dma.c b/drivers/dma/pch_dma.c
index 987ab5c..d5cbd44 100644
--- a/drivers/dma/pch_dma.c
+++ b/drivers/dma/pch_dma.c
@@ -476,7 +476,7 @@ static struct pch_dma_desc *pdc_desc_get(struct
pch_dma_chan *pd_chan)
dev_dbg(chan2dev(pd_chan-chan), scanned %d descriptors\n, i);
if (!ret) {
- ret = pdc_alloc_desc(pd_chan-chan, GFP_NOIO);
+ ret = pdc_alloc_desc(pd_chan-chan, GFP_ATOMIC);
if (ret) {
spin_lock(pd_chan-lock);
pd_chan-descs_allocated++;
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: add Packet hub driver for Topcliff Platform controller hub
Hi Dan,
On Mon, Jan 7, 2013 at 6:02 PM, Dan Carpenter wrote:
> The patch cf4ece53460c: "add Packet hub driver for Topcliff Platform
> controller hub" from Sep 1, 2010, leads to the following warning:
> drivers/misc/pch_phub.c:596 pch_phub_bin_write()
> error: buffer overflow 'buf' 4096 <= 15359
>
> Sorry my question is about an old patch. Smatch complains because we
> only pass a PAGE_SIZE buffer to sysfs files so the test for
> "if (count > PCH_PHUB_OROM_SIZE) {" makes it think we are overflowing.
> In fact, count is never more than 4096 so there is no overflow, but I
> also think that it means only the first 4096 bytes of the firmware gets
> updated.
>
> drivers/misc/pch_phub.c
>560 static ssize_t pch_phub_bin_write(struct file *filp, struct kobject
> *kobj,
>561struct bin_attribute *attr,
>562char *buf, loff_t off, size_t count)
>563 {
>564 int err;
>565 unsigned int addr_offset;
>566 int ret;
>567 ssize_t rom_size;
>568 struct pch_phub_reg *chip =
>569 dev_get_drvdata(container_of(kobj, struct device,
> kobj));
>570
>571 ret = mutex_lock_interruptible(_phub_mutex);
>572 if (ret)
>573 return -ERESTARTSYS;
>574
>575 if (off > PCH_PHUB_OROM_SIZE) {
>576 addr_offset = 0;
>577 goto return_ok;
>578 }
>579 if (count > PCH_PHUB_OROM_SIZE) {
> ^^
> This is 15359.
>
>580 addr_offset = 0;
>581 goto return_ok;
>582 }
>583
>584 chip->pch_phub_extrom_base_address = pci_map_rom(chip->pdev,
> _size);
>585 if (!chip->pch_phub_extrom_base_address) {
>586 err = -ENOMEM;
>587 goto exrom_map_err;
>588 }
>589
>590 for (addr_offset = 0; addr_offset < count; addr_offset++) {
>591 if (PCH_PHUB_OROM_SIZE < off + addr_offset)
>592 goto return_ok;
>593
>594 ret = pch_phub_write_serial_rom(chip,
>595 chip->pch_opt_rom_start_address +
> addr_offset + off,
>596 buf[addr_offset]);
>
> Smatch complains because "buf" is only 4096 bytes.
>
I can understand your saying.
You mean just delete the following condition ?
579 if (count > PCH_PHUB_OROM_SIZE) {
Thanks.
--
ROHM Co., Ltd.
tomoya
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: add Packet hub driver for Topcliff Platform controller hub
Hi Dan,
On Mon, Jan 7, 2013 at 6:02 PM, Dan Carpenter dan.carpen...@oracle.com wrote:
The patch cf4ece53460c: add Packet hub driver for Topcliff Platform
controller hub from Sep 1, 2010, leads to the following warning:
drivers/misc/pch_phub.c:596 pch_phub_bin_write()
error: buffer overflow 'buf' 4096 = 15359
Sorry my question is about an old patch. Smatch complains because we
only pass a PAGE_SIZE buffer to sysfs files so the test for
if (count PCH_PHUB_OROM_SIZE) { makes it think we are overflowing.
In fact, count is never more than 4096 so there is no overflow, but I
also think that it means only the first 4096 bytes of the firmware gets
updated.
drivers/misc/pch_phub.c
560 static ssize_t pch_phub_bin_write(struct file *filp, struct kobject
*kobj,
561struct bin_attribute *attr,
562char *buf, loff_t off, size_t count)
563 {
564 int err;
565 unsigned int addr_offset;
566 int ret;
567 ssize_t rom_size;
568 struct pch_phub_reg *chip =
569 dev_get_drvdata(container_of(kobj, struct device,
kobj));
570
571 ret = mutex_lock_interruptible(pch_phub_mutex);
572 if (ret)
573 return -ERESTARTSYS;
574
575 if (off PCH_PHUB_OROM_SIZE) {
576 addr_offset = 0;
577 goto return_ok;
578 }
579 if (count PCH_PHUB_OROM_SIZE) {
^^
This is 15359.
580 addr_offset = 0;
581 goto return_ok;
582 }
583
584 chip-pch_phub_extrom_base_address = pci_map_rom(chip-pdev,
rom_size);
585 if (!chip-pch_phub_extrom_base_address) {
586 err = -ENOMEM;
587 goto exrom_map_err;
588 }
589
590 for (addr_offset = 0; addr_offset count; addr_offset++) {
591 if (PCH_PHUB_OROM_SIZE off + addr_offset)
592 goto return_ok;
593
594 ret = pch_phub_write_serial_rom(chip,
595 chip-pch_opt_rom_start_address +
addr_offset + off,
596 buf[addr_offset]);
Smatch complains because buf is only 4096 bytes.
I can understand your saying.
You mean just delete the following condition ?
579 if (count PCH_PHUB_OROM_SIZE) {
Thanks.
--
ROHM Co., Ltd.
tomoya
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] misc/pch_phub: Enable UART clock setting by module parameter
On Wed, Jul 25, 2012 at 10:31 PM, Arnd Bergmann wrote: > What I think should work better here would be to use the clk API, > so that the phub driver registers a 'struct clk' using > (I assume) clk_register_divider_table(). > The UART driver would then call clk_get() to find that clk for > the uart device and call clk_set_rate when it needs to change > that clock in order to set a different baud rate. > > Does this make sense? > Thank you for your comments. This sounds good idea. However, it seems the latest kernel doesn't have clk_register_divider_table(). Will the clk_register_divider_table function be applied soon ? Thanks. -- ROHM Co., Ltd. tomoya -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] misc/pch_phub: Enable UART clock setting by module parameter
On Wed, Jul 25, 2012 at 10:31 PM, Arnd Bergmann a...@arndb.de wrote: What I think should work better here would be to use the clk API, so that the phub driver registers a 'struct clk' using (I assume) clk_register_divider_table(). The UART driver would then call clk_get() to find that clk for the uart device and call clk_set_rate when it needs to change that clock in order to set a different baud rate. Does this make sense? Thank you for your comments. This sounds good idea. However, it seems the latest kernel doesn't have clk_register_divider_table(). Will the clk_register_divider_table function be applied soon ? Thanks. -- ROHM Co., Ltd. tomoya -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] misc/pch_phub: Enable UART clock setting by module parameter
Hi Arnd, Let me know this patch status. If you have still any concern, let me know. BTW, now I remember, Did you take part in LinuxConJapan last month ? I also took part in this event as volunteer staff. Additionally, I took charge of your session as time keeper. Thanks in advance. -- ROHM Co., Ltd. tomoya On Thu, Jul 12, 2012 at 9:54 AM, Tomoya MORINAGA wrote: > On Wed, Jul 11, 2012 at 7:45 PM, Arnd Bergmann wrote: >> This looks like a rather nonscalable solution if you get to systems >> with lots of clocks. > > This "clock" is internal clock, not external clock. > This PacketHub provides clock to the UART module > Both the PacketHub and the UART is in 1 chip LSI which is EG20T. > So, selectable clock 1.8432MHz or 48MHz or 64MHz or 192MHz are enough. > >> Given that you are doing it for the uart clock, shouldn't that be >> set from the uart driver using an ioctl like other serial ports do? > PacketHub is not serial driver but special driver. So, ioctl doesn't > suit PacketHub. > >> What would be the use case for an end user to override the module >> parameter? Is it about platform specific settings or policy? > I show use case. > Currently, UART works with 1.8432MHz. > Using this clock, as you know, maximum speed is 115k. > A user wants to use 4M speed, the user need to modify pch_phun.c by hand. > If this patch is applied, a user can specify uart_clock via a modules > parameter and use 4M speed. > > My reference driver for this patch is drivers/tty/serial/pch_uart.c > This driver can set uart_clock via a module parameter(user_uartclk). > > Thanks. > -- > ROHM Co., Ltd. > tomoya -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] misc/pch_phub: Enable UART clock setting by module parameter
Hi Arnd, Let me know this patch status. If you have still any concern, let me know. BTW, now I remember, Did you take part in LinuxConJapan last month ? I also took part in this event as volunteer staff. Additionally, I took charge of your session as time keeper. Thanks in advance. -- ROHM Co., Ltd. tomoya On Thu, Jul 12, 2012 at 9:54 AM, Tomoya MORINAGA tomoya.r...@gmail.com wrote: On Wed, Jul 11, 2012 at 7:45 PM, Arnd Bergmann a...@arndb.de wrote: This looks like a rather nonscalable solution if you get to systems with lots of clocks. This clock is internal clock, not external clock. This PacketHub provides clock to the UART module Both the PacketHub and the UART is in 1 chip LSI which is EG20T. So, selectable clock 1.8432MHz or 48MHz or 64MHz or 192MHz are enough. Given that you are doing it for the uart clock, shouldn't that be set from the uart driver using an ioctl like other serial ports do? PacketHub is not serial driver but special driver. So, ioctl doesn't suit PacketHub. What would be the use case for an end user to override the module parameter? Is it about platform specific settings or policy? I show use case. Currently, UART works with 1.8432MHz. Using this clock, as you know, maximum speed is 115k. A user wants to use 4M speed, the user need to modify pch_phun.c by hand. If this patch is applied, a user can specify uart_clock via a modules parameter and use 4M speed. My reference driver for this patch is drivers/tty/serial/pch_uart.c This driver can set uart_clock via a module parameter(user_uartclk). Thanks. -- ROHM Co., Ltd. tomoya -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] usb/host/ehci-hub: Fix the issue EG20T USB host controller has long resuming time, when pen drive is attached.
Intel EG20T USB host controller does not send SOF in resuming time after suspending, if the FLR bit was not cleared. When pen drive is attached, the controller has a long resuming time to try re-connect it. This patch clear the FLR bit in suspending time for fixing the issue. Signed-off-by: Tomoya MORINAGA --- v3: Update comments from Alan Stern Add comment in the source code. v2: Update comments from Alan Stern Add patch description Always clear the STS_FLR flag. --- drivers/usb/host/ehci-hub.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c index fc9e7cc..278b589 100644 --- a/drivers/usb/host/ehci-hub.c +++ b/drivers/usb/host/ehci-hub.c @@ -318,6 +318,13 @@ static int ehci_bus_suspend (struct usb_hcd *hcd) ehci_readl(ehci, >regs->intr_enable); ehci->next_statechange = jiffies + msecs_to_jiffies(10); + + /* Intel EG20T USB host controller does not send SOF +* in resuming time after suspending, if the FLR bit was not cleared. +* Therefore clear the FLR bit in here. +*/ + ehci_writel(ehci, STS_FLR, >regs->status); + spin_unlock_irq (>lock); /* ehci_work() may have re-enabled the watchdog timer, which we do not -- 1.7.4.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] usb/host/ehci-hub: Fix the issue EG20T USB host controller has long resuming time, when pen drive is attached.
Intel EG20T USB host controller does not send SOF in resuming time after suspending, if the FLR bit was not cleared. When pen drive is attached, the controller has a long resuming time to try re-connect it. This patch clear the FLR bit in suspending time for fixing the issue. Signed-off-by: Tomoya MORINAGA tomoya.r...@gmail.com --- v3: Update comments from Alan Stern Add comment in the source code. v2: Update comments from Alan Stern Add patch description Always clear the STS_FLR flag. --- drivers/usb/host/ehci-hub.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c index fc9e7cc..278b589 100644 --- a/drivers/usb/host/ehci-hub.c +++ b/drivers/usb/host/ehci-hub.c @@ -318,6 +318,13 @@ static int ehci_bus_suspend (struct usb_hcd *hcd) ehci_readl(ehci, ehci-regs-intr_enable); ehci-next_statechange = jiffies + msecs_to_jiffies(10); + + /* Intel EG20T USB host controller does not send SOF +* in resuming time after suspending, if the FLR bit was not cleared. +* Therefore clear the FLR bit in here. +*/ + ehci_writel(ehci, STS_FLR, ehci-regs-status); + spin_unlock_irq (ehci-lock); /* ehci_work() may have re-enabled the watchdog timer, which we do not -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] usb/host/ehci-hub: Fix the issue EG20T USB host controller has long resuming time, when pen drive is attached.
Intel EG20T USB host controller does not send SOF in resuming time after suspending, if the FLR bit was not cleared. When pen drive is attached, the controller has a long resuming time to try re-connect it. This patch clear the FLR bit in suspending time for fixing the issue. Signed-off-by: Tomoya MORINAGA --- v2: Update comments from Alan Stern Add patch description Always clear the STS_FLR flag. --- drivers/usb/host/ehci-hub.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c index fc9e7cc..818a2f1 100644 --- a/drivers/usb/host/ehci-hub.c +++ b/drivers/usb/host/ehci-hub.c @@ -318,6 +318,7 @@ static int ehci_bus_suspend (struct usb_hcd *hcd) ehci_readl(ehci, >regs->intr_enable); ehci->next_statechange = jiffies + msecs_to_jiffies(10); + ehci_writel(ehci, STS_FLR, >regs->status); spin_unlock_irq (>lock); /* ehci_work() may have re-enabled the watchdog timer, which we do not -- 1.7.4.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] misc/pch_phub: Enable UART clock setting by module parameter
On Wed, Jul 11, 2012 at 7:45 PM, Arnd Bergmann wrote: > This looks like a rather nonscalable solution if you get to systems > with lots of clocks. This "clock" is internal clock, not external clock. This PacketHub provides clock to the UART module Both the PacketHub and the UART is in 1 chip LSI which is EG20T. So, selectable clock 1.8432MHz or 48MHz or 64MHz or 192MHz are enough. > Given that you are doing it for the uart clock, shouldn't that be > set from the uart driver using an ioctl like other serial ports do? PacketHub is not serial driver but special driver. So, ioctl doesn't suit PacketHub. > What would be the use case for an end user to override the module > parameter? Is it about platform specific settings or policy? I show use case. Currently, UART works with 1.8432MHz. Using this clock, as you know, maximum speed is 115k. A user wants to use 4M speed, the user need to modify pch_phun.c by hand. If this patch is applied, a user can specify uart_clock via a modules parameter and use 4M speed. My reference driver for this patch is drivers/tty/serial/pch_uart.c This driver can set uart_clock via a module parameter(user_uartclk). Thanks. -- ROHM Co., Ltd. tomoya -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] misc/pch_phub: Enable UART clock setting by module parameter
Currently, when a user wants to change UART clock,
needs to modify this source code by hand.
This patch enables changing UART clock by specifying UART clock
as module parameter.
Signed-off-by: Tomoya MORINAGA
---
drivers/misc/pch_phub.c | 45 +
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/drivers/misc/pch_phub.c b/drivers/misc/pch_phub.c
index 9fbcacd..2e7b0b0 100644
--- a/drivers/misc/pch_phub.c
+++ b/drivers/misc/pch_phub.c
@@ -93,6 +93,18 @@
#define PCH_PHUB_OROM_SIZE 15360
+#define CLKCFG_BAUDDIV2(2 << 20)
+#define CLKCFG_BAUDDIV6(6 << 20)
+#define CLKCFG_PLL2VCO8(8 << 9)
+
+#define PCH_PHUB_REFCLK_48MHZ CLKCFG_UART_48MHZ
+
+#define PCH_PHUB_REFCLK_64MHZ (CLKCFG_UART_48MHZ | CLKCFG_BAUDDIV6 |\
+ CLKCFG_PLL2VCO8 | CLKCFG_UARTCLKSEL)
+
+#define PCH_PHUB_REFCLK_192MHZ (CLKCFG_UART_48MHZ | CLKCFG_BAUDDIV2 |\
+ CLKCFG_PLL2VCO8 | CLKCFG_UARTCLKSEL)
+
/**
* struct pch_phub_reg - PHUB register structure
* @phub_id_reg: PHUB_ID register val
@@ -142,6 +154,8 @@ struct pch_phub_reg {
/* SROM SPEC for MAC address assignment offset */
static const int pch_phub_mac_offset[ETH_ALEN] = {0x3, 0x2, 0x1, 0x0, 0xb,
0xa};
+static unsigned int select_uart_clk;
+
static DEFINE_MUTEX(pch_phub_mutex);
/**
@@ -710,6 +724,34 @@ static int __devinit pch_phub_probe(struct pci_dev *pdev,
chip->pdev = pdev; /* Save pci device struct */
+ /* Reference clock setting. ML7223 bus-m doesn't have clock register. */
+ if (select_uart_clk && id->driver_data != 3) {
+ unsigned int clk_val;
+ switch (select_uart_clk) {
+ case 4800:
+ case 48:
+ clk_val = PCH_PHUB_REFCLK_48MHZ;
+ break;
+ case 6400:
+ case 64:
+ clk_val = PCH_PHUB_REFCLK_64MHZ;
+ break;
+ case 19200:
+ case 192:
+ clk_val = PCH_PHUB_REFCLK_192MHZ;
+ break;
+ default:
+ dev_err(>dev,
+ "%s : Invalid clock(Only 48/64/192MHz).\n",
+ __func__);
+ goto err_sysfs_create;
+ }
+ pch_phub_read_modify_write_reg(chip,
+ (unsigned int)CLKCFG_REG_OFFSET,
+ clk_val, CLKCFG_UART_MASK);
+ }
+
+
if (id->driver_data == 1) { /* EG20T PCH */
const char *board_name;
@@ -908,3 +950,6 @@ module_exit(pch_phub_pci_exit);
MODULE_DESCRIPTION("Intel EG20T PCH/LAPIS Semiconductor IOH(ML7213/ML7223)
PHUB");
MODULE_LICENSE("GPL");
+module_param(select_uart_clk, uint, S_IRUGO);
+MODULE_PARM_DESC(select_uart_clk,
+"Select clock for UART (48/64/192MHz). default is 1.8342MHz");
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] misc/pch_phub: Enable UART clock setting by module parameter
Currently, when a user wants to change UART clock,
needs to modify this source code by hand.
This patch enables changing UART clock by specifying UART clock
as module parameter.
Signed-off-by: Tomoya MORINAGA tomoya.r...@gmail.com
---
drivers/misc/pch_phub.c | 45 +
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/drivers/misc/pch_phub.c b/drivers/misc/pch_phub.c
index 9fbcacd..2e7b0b0 100644
--- a/drivers/misc/pch_phub.c
+++ b/drivers/misc/pch_phub.c
@@ -93,6 +93,18 @@
#define PCH_PHUB_OROM_SIZE 15360
+#define CLKCFG_BAUDDIV2(2 20)
+#define CLKCFG_BAUDDIV6(6 20)
+#define CLKCFG_PLL2VCO8(8 9)
+
+#define PCH_PHUB_REFCLK_48MHZ CLKCFG_UART_48MHZ
+
+#define PCH_PHUB_REFCLK_64MHZ (CLKCFG_UART_48MHZ | CLKCFG_BAUDDIV6 |\
+ CLKCFG_PLL2VCO8 | CLKCFG_UARTCLKSEL)
+
+#define PCH_PHUB_REFCLK_192MHZ (CLKCFG_UART_48MHZ | CLKCFG_BAUDDIV2 |\
+ CLKCFG_PLL2VCO8 | CLKCFG_UARTCLKSEL)
+
/**
* struct pch_phub_reg - PHUB register structure
* @phub_id_reg: PHUB_ID register val
@@ -142,6 +154,8 @@ struct pch_phub_reg {
/* SROM SPEC for MAC address assignment offset */
static const int pch_phub_mac_offset[ETH_ALEN] = {0x3, 0x2, 0x1, 0x0, 0xb,
0xa};
+static unsigned int select_uart_clk;
+
static DEFINE_MUTEX(pch_phub_mutex);
/**
@@ -710,6 +724,34 @@ static int __devinit pch_phub_probe(struct pci_dev *pdev,
chip-pdev = pdev; /* Save pci device struct */
+ /* Reference clock setting. ML7223 bus-m doesn't have clock register. */
+ if (select_uart_clk id-driver_data != 3) {
+ unsigned int clk_val;
+ switch (select_uart_clk) {
+ case 4800:
+ case 48:
+ clk_val = PCH_PHUB_REFCLK_48MHZ;
+ break;
+ case 6400:
+ case 64:
+ clk_val = PCH_PHUB_REFCLK_64MHZ;
+ break;
+ case 19200:
+ case 192:
+ clk_val = PCH_PHUB_REFCLK_192MHZ;
+ break;
+ default:
+ dev_err(pdev-dev,
+ %s : Invalid clock(Only 48/64/192MHz).\n,
+ __func__);
+ goto err_sysfs_create;
+ }
+ pch_phub_read_modify_write_reg(chip,
+ (unsigned int)CLKCFG_REG_OFFSET,
+ clk_val, CLKCFG_UART_MASK);
+ }
+
+
if (id-driver_data == 1) { /* EG20T PCH */
const char *board_name;
@@ -908,3 +950,6 @@ module_exit(pch_phub_pci_exit);
MODULE_DESCRIPTION(Intel EG20T PCH/LAPIS Semiconductor IOH(ML7213/ML7223)
PHUB);
MODULE_LICENSE(GPL);
+module_param(select_uart_clk, uint, S_IRUGO);
+MODULE_PARM_DESC(select_uart_clk,
+Select clock for UART (48/64/192MHz). default is 1.8342MHz);
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] misc/pch_phub: Enable UART clock setting by module parameter
On Wed, Jul 11, 2012 at 7:45 PM, Arnd Bergmann a...@arndb.de wrote: This looks like a rather nonscalable solution if you get to systems with lots of clocks. This clock is internal clock, not external clock. This PacketHub provides clock to the UART module Both the PacketHub and the UART is in 1 chip LSI which is EG20T. So, selectable clock 1.8432MHz or 48MHz or 64MHz or 192MHz are enough. Given that you are doing it for the uart clock, shouldn't that be set from the uart driver using an ioctl like other serial ports do? PacketHub is not serial driver but special driver. So, ioctl doesn't suit PacketHub. What would be the use case for an end user to override the module parameter? Is it about platform specific settings or policy? I show use case. Currently, UART works with 1.8432MHz. Using this clock, as you know, maximum speed is 115k. A user wants to use 4M speed, the user need to modify pch_phun.c by hand. If this patch is applied, a user can specify uart_clock via a modules parameter and use 4M speed. My reference driver for this patch is drivers/tty/serial/pch_uart.c This driver can set uart_clock via a module parameter(user_uartclk). Thanks. -- ROHM Co., Ltd. tomoya -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] usb/host/ehci-hub: Fix the issue EG20T USB host controller has long resuming time, when pen drive is attached.
Intel EG20T USB host controller does not send SOF in resuming time after suspending, if the FLR bit was not cleared. When pen drive is attached, the controller has a long resuming time to try re-connect it. This patch clear the FLR bit in suspending time for fixing the issue. Signed-off-by: Tomoya MORINAGA tomoya.r...@gmail.com --- v2: Update comments from Alan Stern Add patch description Always clear the STS_FLR flag. --- drivers/usb/host/ehci-hub.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c index fc9e7cc..818a2f1 100644 --- a/drivers/usb/host/ehci-hub.c +++ b/drivers/usb/host/ehci-hub.c @@ -318,6 +318,7 @@ static int ehci_bus_suspend (struct usb_hcd *hcd) ehci_readl(ehci, ehci-regs-intr_enable); ehci-next_statechange = jiffies + msecs_to_jiffies(10); + ehci_writel(ehci, STS_FLR, ehci-regs-status); spin_unlock_irq (ehci-lock); /* ehci_work() may have re-enabled the watchdog timer, which we do not -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb/host/ehci-hub: Fix the issue EG20T USB host controller has long resuming time, when pen drive is attached.
Signed-off-by: Tomoya MORINAGA --- drivers/usb/host/ehci-hub.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c index fc9e7cc..d596d0f 100644 --- a/drivers/usb/host/ehci-hub.c +++ b/drivers/usb/host/ehci-hub.c @@ -207,6 +207,7 @@ static int ehci_bus_suspend (struct usb_hcd *hcd) int port; int mask; int changed; + int temp; ehci_dbg(ehci, "suspend root hub\n"); @@ -324,6 +325,9 @@ static int ehci_bus_suspend (struct usb_hcd *hcd) * want, and so we must delete any pending watchdog timer events. */ del_timer_sync(>watchdog); + temp = ehci_readl(ehci, >regs->status); + if (temp & STS_FLR) + ehci_writel(ehci, STS_FLR, >regs->status); return 0; } -- 1.7.4.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb/host/ehci-hub: Fix the issue EG20T USB host controller has long resuming time, when pen drive is attached.
Signed-off-by: Tomoya MORINAGA tomoya.r...@gmail.com --- drivers/usb/host/ehci-hub.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c index fc9e7cc..d596d0f 100644 --- a/drivers/usb/host/ehci-hub.c +++ b/drivers/usb/host/ehci-hub.c @@ -207,6 +207,7 @@ static int ehci_bus_suspend (struct usb_hcd *hcd) int port; int mask; int changed; + int temp; ehci_dbg(ehci, suspend root hub\n); @@ -324,6 +325,9 @@ static int ehci_bus_suspend (struct usb_hcd *hcd) * want, and so we must delete any pending watchdog timer events. */ del_timer_sync(ehci-watchdog); + temp = ehci_readl(ehci, ehci-regs-status); + if (temp STS_FLR) + ehci_writel(ehci, STS_FLR, ehci-regs-status); return 0; } -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
