Re: [patch 1/1] TOUCHSCREEN: S3C24XX touchscreen driver from Arnaud Patard.
В сообщении от 19 ноября 2009 1:29:40 автор Ben Dooks написал: skipped + /* Initialise registers */ + if ((info-delay 0x) 0) + writel(info-delay 0x, ts.io + S3C2410_ADCDLY); As for me, it's not OK to modity ADC-related registers in touchscreen driver, adc driver should be modified to support delay. Regards Vasily signature.asc Description: This is a digitally signed message part.
Re: [PATCH 01/18] ARM: MM: use 64bytes of L1 cache on plat S5PC1xx
On Fri, Nov 13, 2009 at 11:19:03PM +, Ben Dooks wrote: On Thu, Nov 12, 2009 at 09:21:45AM +0100, Marek Szyprowski wrote: From: Kyungmin Park kyungmin.p...@samsung.com From: Kyungmin Park kyungmin.p...@samsung.com This one i'll keep out of the series, as it either needs to go to Russell's patch tracker on be on a branch for Russell to merge into the main arm tree. FYI, I haven't seen it there yet. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/19] drivers: serial: add support for Samsung S5PC110 SoC uart
On Thu, Nov 19, 2009 at 11:44:14AM +0900, jassi brar wrote: Let each platform code(SoC specific) define names of all possible source clocks and let the board init code pass on the potential source clocks by some bit-mask(or some other mechanism) while setting the platform data. This is going to set off warnings from a clock API point of view - passing clock names around in platform data is usually a sign that something is very wrong. Keeping the mapping inside the clock API (still controlled by the board driver but by telling the clock API that device X should use clock Y). -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/19] drivers: serial: add support for Samsung S5PC110 SoC uart
On Thu, Nov 19, 2009 at 7:33 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Thu, Nov 19, 2009 at 11:44:14AM +0900, jassi brar wrote: Let each platform code(SoC specific) define names of all possible source clocks and let the board init code pass on the potential source clocks by some bit-mask(or some other mechanism) while setting the platform data. This is going to set off warnings from a clock API point of view - passing clock names around in platform data is usually a sign that something is very wrong. Keeping the mapping inside the clock API (still controlled by the board driver but by telling the clock API that device X should use clock Y). no clock pointer needs to be passed, just a pointer to an array of _strings_ There is no need to even include any clock header in platform code for the purpose. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/19] drivers: serial: add support for Samsung S5PC110 SoC uart
On Thu, Nov 19, 2009 at 8:08 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Thu, Nov 19, 2009 at 08:05:29PM +0900, jassi brar wrote: On Thu, Nov 19, 2009 at 7:33 PM, Mark Brown This is going to set off warnings from a clock API point of view - passing clock names around in platform data is usually a sign that something is very wrong. Keeping the mapping inside the clock API (still controlled by the board driver but by telling the clock API that device X should use clock Y). no clock pointer needs to be passed, just a pointer to an array of _strings_ There is no need to even include any clock header in platform code for the purpose. Yes, that's what I was commenting on - like I say, passing clock names tends to set off the same alarm bells as passing a struct clk. Like I say, the general model for this has been that the fixups will be done by having the machine code talk to the clock API ratehr than bouncing the data about the clock to use through the driver. The case here is that UART controller can source from various platform clocks to generate the UART clocks. The drivers/serial/samsung.c chooses a source clock that can result in closest match to the requested rate. How could we do that from machine code(except for writing callbacks for each machine using the SoC)? Or maybe i cud understand better looking at some example. Cud u suggest some please? -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/19] drivers: serial: add support for Samsung S5PC110 SoC uart
On Thu, Nov 19, 2009 at 11:08:27AM +, Mark Brown wrote: On Thu, Nov 19, 2009 at 08:05:29PM +0900, jassi brar wrote: On Thu, Nov 19, 2009 at 7:33 PM, Mark Brown This is going to set off warnings from a clock API point of view - passing clock names around in platform data is usually a sign that something is very wrong. Keeping the mapping inside the clock API (still controlled by the board driver but by telling the clock API that device X should use clock Y). no clock pointer needs to be passed, just a pointer to an array of _strings_ There is no need to even include any clock header in platform code for the purpose. Yes, that's what I was commenting on - like I say, passing clock names tends to set off the same alarm bells as passing a struct clk. Like I say, the general model for this has been that the fixups will be done by having the machine code talk to the clock API ratehr than bouncing the data about the clock to use through the driver. I'm not sure what you're commenting on precisely, but the Samsung code as a whole doesn't use the clk API very well, and I suspect that is starting to cause people to have to pass clock names around. I've tried to persuade Ben to tidy this up and convert over to clkdev before it becomes too big a problem, but I've had little success. I suspect it's now grown too big to be tackled sanely. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/19] drivers: serial: add support for Samsung S5PC110 SoC uart
On Thu, Nov 19, 2009 at 11:38:41AM +, Russell King - ARM Linux wrote: I'm not sure what you're commenting on precisely, but the Samsung code as a whole doesn't use the clk API very well, and I suspect that is starting to cause people to have to pass clock names around. That's what I'd thought originally but it's not quite the problem here. The issue is that Samsung serial port clock is chosen from a mux and the logic to select which of the inputs to that mux should be used is in the serial driver. This means that if the set of parent clocks changes then the serial driver needs to be told what they are. My suggestion was to push this logic down into the clock API so the serial driver just requests a rate and then clock API picks the best option from the mux. As well as being nicer from the clock API point of view this would also allow other drivers to use the same logic since these muxes are a standard idiom for Samsung SoCs. I've tried to persuade Ben to tidy this up and convert over to clkdev before it becomes too big a problem, but I've had little success. I suspect it's now grown too big to be tackled sanely. clkdev would be nice but I don't think it'd deal with the issue here. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/19] drivers: serial: add support for Samsung S5PC110 SoC uart
On Thu, Nov 19, 2009 at 11:48:33AM +, Mark Brown wrote: On Thu, Nov 19, 2009 at 11:38:41AM +, Russell King - ARM Linux wrote: I'm not sure what you're commenting on precisely, but the Samsung code as a whole doesn't use the clk API very well, and I suspect that is starting to cause people to have to pass clock names around. That's what I'd thought originally but it's not quite the problem here. The issue is that Samsung serial port clock is chosen from a mux and the logic to select which of the inputs to that mux should be used is in the serial driver. This means that if the set of parent clocks changes then the serial driver needs to be told what they are. My suggestion was to push this logic down into the clock API so the serial driver just requests a rate and then clock API picks the best option from the mux. As well as being nicer from the clock API point of view this would also allow other drivers to use the same logic since these muxes are a standard idiom for Samsung SoCs. Yes, I agree with that approach. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/1] TOUCHSCREEN: S3C24XX touchscreen driver from Arnaud Patard.
On Thu, Nov 19, 2009 at 01:52:36PM +, Daniel Silverstone wrote: On Thu, Nov 19, 2009 at 11:34:40AM +, Ben Dooks wrote: + input_report_key(ts.input, BTN_TOUCH, 1); + input_report_abs(ts.input, ABS_PRESSURE, 1); No fake pressure events please, BTN_TOUCH should be enough. I'd have to check, IIRC tslib needs these to function properly. Indeed it does -- otherwise it won't work. Yes you could try going around and patching TSLIB but so many people use it that it is principle-of-least-surprise to produce pressure events. + ts.input-keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH); + input_set_abs_params(ts.input, ABS_X, 0, 0x3FF, 0, 0); + input_set_abs_params(ts.input, ABS_Y, 0, 0x3FF, 0, 0); + input_set_abs_params(ts.input, ABS_PRESSURE, 0, 1, 0, 0); Drop ABS_PRESSURE. ok, see above. The same applies here -- claim ABS_PRESSURE or tslib won't operate with the touchscreen. While it is tempting to be 100% exactly correct to what the hardware reports (which is only TOUCH not PRESSURE) it is preferable to work with the software which the majority of people use -- namely tslib. I would strongly argue against removing the ABS_PRESSURE stuff personally, despite it being essentially a lie. And I would strongly argue that you just need to update your tslib, especially given the fact that this issue was dealt with there about a year ago. And if you really need that fix to be in released (read 'tagged') version of tslib - please speak to its maintainer. Why everyone thinks that it is a good idea to pile workarounds for software issues in the kernel but updating the other parts of software stack is a big no-no? -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/1] TOUCHSCREEN: S3C24XX touchscreen driver from Arnaud Patard.
On Thu, Nov 19, 2009 at 09:03:21AM -0800, Dmitry Torokhov wrote: Why everyone thinks that it is a good idea to pile workarounds for software issues in the kernel but updating the other parts of software stack is a big no-no? It's probably because pressing 'reset' and have your board TFTP the new kernel straight from your development machine is far easier than going through the hoops to regenerate a root filesystem and reflashing it. Note that I'm not condoning it, just pointing out why it happens. And yes, we must resist the temptation to merge such workarounds. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
