RE: RE: RE: [PATCH v2 1/2] clk: divider: prepare for minimum divider
Hi Mike, On Sat, Jan 26, 2013 at 04:05:24, Mike Turquette wrote: Thank you for the information. In short, the way you program your clock depend on the configuration of your lcdc device. As such I am not sure the basic divider is the right choice for you. You might be better off creating a clock for your IP which takes into account these details. Luckily it is possible to inherit from the basic clock types and create a new type. An example of this is the MXS divider. It uses the basic divider as a parent class and adds a busy bit. This is a better approach than putting every feature into the basic divider type. You can see how it was done in drivers/clk/mxs/clk-div.c Let me know what you think. Yes, a derived divider is better. As mentioned in other thread, the modeling of clock nodes (derived plus gates) would bring in considerable (relative to complete driver) code, the advantage being higher pixel clock resolution. Current use cases work as per existing divider setting in driver. Hence now it seems a better decision now is to proceed with logic as in v2 (not using clock nodes). And later depending on the use case requirement, clock tree modeling can be implemented. Thanks for your input. Regards Afzal
RE: RE: [PATCH v2 1/2] clk: divider: prepare for minimum divider
Hi Mike, On Thu, Jan 24, 2013 at 22:36:30, Mike Turquette wrote: Quoting Mohammed, Afzal (2013-01-24 03:29:15) It is a functional constraint: divider has 8 bits and it can have all possible values (0 to 255) and divider value corresponds to value set in the 8 bits. But depending on the modes the minimum value that can be configured (to get display working) varies. Eg. For raster mode (which the driver is presently supporting), it can take a minimum value of 2, while in LIDD (LCD interface display driver) mode it can take a min value of 1. Here min rate is not a constraint w.r.t divider in LCDC IP, but rather min divider. Just so I understand correctly... you are saying that the functional constraint is not caused by the clock rate, but instead by the divider value? For the different modes (raster vs LIDD) is the clock rate the same, or is the clock rate different? What is the clock output rate of the divider in raster mode? What is the clock output rate of the divider in LIDD mode? Yes, functional constraint in caused by divider value. clock output rate can defined for both modes as follows, p_clk (clock output rate) = lcd_clk (input clock rate) / div, to configure div, we have r/w 8 bits, so div values can range from 0-255, And IP spec says value 0 and 1 should not be written, in raster mode. Further it says if in LIDD mode it can have values from 0-255, but effect of writing 0 is same as 1. Effect of divider value on output rate is in the same way for both modes as per above expression (except for writing 0 in LIDD mode). The driver supports only raster mode. Regards Afzal Note: link to trm has been mentioned in the earlier reply.
Re: RE: RE: [PATCH v2 1/2] clk: divider: prepare for minimum divider
Quoting Mohammed, Afzal (2013-01-25 04:06:41) Hi Mike, On Thu, Jan 24, 2013 at 22:36:30, Mike Turquette wrote: Quoting Mohammed, Afzal (2013-01-24 03:29:15) It is a functional constraint: divider has 8 bits and it can have all possible values (0 to 255) and divider value corresponds to value set in the 8 bits. But depending on the modes the minimum value that can be configured (to get display working) varies. Eg. For raster mode (which the driver is presently supporting), it can take a minimum value of 2, while in LIDD (LCD interface display driver) mode it can take a min value of 1. Here min rate is not a constraint w.r.t divider in LCDC IP, but rather min divider. Just so I understand correctly... you are saying that the functional constraint is not caused by the clock rate, but instead by the divider value? For the different modes (raster vs LIDD) is the clock rate the same, or is the clock rate different? What is the clock output rate of the divider in raster mode? What is the clock output rate of the divider in LIDD mode? Yes, functional constraint in caused by divider value. clock output rate can defined for both modes as follows, p_clk (clock output rate) = lcd_clk (input clock rate) / div, to configure div, we have r/w 8 bits, so div values can range from 0-255, And IP spec says value 0 and 1 should not be written, in raster mode. Further it says if in LIDD mode it can have values from 0-255, but effect of writing 0 is same as 1. Afzal, Thank you for the information. In short, the way you program your clock depend on the configuration of your lcdc device. As such I am not sure the basic divider is the right choice for you. You might be better off creating a clock for your IP which takes into account these details. Luckily it is possible to inherit from the basic clock types and create a new type. An example of this is the MXS divider. It uses the basic divider as a parent class and adds a busy bit. This is a better approach than putting every feature into the basic divider type. You can see how it was done in drivers/clk/mxs/clk-div.c Let me know what you think. Regards, Mike Effect of divider value on output rate is in the same way for both modes as per above expression (except for writing 0 in LIDD mode). The driver supports only raster mode. Regards Afzal Note: link to trm has been mentioned in the earlier reply. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RE: [PATCH v2 1/2] clk: divider: prepare for minimum divider
Quoting Mohammed, Afzal (2013-01-24 03:29:15) Hi Mike, On Thu, Jan 24, 2013 at 03:10:53, Mike Turquette wrote: Quoting Afzal Mohammed (2013-01-23 03:38:52) Some of clocks can have a limit on minimum divider value that can be programmed, prepare for such a support. Add a new field min_div for the basic divider clock and a new dynamic clock divider registration function where minimum divider value can be specified. Keep behaviour of existing divider clock registration functions, static initialization helpers as was earlier. My first question is whether the minimum divider you plan to use is an actual constraint of the hardware (e.g. the clock controller ip only lets program two bits which divide by 4, 5, 6 or 7, where 4 is the minimum divider) or if this is a functional constraint (e.g. the clock hardware can divide by a lower value, but you never want that since it results in non-functional video/audio/whatever). If this is more of a functional constraint then perhaps a new api like clk_set_min_rate makes more sense. It is a functional constraint: divider has 8 bits and it can have all possible values (0 to 255) and divider value corresponds to value set in the 8 bits. But depending on the modes the minimum value that can be configured (to get display working) varies. Eg. For raster mode (which the driver is presently supporting), it can take a minimum value of 2, while in LIDD (LCD interface display driver) mode it can take a min value of 1. Here min rate is not a constraint w.r.t divider in LCDC IP, but rather min divider. Just so I understand correctly... you are saying that the functional constraint is not caused by the clock rate, but instead by the divider value? For the different modes (raster vs LIDD) is the clock rate the same, or is the clock rate different? What is the clock output rate of the divider in raster mode? What is the clock output rate of the divider in LIDD mode? Thanks, Mike As it is the case, you prefer a clk_divider_set_min_div()? Secondly, have you looked into using the rate-table option provided by the basic divider clock? Can you explain how this is not a good fit for your needs? Perhaps there are too many divisor values so the table would be large? Divider values can range from 2-255 (254 possible values), so I believe it is not a suitable candidate here (also divider to values have 1-to-1 mapping) Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
