On Sat, Nov 16, 2013 at 06:12:26AM -0800, Tony Lindgren wrote: > [...] > > b) I could not get the 32GB eMMC working. For me the chip is not found > > and I don't know how to debug it. > > OK the eMMC issue might be related to the control module PBIAS > register support missing. If so, that should be fixable with the > auxdata until we have a minimal control module device driver to > deal with the PBIAS and expose those features as regulators to > the omap-hsmmc driver. I wasn't aware, that PBIAS register support is missing for DT boot. The existing board code uses a 2.8-3.0V regulator for mmc1, so missing PBIAS is probably the problem. > > [...] > > > > My suggestion would be: > > 1. Find a better workaround for omapdss to acquire the SDI > > regulator. My current hack is obviously not acceptable. > > 2. Load the panel driver via DT as seen above and reference > > the omapdss interface with something like the above > > "ti,dss-source". > > To me it seems that we should be able to add minimal panel entries to DT > if we stick to existing standard bindings. Then the timings etc can be > set up based on the compatible flag. So I would leave out the properties > for ti,sdi-datapairs and ti,dss-source for now, and just set those in > the driver based on the sony,acx565akm compatible flag. Or maybe it should > be sony,acx565akm-n900 if there's some board specific configuration info. So we add reset-gpio and label to the DT data (they are panel specific and independent of omapdss) and just hardcode "dsi.0" with 2 data lanes into the driver? That sounds fine for me. If neither Tomi nor anybody else has better ideas I will cook a patch for that. I'm not sure how to setup the vdds_sdi regulator for omapdss, though. Is there an example for a legacy driver using a DT regulator available? > [...] -- Sebastian
Attachment:
signature.asc
Description: Digital signature
