| Message ID | 49DD62AE.2090700@renesas.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Delegated to: | Paul Mundt |
| Headers | show |
Dear Iwamatsu > > But SH7723 doesn't have SCPTR/SCSPTR register. > > Therefore, I thought that it used IO port. > > > > So, I thought that it should read RXD pin if it use IO port. (snip) > I think that this is coding miss. > If you check implemenation of other SH CPU's(e.g. SH7722), > you can understand that other CPU checked RXD bit. If this is a just "coding miss", I can understand !! Thank you Best regards -- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Dear Iwamatsu > > I think that this is coding miss. > > If you check implemenation of other SH CPU's(e.g. SH7722), > > you can understand that other CPU checked RXD bit. > > If this is a just "coding miss", I can understand !! > Thank you Oops. But Can we really read RXD status from IO port ? Because when we use SCIF/SCIFA, function modules is selected in PFC. it is not IO port. Best regards -- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
morimoto.kuninori@renesas.com wrote: > Dear Iwamatsu > >>> I think that this is coding miss. >>> If you check implemenation of other SH CPU's(e.g. SH7722), >>> you can understand that other CPU checked RXD bit. >> If this is a just "coding miss", I can understand !! >> Thank you > > Oops. > But Can we really read RXD status from IO port ? > Because when we use SCIF/SCIFA, > function modules is selected in PFC. > it is not IO port. > We set function to use in PFC and it is from IO-port and controls them. For example, we want to get RXD of SCIF0, setup PSELC and PTCR, and get value from PTDR. OK? Best regards, Nobuhiro -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Dear Iwamatsu > We set function to use in PFC and it is from IO-port > and controls them. > > For example, we want to get RXD of SCIF0, setup PSELC and PTCR, > and get value from PTDR. Hmm.... Now I tried to watch PxDR behavior by JTAG. Then, I can read data from PxDR if PxCR is "I/O". But, I can not read data when PxCR is "Function". It is always 0x00. I think at least clock bit will change. Do you know why ? Best regards -- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Dear Paul, Iwamatsu > Now I tried to watch PxDR behavior by JTAG. > Then, I can read data from PxDR if PxCR is "I/O". > But, I can not read data when PxCR is "Function". > It is always 0x00. Is checking SCFSR::BRK (SCASSR::BRK) good idea ? It indicate rx break. Best regards -- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
morimoto.kuninori@renesas.com wrote: > Dear Iwamatsu > >> We set function to use in PFC and it is from IO-port >> and controls them. >> >> For example, we want to get RXD of SCIF0, setup PSELC and PTCR, >> and get value from PTDR. > > Hmm.... > Now I tried to watch PxDR behavior by JTAG. > Then, I can read data from PxDR if PxCR is "I/O". > But, I can not read data when PxCR is "Function". > It is always 0x00. > I think at least clock bit will change. > > Do you know why ? > In current code, when sci_handle_errors was called , sci_rxd_in seemed to come to be called it. Did you check this? Thanks, Nobuhiro -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Dear Iwamatsu > In current code, when sci_handle_errors was called , > sci_rxd_in seemed to come to be called it. > Did you check this? OK. Now I could understand. I think sci_rxd_in function is not called in SH7723. This function is for SCI which can not get rx break status from register. Best regards -- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/serial/sh-sci.h b/drivers/serial/sh-sci.h index d0aa82d..cc51500 100644 --- a/drivers/serial/sh-sci.h +++ b/drivers/serial/sh-sci.h @@ -591,15 +591,15 @@ static inline int sci_rxd_in(struct uart_port *port) static inline int sci_rxd_in(struct uart_port *port) { if (port->mapbase == 0xffe00000) - return ctrl_inb(SCSPTR0) & 0x0008 ? 1 : 0; /* SCIF0 */ + return ctrl_inb(SCSPTR0) & 0x0010 ? 1 : 0; /* SCIF0 */ if (port->mapbase == 0xffe10000) - return ctrl_inb(SCSPTR1) & 0x0020 ? 1 : 0; /* SCIF1 */ + return ctrl_inb(SCSPTR1) & 0x0040 ? 1 : 0; /* SCIF1 */ if (port->mapbase == 0xffe20000) - return ctrl_inb(SCSPTR2) & 0x0001 ? 1 : 0; /* SCIF2 */ + return ctrl_inb(SCSPTR2) & 0x0002 ? 1 : 0; /* SCIF2 */ if (port->mapbase == 0xa4e30000) - return ctrl_inb(SCSPTR3) & 0x0001 ? 1 : 0; /* SCIF3 */ + return ctrl_inb(SCSPTR3) & 0x0002 ? 1 : 0; /* SCIF3 */ if (port->mapbase == 0xa4e40000) - return ctrl_inb(SCSPTR4) & 0x0001 ? 1 : 0; /* SCIF4 */ + return ctrl_inb(SCSPTR4) & 0x0002 ? 1 : 0; /* SCIF4 */ if (port->mapbase == 0xa4e50000) return ctrl_inb(SCSPTR5) & 0x0008 ? 1 : 0; /* SCIF5 */ return 1;